Normals Appeased

I finally decided to use the standard mesh layout for height maps instead of the diamond pattern you see in ROAM implementations and the normals now look fine. Before switching to this standard triangle layout I tried several other normal calculation methods, but still got those ugly cross hatches that you see in my previous posts.

Here's what the normals look like fixed:


And the wireframe version:


I still need to cache the vertex normals and tangents for the edges of each mesh to make the transition from large meshes to smaller resolution meshes seamless. Right now there are seams that I had fixed in my previous version that used the diamond pattern mesh.

After I fix that I plan on moving from a static image that is loaded from disk to a random image generated by the program so that I can test different planets.

After getting that working I'll need to fix some issues that come up when calculating normals that are on the edges of two (or three) faces. I will probably do some kind of vertex normal/tangent sharing similar to how I will share edge normals between separate quad tree nodes on the same face.

Here's a cute screenshot I took when debuggin the normals:

One Lumpy Planet

I spent a long time with a pen and paper and a calculator (and a debugger) to get a heightmap imported as a material and as a, well heightmap for the mesh.

Here's where I've ended up so far:


And this is a version with wireframe overlay:


The quality of the normals is not very good because I'm using this cheap cross calculation that I saw on GameDev whilst reading this informative article on normal calculation algorithms by Jeromy Walsh. It's a very simple algorithm, but it doesn't seem to work well for me and I think I will try the MWA method next.

For the heightmap I'm using a 1025x1025 pixel grayscale 8bit png (or similiar raw). I divide that up to get the heights for all the vertices. It did not occur to me at first that quadrants share vertices (duh) so I didn't have their heightmap bounds overlap at first and that threw everything out of wack. Once I fixed that though, I discovered I need to store the heights for the neighbor vertices to calculate normals correctly. That also took a while to get the algebra to where I wasn't causing memory access errors.

Before I got the neighbor heights in there for normal calculations I got this quilt effect:


I still don't have the calculations correct for getting the correct 3d positions of neighbors across faces, but that's on the list. First, however, I have to fix the normal quality and the problem I'm having with quadrants at different levels having higher resolutions for their normals and that causing a seem - ugh. Hopefully, improving the quality of the normals and always assuming there are no neighbors at the edges will work.

I also fixed a memory leak, but I think I still have some minor ones left somewhere - but that's for later.

It's great to be able to actually fly around a bumpy planet now, even if it does have crazy normals.

Project Refresh

My laptop got stolen argh. Fortunately I had backups and didn't lose anything, however, after re-installing everything on the new laptop I decided to start fresh. The reasons for that were that there was a new version of Ogre out and I ran across some posts on the Ogre forums about other developers doing the same thing with Ogre.

So this time I started with the OgrePlanet approach to creating a mesh from a movable and renderable derived object and used an index cache to store the 16 possible index orders (four sides of a square and each can be stitched or not). I also started out with my own neighbor and mesh creation algorithms just so I could really understand them and after I got them working, I realized that Sean O'Neil's algorithms were better thought out (he did spend years on the project), less crash prone, and more efficient.

So I re-implemented the quad tree node neighbors and then implemented the stitching and the index cache. Next up is normals and then either a simple texture job and/or heightmap building/importing.



This image shows what the planet mesh looks like when the camera is near the surface. It's hard to see in a small picture, but the mesh has no cracks. The tri count ranges from 3,000 to 20,000 currently.