World Machine Community

News and Development => Feature Requests => Topic started by: hogjonny on November 19, 2008, 03:00:40 pm

Title: Normal Map Generation, heightfield output - Diff against mesh output
Post by: hogjonny on November 19, 2008, 03:00:40 pm
For our game content, as an example, I spitting out data in multiple passes at different resolutions.

For example:

As is common, I am compressing my normal maps (removing black) and using them as tangent space normals.  I have shader settings to tweak the amount of normal bump rendered on screen in the, and as a result with this output I can manage to get everything to look OK.  However, I know that the normals are not technically correct, as they are based off of a flat plat and not the mesh output I am importing.

As a result, sometimes I can see where the normals are abnormally 'bent' when rendering on screen in our real-time.  This usually occurs on steep slopes, which makes sense as that is where the most extreme normal deviation would appear on the mesh normals to begin with.

What I would LOVE is a modified normal map output, which could know about or store information about the mesh tile output resolution I am using and then diff the normal output against them when outputing the maps.

Currently we are living with the output normal maps as is, but some point down the road we are likely going to have to find a solution to account for and correct the anomolies.  Which would probably involve us outputing the mesh normals into a texture, then processing the mesh normals against the WM normal maps and outputting a corrected texture.  (some sort of baking process, like transfer maps in maya, or an offline tool.)  But ideally, it would be great to have exactly what we need come out of WM directly rather then add additional steps into our pipeline.  WM out --> 3D app import, done.

*note:  we smooth the normals on the mesh, and average normals across tile edges.  This would be important and necessary to take into account in WM to output correct normals based on the mesh output.

Anyone have thoughts on this?