I'm trying to use a normal, specular and watermask map for my Cinema 4d Earth Scene to get the best visual result. Hence, tiled versions are not usable for me. I even thought about putting the tiles together in Photoshop but then I tried the tools from Fridger:
Unfortunately I am unable to get correct results with Nm and F-texTools when I try to create big maps on my system.
The test file (4k) for Normal worked fine but when I try to create 64k maps the resulting Normal map looks disastrous - I did not get any error messages...
The specular map looks incorrect as well.
Gzip was also not registered in registry but that is the least of problems because I have Winrar - so I can and did it manually.
I am using W7 ultimate x64 with 14gb ram along with 2x physical Quads.
I have the watermask by cartrite in 84k so I actually only need the Normal and the specular Map to improve my scene in C4D....
The command prompt was new territory for me so I invested about 8-10h so far... without a usable result
Is someone, please!, willing to share a Normal and Specular Map in 64k, UNTILED!
I'm registered with 4shared - they have 15GB of free space.
Help will be much appreciated!
Welcome at CM, Martin!
Your report sounds depressing...
What do you mean precisely with " the 64k Normal map looks disastrous" ??
If it looks somehow "scrambled" then most probably you made a mistake related to the "Endianness" that becomes relevant when dealing with 16
bit binary numbers (elevation map!!).
As clearly discussed in my tutorial:
My Tutorial wrote:
First of all, you need to download the 1.2 GB gz-packed input heightmap of Earth from the NASA Arctic server. Here is the link, ready for clicking.
Remember, unlike our 4k warming-up input heightmap above, this file uses 'big endian' storage mode of its 16 bit integer height values.
Hence if you copied the command line parameter of the 4k example straight into your 64k task with only the widths values adapted, your result will look scrambled!!!
In conclusion, for your present 64k task, all 'little endian' machines (Windows PC
, Linux PC, Intel Mac) need to insert the byteswap = 1 option
in the first nmtools command of the "pipeline".
The first nmtools command is concerned with a reduction of the 85k elevation map to the nearest power-of-two size, i.e. to 64k. Adding the endedness compensation flag, the correct command line for a Windows PC
looks like so:
nm2pow2 86400 1
< srtm_ramp2.world.86400x43200.bin | nms 6378.140 65536 2.5 > normalmap64k.png
I here have assumed that you unpacked the input heightmap separately and that the 64k normalmap file is called normalmap64k.png.
For a 'big endian' PPC MAC, the byteswap=1 compensation flag above would NOT be necessary, of course!
If you used a different command line from the one above, please let me know what was so difficult in writing this correct one? I have emphasized the Endianness issue even in two places, in order to hopefully avoid people stepping into this "trap":
1) Detailed discussion in the Tutorial!
2) Upon running nms without any parameters, a help text is first printed and then at the bottom:
Your computer uses +++ Little-endian (Intel-PC, Intel-MAC,...) +++ byte order!
If different from byte order of input file, use byteswap = 1
I have never heard of a Celestia user who would want to consider 64k UNTILED textures. The upload takes hours due to the asymmetry in up/download speeds.
A 64k RGB Normal map in (stage 9 packed) PNG format will be close to 10 GB!
That's why I wrote my tools: to make people save a lot of upload / download time and to hopefully make them understand a bit better how some things work...
To me it looks highly probable that you made some kind of error (Endianness!?) when dealing with the 64k Normal map amd Specmap tasks. In my tools there is NO reason why 4k jobs should work while 64k jobs give nonsense. The tools have actually been written for handling 'monster' textures! If you made the presumed Endianness mistake it would also have affected the 64k Specmap generation.
Of course I can only help specifically, if I see the command lines that you ACTUALLY used as well as the links and other operations for getting hold of the input elevation files.