|
Hi All,
I have the problem stated in the subject line - I know what’s causing it, but not which part of our pipeline it happens in, or how to avoid it…
Our artist is sculpting a model in Mudbox (2009), importing this into Max (2009), then exporting as an ogre mesh using OgreMax (1.6.23/1.7.0).
The problem we are seeing is that Mudbox uses quads, and the model which ends up in Max is using quads, but when we export a triangulated ogre mesh the vertex normals are “"incorrect"” and causing lighting problems because it appears to re-calculate the vertex normals after triangulation.
Please see the attached image - I’ll refer to the sub-images below:
What you can see in the images is the floor of a tunnel - it’s a bit hard to see what’s happening because there’s pink stripes drawn across the floor, but the floor is actually going up and down: if you look at 1B and 2B the faces I’ve highlighted in green are facing toward the camera the red ones are facing away from the camera.
If you look back to image 1A, you can see four or five slightly dark patches across the stripes on the floor - these aren’t part of the texture map. If you look at image 1C I’ve circled one of them in red. There are actually patches which are lighter than they should be as well but they’re not so obvious (one circled in green).
Now these ridges across the floor are pretty uniform - one side points slightly toward the camera and the other points slightly away, so all the vertex normals in question should point straight up for smoothing purposes (but they don’t => problem). To understand the problem, if you look at the red circled vertex in image 2C (which relates to a dark patch) it’s got 4 triangles connected to it which point away from the camera, and 2 triangles connected to it which point toward the camera, so the resulting vertex normal is pointing slightly away from the camera instead of straight up because of the 4:2 triangle weighting (ie: it points away because there are more tri’s connected to it pointing in that direction).
The green circled area has the opposite problem (ie: 4 tri’s pointing toward and 2 away, so the normal points slightly toward), and the purple circled area is just fine because it’s got 3 tri’s each way.
Three possible solutions occur to me:
1) Get mudbox to produce a normal map for an unsmoothed version of the triangulated mesh, in which case the bogus normal map would fix the bogus mesh normals and look right (assuming we have a shader on it that renders the normal map). I think this works, but it’s *really* not the solution we want.
2) If all the quads were split the same way into tri’s (eg: all split top-left to bottom-right), then all the vertices would be like the purple circled one and it would look fine (in most places). Again, this isn’t really a fix - it’s just an attempt to avoid the problem. I assume the generation of the new quads in Mudbox is what decides which way they will be cut into triangles?
3) The correct solution seems to be to generate vertex normals from the quad-mesh, and then retain these vertex normals when the mesh is triangulated.. this is because the quad-based vertex normals will always be “"correct"” because for example in the image shown there will always be two quads connecting to the vertex which point away, and two which point toward the camera. This is what I’d like to see happen, but I’m not sure where the triangulation and re-calculation of the vertex normals is happening at the moment, or how to control it.
Any thoughts on how to achieve “3)”, other fixes, or just feedback in general is most appreciated.
| Attachment
|
|
| 
