[ARSPR]

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

[Wanderer]

FSwiki.....

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.

[Flipside]

Oddly enough, I only updated that a few days ago 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

[ARSPR]

FSwiki.....

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')

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

[taylor]

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.

[Turambar]

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)

[Flipside]

Thanks for the info Taylor, I've updated the Wiki to reflect what you said about Shine-maps.

[taylor]

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.

[Turambar]

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. 

[Vasudan Admiral]

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'*

[taylor]

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.

[Vasudan Admiral]

Now _that_ would be awesome.

*scurries away to do some bump mapping*

[Flipside]

Are we talking 256-colour displacement maps or normal maps here?

[taylor]

Are we talking 256-colour displacement maps or normal maps here?

Normal maps.

EDIT: Or whatever you guys would prefer I guess.

[Flipside]

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.

[ARSPR]

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.

[taylor]

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.

[ARSPR]

Thank you, Taylor 

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).

[Flipside]

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

[bkd86]

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.