(#10)NormalMaps-- pitfalls
Posted: 01.09.2011, 05:24
--- edit----
a few comments, perhaps. The adaptation from 16bit signed to 16bit unsigned integer input is a trivial 1-line change and thus barely worth big words. This modification has been discussed here and at CM repeatedly, and can be easily implemented by anybody knowing about the basic use of a C++ compiler.
The really strong aspect of my tools is their high speed, their optimizations and notably their memory handling that allows to deal with "monster" textures >=64k (in only about 15-20 minutes)! The gimp or NVIDIA normalmap plugins only work for much smaller "baby" sizes (<= 8k?). Also, how about LittleEndian and BigEndian machines? My tools work automatically for both (Intel PCs and certain MACs).
An important optimization concerns nm tiles that only contain parts of oceans. Since the sea is strictly flat (locally and neglecting waves
), the corresponding normalmap ( = gradient!) is monochromatic and hence can be replaced by a tiny 4x4 pixel (template) tile. Since e.g. Earth's surface consists predominantly of oceans, there are large savings indeed...Last not least, the latest version directly outputs optionally the high-quality compressed, normalmap format .dxt5nm! Meanwhile, that format is indistinguishable visually from lossless .png, but is supported by the graphics hardware and by Celestia. This way "monster" VT sets appear "butter smooth" also on low-end computers...
Fridger
PS: my old nms and nmstile tools are about a factor of 2 slower than the more recent ones that Christophe, Dirkpitt and myself have jointly tuned with lots of tricks...