[bkd86]

Sorry for the double post, but I did this in 1.5 hours normal mapped and textured in zbrush, (rocks for cliff face).

[Flipside]

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

[Vasudan Admiral]

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:

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

[Turambar]

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

[taylor]

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

[Colonol Dekker]

Env Mapping, = Reflective surfaces?

[ARSPR]

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?

[taylor]

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.

[ARSPR]

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.

[Flipside]

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?

[taylor]

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.

[Flipside]

Got it thanks Sorry, just read through my last post and I sound like my own boss there, gatling gun questions ftl

[Vasudan Admiral]

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.

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.

[taylor]

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.

[Vasudan Admiral]

It doesn't appear to be in the latest media vps, so nope, and thanks the both of you.

[taylor]

Here it be ... http://icculus.org/~taylor/fso/misc/tc-tri-htl-shine.dds
(it was too big, even compressed, to attach here)

[ARSPR]

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.

[karajorma]

Modelview has a bug and does a bad job of showing non-LOD0 textures.

[ARSPR]

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

[neoterran]

You should always use the latest version of nvdxt to do the conversion with the new -quality_highest switch, which enables their improved algorithms.