Ah I understand now, I thought I couldn't open the file because it's thumbnail was unknown by xNview. Why are the normal maps so low contrast, do I need to pen these with the crytif plugin or something?
correct me if im wrong, but to "compress" the normal maps, the texture exporter removes the blue channel, which leaves only the green and red channels (for normal X and Y) This effectively makes the normal maps look a bit odd. The way to fix it is to open up the normal map in photoshop, apply a levels modifier, and make the input levels of the RGB channel 128 1 255 (so you just move the black slider to 128, which is in the middle of the spectrum.
I found out this trick by myself and havent done much testing with it so im not sure if its a perfect fix but its worked so far for me.
Could you explain that a little further Olli? I'm confused by this. I've checked the exported tif for my normals and their channels look the same as the baked results from xNormal.
I confirmed with a rendering programmer at work, Crysis does indeed delete one of the channels, I think this is pretty common practice. Doesn't the blue channel get regenerated at run time by the shader or something?
Yup, since the normals are normalized upon import (IIRC, BTW, this is all on the Wiki) the engine can derive the blue channel with just a few simple math operations(b=1-(r+g)). It saves a lot of space.
Ah okay, the DDS versions. I was checking the TIFs. I don't really understand the way the TIF and DDS stuff works. I export using CryTIF, and then the engine compiles a DDS. But in the material editor I reference the TIFs; but then in-game it's using the DDS?
So basically, you should ignore the DDS's, these files are generated automatically by the RC (Resource Compiler) so, just ignore them and leave them alone.
When you're working on a texture, say this texture is a 2048*2048, you export it using the CryTiff exporter, say change your parameters to NormalMap_LowQ, 1024*1024 on PC, and 512*512 on console.
It will export a .TIF file, if you open this file in photoshop, it will be a 2048*2048 texture.
Now, a couple seconds after exporting, the RC will also generate a .DDS automatically, with the same name, and this will be a 1024*1024, this will be the texture that the engine will actually use in the game, ALTHOUGH in the material editor you input the .TIF, not the .DDS.
If you run a build on a PS3 or XBox, the .DDS on the build will be a 512*512. (No TIF files are ever put in the .PAK files of the builds)
Replies
I found out this trick by myself and havent done much testing with it so im not sure if its a perfect fix but its worked so far for me.
So basically, you should ignore the DDS's, these files are generated automatically by the RC (Resource Compiler) so, just ignore them and leave them alone.
When you're working on a texture, say this texture is a 2048*2048, you export it using the CryTiff exporter, say change your parameters to NormalMap_LowQ, 1024*1024 on PC, and 512*512 on console.
It will export a .TIF file, if you open this file in photoshop, it will be a 2048*2048 texture.
Now, a couple seconds after exporting, the RC will also generate a .DDS automatically, with the same name, and this will be a 1024*1024, this will be the texture that the engine will actually use in the game, ALTHOUGH in the material editor you input the .TIF, not the .DDS.
If you run a build on a PS3 or XBox, the .DDS on the build will be a 512*512. (No TIF files are ever put in the .PAK files of the builds)
So the .TIF works as a reference for the .DDS's.