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.
Friday, October 17, 2008
Wednesday, October 15, 2008
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.
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.
Subscribe to:
Posts (Atom)