Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: ARSPR on May 29, 2006, 01:44:37 pm
-
Well I'm trying to fix HTL Triton alpha envmapping (within 3.6.8. zeta) but there's actually a lot of things I don't understand. So please, can anyone check my statements or answer my dudes?
- Within Modelview, GTFr Triton (freighter2t-01.POF) uses the next textures: Triton_HTL1, Triton_HTLDebris, DocTile6A and Triton_HTL_Turrets. So I can asume that Triton_HTL1_b and Triton_HTL_c (that are also inside mv_models) are useless. Am I right?
- As example, Triton_HTL1 is the main GTFr Triton texture. And it has a full white alpha channel. I thought these ones were the texture and channel that affected envmapping so I edited it with Photoshop and I made it fully black. But then what I get is a bright ship with a lot of black envmapping nevertheless.
So can anyone tell me which alpha-channel and in which texture (main, glow or shine) causes the overbright envmapping in this ship?
I have also checked that HTL Fenris and all its textures (Fenris-HTL, Fenris-HTL-glow and Fenris-HTL-shine) have a white alpha but you don't get the weird envmapping. So I just can't understand anything
- I think the -glow textures are textures that are always rendered in full lighting even if they are at the shade (so you use them to simulate lights). And of course these textures are rendered over the main ones. Am I right? (If you use the -glow launcher flag ...)
And I think the -shine textures are used to tell the renderer how much reflective is each surface to specular "brights", so you don't get these brights in black textures and white ones will appear as a mirror or stainless steel. Am I right? (If you use the -spec launcher flag ...)
Thank you in advance
-
FSwiki..... (http://www.hard-light.net/wiki/index.php/Texturing)
If you are using alpha env then game uses the alpha of the shinemaps for envmapping. Extra textures are usually used by other levels-of-details (LODs) especially when named that way.
-
Oddly enough, I only updated that a few days ago :D Thanks to whoever added the -trans definition as well, forgot that one.
I'm working my way through the modding section, I'm going to try and explain Hierarchies and PCS/Modelview in a way that'll make it easier for new modders to get their ships working :)
-
FSwiki..... (http://www.hard-light.net/wiki/index.php/Texturing)
If you are using alpha env then game uses the alpha of the shinemaps for envmapping. Extra textures are usually used by other levels-of-details (LODs) especially when named that way.
BEATING MYSELF WITH A CLUB (I'm always saying 'look in the wiki or Karajorma's FAQ') :headz:
Tomorrow I will make my next try...
Just one thing, are Triton_HTL1_b and Triton_HTL1_c useless? Does the _b or _c endings have any 'special' meaning as -glow or -shine?
Thank you
-
As already said, the alpha of the specmaps is used for envmaps. But unless that specmap is actually using alpha transparency then it should have NO alpha channel. Save the file as DXT1c (with no alpha) and then it should work better. The code only checks that a texture has an alpha channel when using -alpha_env, not whether it makes full use of that alpha channel. The only way to make it work right is to use full alpha transparency provided by the alpha channel, or not have an alpha channel at all. The code isn't smart enough (without being a billion times slower) to figure it out otherwise.
And the _b/_c stuff is usually the LODed textures. If you UV map it against only _a (and use mipmaps instead) then you should be able to get rid of them. Basically, if they aren't referenced in the POF then they aren't used. Only -glow, -shine, -trans, and -bump (in the future) are special since they aren't referenced in the POFs but loaded by the game itself.
-
im waiting for the ptah to release my big fix of all of the maps.
i find that my various texture improvements are accepted much better when they are accompanied by a high-polygon model.
unfortunately, unknown target has disappeared
and micropsycho too (for the dragon)
-
Thanks for the info Taylor, I've updated the Wiki to reflect what you said about Shine-maps.
-
im waiting for the ptah to release my big fix of all of the maps.
i find that my various texture improvements are accepted much better when they are accompanied by a high-polygon model.
Just don't wait too long. Some of us would be just as happy with fixed maps as with a new model. :)
There will probably be a new MediaVP set before long since there is a backlog of missing/broken things. There is a new feature for effects which is disabled by default now since it breaks with the current MediaVPs, for instance. Just be sure to make sure DaBrain knows about the new maps when they are ready since he is the man in charge of the MediaVPs now.
-
ah, unknown target has just returned from his mysterious disappearance
won't be too long now.
the reason that i'm waiting is because the envmap on the ptah currently is borked, you can tell on the cockpit window that its all shifted down on the model for some reason.
-
Wow - all my ships excluding the Fenris are now flying mirrors, which is awesome......and weird,........and awesome.
I'll go through my HTL stuff now and update it to take full advantage of env mapping and Taylor's guide. :)
Has anyone already done/started anything for any of them? Ie, going over the map and 'properly' giving it env mapping that could save me time?
BTW, since I will have all the source files out, should I make some bump maps up too?
i find that my various texture improvements are accepted much better when they are accompanied by a high-polygon model.
Just don't wait too long. Some of us would be just as happy with fixed maps as with a new model. :)
There's that and the fact that new maps might inspire peeps to make a HTL model in the first place. ;)
*doesn't mention the word 'poseidon'*
-
BTW, since I will have all the source files out, should I make some bump maps up too?
Up to you. The code has been updated to actually load and use the maps properly now, but it still can't do anything with them after that. The rendering code needs to be updated first and I don't know when that's going to happen. Could be a while.
Having some ready to use maps would greatly encourage the code work to happen though. Not having anything to test with makes it take much longer to get the code working properly. I don't really have to the time to work on any new features (other than what I've already got on my plate) but if you do maps for one or two ships then I might be able to find a couple hours here and there to hack on it. :)
-
Now _that_ would be awesome. :D
*scurries away to do some bump mapping*
-
Are we talking 256-colour displacement maps or normal maps here?
-
Are we talking 256-colour displacement maps or normal maps here?
Normal maps.
EDIT: Or whatever you guys would prefer I guess. :)
-
I think normal maps would be better, they have a slight disadvantage of being slightly harder to produce (but then, if you can make displacement maps, you can make normals using the NVidia plugin). And, I believe, give a better effect, though my actual understanding of the difference is pretty limited.
-
Hey thank you to all of you. I'm learning a lot so I think even if it's going to be a full 'official' patch I'm going to play a little trying to fix Triton or giving it different env-mapping qualities...
Thanks for the info Taylor, I've updated the Wiki to reflect what you said about Shine-maps.
I'm at work and Wiki needs a login now (I didn't have to before...) so I'm not going to open a count just now.
There's a little mistake in Texturing > SCP Team Recommendations. So if someone wants to correct it:
Other alternatives to TGA -- in cases where DXT compression is unacceptable (noticable errors/artifacts) -- are u888, u8888, or u1555. u888 is 24 bit color and u8888 is 32 bit color (24 bit plus 8 bit alpha map), just like the types of TGA. The file doesn't get any smaller than TGA, but it can now have mipmaps (see Models). u1555 is 15-bit color, usually best for files that used to be PCX.
So there's a missing 8 and I also think that DDS are smaller than TGAs because they're compressed (or they can be bigger but because of mipmaps...)
And now just one question. If you open a JPG, modify it and then save it again, and you keep doing this, (even without modifying), you loose quality because in each saving step the file is lossly recompressed. So, is it the same with DDS compressed format?
I ask this because if it is true, I think it could be a good idea for all the modders to distribute 'SDK' uncompressed TGAs of their textures to help people who might want to modify them. In this way you could make a zip with a data folder structure or just a MyHTLSuperModel.vp containing DDS mipmapped textures and POF for playing and a SDK folder with the uncompressed TGAs textures. Even if nooby people, as myself, just unzip this archive within Freespace folders they will waste HD space but their game performance won't suffer as FSOpen does not use SDK folder in any way.
-
So there's a missing 8 and I also think that DDS are smaller than TGAs because they're compressed (or they can be bigger but because of mipmaps...)
DDS doesn't mean compressed so it doesn't automatically mean that it's smaller. DXT (DXT1, DXT3, DXT5) are the compressed versions of DDS (same file and extension, but different image format). Those will be anywhere from 4 to 8 times smaller than a 32-bit TGA version of the same image. Uncompressed DDS (the u???? stuff) will be the same size as a TGA (as image formats go they are almost identical data wise). Mipmaps will add approximately 30% to the original file size of a DDS (whether it's compressed or not).
I make use of both compressed and uncompressed DDS since some effects just don't look very good with the compression artifacts. Using uncompressed DDS for them lets me still have mipmaps, but not have to lose any image quality.
And now just one question. If you open a JPG, modify it and then save it again, and you keep doing this, (even without modifying), you loose quality because in each saving step the file is lossly recompressed. So, is it the same with DDS compressed format?
Correct, if it's actually a compressed DDS (DXT). DDS can be uncompressed too and so would not sacrifice any quality by saving them over and over again.
-
Thank you, Taylor :yes:
So in this case, and if the modder wants to fully share his/her work, I think it could be a good idea to distribute new model add-ons with the data/vp playable structure, (using compressed textures if possible), AND the 'SDK' folder with the uncompressed textures and even raw 3D models (TrueSpace files, 3dmax or whatever).
In this way, as I've said before, if people are not careful or do not understand what they're unzipping they will just waste HDD space but without affecting the game, (but nowadays people usually have HUGE HDDs).
-
Thanks for the info Taylor, I'll alter the modding side of the Wiki to reflect that as well.. Now I've finally got Truespace working on my machine again, I should hopefully be able to do more about that side of things in the next week or so :)
-
I think normal maps would be better, they have a slight disadvantage of being slightly harder to produce (but then, if you can make displacement maps, you can make normals using the NVidia plugin). And, I believe, give a better effect, though my actual understanding of the difference is pretty limited.
Normal maps can be produced several different ways depending on the program used and the modeler's/texturer's familiarity/skill. Most game engines don't use displacement maps, rather bump maps or normal maps. Displacement maps are usually used for rendering programs such as maya and 3dsmax to keep the poly counts low.
The best ways here to do this would be with a pluggin (ATI or nvidia) or do a high poly version of the base mesh and project it onto it for the normal map (can get the best results, but you have to really know what your doing).
The third option is to use Zbrush. This wouldn't work very well for the federation ships, but may work really well for the Shivan. As long as the model has a UV map already, they can be produced pretty fast. The HL2 mod I'm working on has used all the above to great effect, especially the zbrushed normal maps on organic models.
-
Sorry for the double post, but I did this in 1.5 hours normal mapped and textured in zbrush, (rocks for cliff face).
(http://img145.imageshack.us/img145/4933/pic14rz.th.jpg) (http://img145.imageshack.us/my.php?image=pic14rz.jpg)
(http://img112.imageshack.us/img112/2602/stoutdoors1yp.th.jpg) (http://img112.imageshack.us/my.php?image=stoutdoors1yp.jpg)
-
ZBrush looks pretty good, I use Deep Paint 3D which is pretty similar for my stuff. I can produce normals either way really, but the 'proper' way is pretty labour intensive, I can actually convert the bump map into anything up to a 16 million polygon model and then yank normals, but the process takes a fair while, so I'll probs stick to the 'cheaper' way of doing it :)
-
Well, the Aeolus has been done - bumpmap, envmap, fewer textures and more texture format optimisations. However, I seem to be encountering problems in exporting DDS's with an alpha map. Most of the things I've tried result in the env map 'hiding' much of the shine map - as in, it's not stored as an alpha map, which results in this in-game:
(http://sectorfiles.net/ti-file-dump/VasudanAdmiral/Pics/EnvWashout.png)
(basically - the export to dds turned the shinemap mostly white with some splotchy exceptions as seen above)
And just when I think I've set the file up correctly, I get a "Unsupported input format" message from the DDS plugin.
So my question is, how exactly do you go about properly exporting an alpha mapped DDS? (photoshop or preferably PSP)
-
oh, i'd already taken care of aeolus, no problems...
refer to my thread: New Feature Demands New Textures
for my list of what has and hasnt been fixed
-
So my question is, how exactly do you go about properly exporting an alpha mapped DDS? (photoshop or preferably PSP)
What DDS format are you saving in? With true alpha you need to be using DXT5 only. DXT3 has alpha support but it's only 4-bit and that's probably not enough for this purpose. DXT1 doesn't have alpha (as far as the game is concerned anyway).
-
Env Mapping, = Reflective surfaces?
-
Yesterday I played for a while with Triton main shinemap (Triton_HTL1-shine.DDS) and what I did (with Photoshop) was just the following steps (sorry if I post very obvious ones):
- I downloaded and installed latest nvidia DDS plug-in (http://developer.nvidia.com/object/photoshop_dds_plugins.html). Here you have instructions for Paint Shop Pro too.
- I opened the file within Photoshop and it has a fully white Alpha1 channel. This channel is causing the mirror effect. I just deleted this channel. Then selecting RGB channel (ie the rest channels) I copied the full image, I made a new channel (Photoshop names it Alpha 1) and pasted it inside it. As main RGB channel is quite gray I'm lowering the full env-mapping effect without worrying very much about its quality (I could have just use a continuous grey colour).
- Then I saved the image in DDS format. In the first dialog box (Photoshop's one) I ticked 'Alpha Channels'. Within the second dialog box (the plug-in's one) I can select 8:8:8, 8:8:8:8 (for uncompressed) or DXT5 (for compressed with alpha) without trouble. My only trouble is that DXT1 always puts a white alpha even if I select RGB only. So no crashes but a little issue. I always recheck the texture loading it again in Photoshop.
- With 8:8:8, I get what I suppose is a "default" amount of envmapping. But with a full black Alpha I get no envmapping as expected. With the "textured" alpha I get some amount of it.
- But OTOH I also noticed that LOD0 has much more spec brights than LOD1. But I don't know if that's normal or if it is some kind of bug.
I hope this info can be useful for you. Does FSOpen support bumpmaps?
-
I can't remember how Photoshop handles this (been a few years since I've used anything but GIMP), but you need to only have RGB channels, no alpha channel, when saving DXT1. That way you make sure not to get the white/black alpha channel in there. Remember that DXT1 does support 1-bit alpha so it can have a basic alpha channel. The game doesn't use this properly though so you have to make sure that it's only RGB before saving to DXT1.
-
I
I can't remember how Photoshop handles this (been a few years since I've used anything but GIMP), but you need to only have RGB channels, no alpha channel, when saving DXT1. That way you make sure not to get the white/black alpha channel in there. Remember that DXT1 does support 1-bit alpha so it can have a basic alpha channel. The game doesn't use this properly though so you have to make sure that it's only RGB before saving to DXT1.
It doesn't matter. If I use DXT1 (RGB or ARGB) I always get the alpha even if there's no alpha channel in the drawing I'm saving.
OTOH, I've turned off envmapping, (just to avoid mixing effects), and at least Triton and Aeolus (unmodified 3.6.8. zeta versions) have a huge differences in spec brights between LOD0 and LOD1. But other models do not show that differences.
-
Does DXT MipMap the Alpha channels as well as the colour channels? Also, does the Engine auto-mipmap? Does that mipmap both the colour and alpha channels?
-
Does DXT MipMap the Alpha channels as well as the colour channels? Also, does the Engine auto-mipmap? Does that mipmap both the colour and alpha channels?
It doesn't distinguish between channels as far as mipmaps go, it only sees the image as a whole and replicates the top image as it drops down the mipmap chain. Whatever properties exist in the main level will also exist in each subsequent mipmap level. The engine will use mipmaps automatically but only create them if using -mipmap with -img2dds and/or -env, and only for images affected by those options. If the main image includes an alpha channel then any mipmap levels created by the game will also contain the alpha channel.
-
Got it thanks :) Sorry, just read through my last post and I sound like my own boss there, gatling gun questions ftl :(
-
W00t! Shiny! Thanks all. :)
Turns out I needed to flatten the already flattened image for that new exporter to work (thanks ASPSR), else it gave me a "too many channels to export(5)" error.
But it works now!
oh, i'd already taken care of aeolus, no problems...
Err, that was what I said this for. :p
Has anyone already done/started anything for any of them? Ie, going over the map and 'properly' giving it env mapping that could save me time?
No matter though - I still needed to learn how to do it, and more than just the env map was fixed this run through.
Since I'll be performing optimisations for the Aeolus, TC-Tri, Triton and Fenris, would you be willing to send me any env/shine maps you've done for those ships? (Lucifer should be fine - I've not heard of any performance issues/bugs about it)
But OTOH I also noticed that LOD0 has much more spec brights than LOD1. But I don't know if that's normal or if it is some kind of bug.
This is one of the things I've just fixed actually - it was simply because the LODs used a separate texture to the main texture, and these other textures did not have shinemaps. Now - in accordance with Taylors modding guide, the lods all use the same texture as LOD 0, with mipmaps handling texture shrinkage. Faster performance, smaller RAM footprint. :)
-
Since I'll be performing optimisations for the Aeolus, TC-Tri, Triton and Fenris, would you be willing to send me any env/shine maps you've done for those ships?
DaBrain already fixed the specmap for the TC-Tri, making it a true alpha map. If you don't already have that let me know and I'll dig it up from my VPs for you.
-
It doesn't appear to be in the latest media vps, so nope, and thanks the both of you. :)
-
Here it be ... http://icculus.org/~taylor/fso/misc/tc-tri-htl-shine.dds
(it was too big, even compressed, to attach here)
-
This is one of the things I've just fixed actually - it was simply because the LODs used a separate texture to the main texture, and these other textures did not have shinemaps. Now - in accordance with Taylors modding guide, the lods all use the same texture as LOD 0, with mipmaps handling texture shrinkage. Faster performance, smaller RAM footprint. :)
I'm just learning, but as I posted in the first one, within Modelview I do not get Triton_HTL1_b and Triton_HTL_c, (with no associated shinemaps), listed as used textures. It doesn't matter if I change LOD.
But with PCS I get a list of 6 textures that includes these two ones.
Can I assume that Modelview has a bug and it only shows LOD0 textures? Or is there a way to show LODx textures that I can't find?
Thank you.
-
Modelview has a bug and does a bad job of showing non-LOD0 textures.
-
Well. for some days I've been playing with textures within Photoshop and I've been searching in Internet about compression and texturing and what I think I have learned is the following knowledge, (in plain, non-technical words):
- Losy compression techniques, (such as DXT), work firstly cuting the full texture in small pieces, (4x4 pixels). Then, within these pieces, the different algorithms save some of the more important colour information, while the rest is just calculated. In these way they can redraw the full texture with less information than original and they achieve smaller sizes.
- With this process, they are making a kind of "mean" of pixel colour in these areas. Because of it, these compression methods usually work very well when colours change smoothly. But they can get artifacts, (pixels with quite wrong colours), within edges and abrupt changes. Specially designed methods are needed to get more accurate interpolation within these areas.
- When textures are used to "paint" the 3D model, the artifacts aren't usually very important. If you were very near to a spaceship, you would see that in "GTD Bastion" sign, the letters have a bit ugly edge or something like that and that's all.
- But in 3D games, there are other maps that are used for making calculations over the "painted" textures. Normal maps or spec maps can be examples of them. In these textures, each colour channel is just a "number" that is used to calculate something on every pixel. For example in a normal map you store the direction the real surface would have over the flat 3D mesh. In this way the software can calculate if you are directly seeing reflections on every pixel. Without normal maps the whole 3D triangle would have the same direction. The normal map store the normal vector to the real surface on each pixel, x component is saved in Red Channel and y component is saved in Green (z isn't saved because z = Sqr(1-x^2-y^2)). Other maps can contain any kind of info you can think of.
These 'non-real' maps have usually very sharp changes, so compression algorithms as DXT can generate a lot of artifacts. And the real problem is these artifacts mean wrong calculations that can hugely increase the original deviation and be quite noticeable. So you will see strange and changing brights, displacements or whatever.
- So DXT compression will be usually enough for texturing maps because artifacts will be just a few ones and they usually have no more importance rather than some ugly pixels. (Hey, I'm sure that most of us have a digital camera and nearly no one will take pictures in RAW uncompressed format, even a lot of cameras just support jpg compressed format). But for "calculation" maps, DXT compression can be a wrong option if they're very sharp or if the interpolation errors cause very noticeable effects. So you will need to use an uncompressed map or you will need FSOpen and Graphics API to support other compression techniques, such as V8U8 or 3Dc that are better designed for this kind of maps.
(I hope that this info wasn't very wrong and that it could be interesting to someone as general info ;) ).
-
You should always use the latest version of nvdxt to do the conversion with the new -quality_highest switch, which enables their improved algorithms.