Buzz wrote:Good to hear you have lots of C experience! Fridger wrote earlier in this thread:
"you changed the conventions in your readS16() relative to Chris , e.g. for MSB (big endian)
Chris would use in your notation:
return (short) (b) * (1.0f / 65535.0f);
You used:
return (32767-b) * (1.0f / 65535.0f);
which reverts the normal map relative to Chris. "
I hope this helps!
Alas, I made the above change, and generated a 64K normal map on the optimistic assumption that this would fix everything, but it didn't. When the earth is lit from the east, the mountains are illuminated as if from the west (or, alternatively, they have become canyons). [LATER EDIT: I was wrong about this. The shadows are right. With the suggested (32767-b) fix, the windows version of nm16 works fine.]
On further thought, it really doesn't make sense that a (b) vs. (32767-b) could have addressed an endian issue.
The windows version of the nm16 executable already had provisions for big vs. little endian anyway, in the form of a command-line option. The documentation for that option specifically addressed the data set I was working with, so I'm pretty sure the endian-ness of the data has been properly accounted for.
Since I know nothing about the theory of normal maps, it's going to be pretty hard to debug this problem. Can any normal map gurus take a look at the nm16win code from Pixel's link above, and tell me what to fix?
Thanks,
Tim Crews
P.S. In addition to the fact that it's inverted, the 64K normal map does show more flaws than the 32K map did. In part, this may be because 64K really exceeds the native resolution of the (43K) raw data. But it might also be because I skipped the two-step resizing procedure. I'll re-write my scripts to do that, but I'll wait to run them until I'm pretty sure I know how to use nm16.
) And the right edge of the generated normalmaps shows a 1-pixel artefact 
