(#10)NormalMaps-- pitfalls
-
Topic authorJohn Van Vliet
- Posts: 2944
- Joined: 28.08.2002
- With us: 22 years 2 months
(#10)NormalMaps-- pitfalls
--- edit----
Last edited by John Van Vliet on 18.10.2013, 10:44, edited 4 times in total.
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
Re: NormalMaps-- pitfalls
John,
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...
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...
-
Topic authorJohn Van Vliet
- Posts: 2944
- Joined: 28.08.2002
- With us: 22 years 2 months
Re: NormalMaps-- pitfalls
--- edit----
Last edited by John Van Vliet on 18.10.2013, 10:44, edited 2 times in total.
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
Re: NormalMaps-- pitfalls
john Van Vliet wrote:
i like the ppm output for very large files. ( my personal preference )
I work on 64k and 128k maps in Nip and a png that size takes all night to load even with 8 gig ram .So a ppm works for me .
John,
you sure know that png and ppm are close relatives. The reason why the PNG output of nms (nmstiles) gives you slow loading for large file size is the fact that unlike ppm PNGs are usually highly compressed. The decompression then takes a long long time for large files!
In my nms (or nmstiles) you just modify one statement
png_set_compression_level(png, 4);
to no (or mild) compression
png_set_compression_level(png, 0);
and the loading will be fast as for ppm.
I chose png_set_compression_level(png, 4) because the level 4 is a good compromise between speed and size.
Fridger
-
Topic authorJohn Van Vliet
- Posts: 2944
- Joined: 28.08.2002
- With us: 22 years 2 months
Re: NormalMaps-- pitfalls
--- edit----
Last edited by John Van Vliet on 18.10.2013, 10:44, edited 1 time in total.
Re: NormalMaps-- pitfalls
john Van Vliet wrote:A thought ( i have not done this yet ) that might work
"Fictional Clouds Map" post points here
there is a possible solution to using the Photoshop nvidia plugin or the Gimp plugin on google code
John, I've linked here because its importance. I do not find clues about such issue on the GIMP's normalmap plug-in Google page.
Never at rest.
Massimo
Massimo