I don't actually see any normal mapping there on the last pictures. I'm also a bit confused, since only one image posted by vpmedia actually seems like a normal map (the radiosity one). Also, 1024^2 is rather insufficient resolution for good, detailed normal mapping on something like a fighter aircraft. Fine for testing purposes, though, I suppose.
At any rate, your code seems to be working based on the earlier example, it's just that generating normals from a texture is an exercise in futility and doomed to failure. There is
no possible way to generate good height maps from diffuse texture information alone, and if you're working just with textures, you need a good height map to generate a good normal map.
If you don't have a nice height map available you kind of have to craft one yourself.
The other path is to create a high detail model with same UV coordinates as lower detail model, bake the high detail to a normal map, and then use that on the lower detail model.
That said there are some ways to improve the results you get from a diffuse->height->normal conversion. Here's what I ended up with, using the given height map as a source:
Stainless, normal maps are probably something that only few people would be interested in modding. As such, I think it would be prudent to optimize the quality and performance of the normal maps over ease of use.
Two things you need to decide are channel assignments, and file formats. The basic RGB normal map format usually stores the normals information in red and green textures. Some applications leave blue channel completely white (blank), some store some occlusion information there (which basically looks a lot like a faint trace of the height map in most cases).
For the purposes of normal mapping in tangent space, only the normal data is used, leaving the blue channel as ballast unless you decide to store some other information there - like glossyness map, for example.
Another popular arrangement of channels is to use RGBA textures, and store normal map information on green and alpha channel. This ensures compatibility with a popular way to use DXT compression for normal maps (DXT5nm to be precise).
You could also use either 3DC (two channels, independently compressed) or u8v8 (two 8-bit, uncompressed channels) since for tangent space normal mapping you only need two channels.
Of course, it would be ideal if the program could identify the normal map type from the file input and assign the normals data appropriately from there. Basic identification by headers, number of channels, that kind of thing could be used to tell the program where to look for the normals information. That way, all of the above options could technically be valid.
For sanity reasons I would suggest just using basic, uncompressed RGB textures (like the one I posted) as a WIP phase format. It is so much easier and faster to work with them than one of the more exotic varieties, even if the other formats would offer better performance.
Author
Topic: Normal / Bump mapping (Read 13390 times)
