Page 7 of 10
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 11:37 am
by JohnWordsworth
I'm sure Leki posted something about this recently. From his experiments, it sounded like the normal map data was simply packed into the texture files differently (using only two channels and recreating the third on the fly?).
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 11:48 am
by Phitt
Tried with the dragon statue model from LoG 1 and it's the same problem, so I can at least be sure it's not a problem with my models.
http://cloud-4.steampowered.com/ugc/548 ... 0617D0000/
JohnWordsworth wrote:I'm sure Leki posted something about this recently. From his experiments, it sounded like the normal map data was simply packed into the texture files differently (using only two channels and recreating the third on the fly?).
I'm not sure I understand that. Instead of a red, green and blue channel it now only has two channels? Doesn't sound like that would work, so I guess I just don't get it.
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 11:54 am
by petri
Oh yeah, that's it. Normal maps are now DXT5 compressed so that G is Y vector and A is X. The Z vector is reconstructed in the shader. Saves a lot of memory.
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 12:13 pm
by Phitt
petri wrote:Oh yeah, that's it. Normal maps are now DXT5 compressed so that G is Y vector and A is X. The Z vector is reconstructed in the shader. Saves a lot of memory.
Tried to save the normal map in DXT5, but the lighting is still weird for some reason.
We used DXT compression a lot while modding Elder Scrolls (Bethesda's texture are all saved as DXT). While it is true that it saves a lot of memory it is also true that it can create some really ugly artifacts at times due to the compression.
Here is a good example of what DXT compression can do. I have to admit that I didn't notice any in Grimrock though, so maybe I'm simply using the wrong DXT5 format (I used the regular DXT5 ARGB) and that's also why I still don't get the correct lighting?
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 12:23 pm
by petri
Using DXT5 with Y in green and X in alpha is pretty common trick. Compressing normal maps as RGB results in horrible compression artifacts.
We did pretty extensive tests with our content before choosing to use normal map compression. Overall the gains we huge (several hundred megs saved) and the artifacts are pretty small.
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 12:26 pm
by JohnWordsworth
EDIT: What Petri Said. Lol
@Phitt: You might have to do some magic with the different channels in Photoshop. If you load up a normal map texture from the LOG1 asset pack, you will need to swap some of the colour channels around (red channel -> alpha channel IIRC) and then black out the other two channels.
In terms of quality, I guess there is nothing stopping you from using an uncompressed format (apart from massive memory wastage from having two full, uncompressed colour channels in memory) - it's just that the game will read normal data from the specific colour channel of the texture (regardless of whether it's compressed or not). I believe that the Green and Alpha channels retain the most information in DXT5, hence the decision to stash the useful data in those two channels and then ignore the other two (which compress really well in DXT5).
Leki's original post is
here.
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 12:27 pm
by Phitt
petri wrote:Using DXT5 with Y in green and X in alpha is pretty common trick. Compressing normal maps as RGB results in horrible compression artifacts.
We did pretty extensive tests with our content before choosing to use normal map compression. Overall the gains we huge (several hundred megs saved) and the artifacts are pretty small.
Ah ok, with DXT5_nm it worked. And I can see now why it doesn't create compression artifacts. In Elder Scrolls games the specular map is stored in the normal map's alpha channel, so they can't do it that way. Saves even more memory, but the results are sometimes really ugly. Thanks for the help, nice to know that I can 'convert' static models now.
EDIT: @John Wordsworth: Thanks, but I simply didn't know about that trick. The quality is fine (that's why I wondered why I didn't see any of those ugly compression artifacts in LoG 2 that are really common in Bethesda games), no need to use an uncompressed format now that I know how it works.
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 1:13 pm
by petri
Updated the scripting reference with asset definition functions. Have fun!
Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 2:08 pm
by gambit37
petri wrote:Updated the scripting reference with asset definition functions. Have fun!
Fantastic! This is going to be so valuable... thank you

Re: Scripting Reference (work in progress)
Posted: Wed Nov 05, 2014 2:10 pm
by petri
Hey Matt! Great to see you here! When can we see the first Grimrock mod from you ?
