Hope that title isn't misleading, but I've been working on this project off and on for a while with varying degrees of success. I've recently hit a snag in the project, or what I perceive as one, and I've also promised to release this code for a while. I figure I'd kill two birds with one stone here and try to get both done at once.
The project is basically just building planets to use with Ogre. I use a quad-tree based method that breaks down heightmaps and then projects them onto a sphere. It works pretty well and is fairly fast even on my 2 GHz machine, 512 MB RAM and Radeon 9600.
There's a problem, though. Everything has gone very smoothly up until a few days ago. I was testing the application from a slightly different angle - I would usually build up the map instantly (skipping any sort of queue) and tearing it apart in the same fashion. It worked fine, but I recently added the queue and actually let it run as if it were a real application - that is, I let the LOD/Camera system take over. It worked great... until I started accumulating a lot of stuff into memory. I started noticing some weird things, like when I let the program randomly build further than I would let it go in a real test and it would get to maybe 200 MB of data in memory... then suddenly drop to 33 MB. Well that's odd... Next, and this is the killer for me, the quad-tree neighborhood breaks.
Now, I'd normally attribute that to a bug, however the whole system is designed that all the children are self-similar, meaning if you were to section off a child and it's children, it would look exactly the same as the Root node and it's children/neighbors. The problem that occurs changes and isn't repeatable to the exact same error every time. It randomly chooses which depth it occurs at, which node it occurs in, which STEP it occurs in and even which neighbor it looses track of.
Again, this could just be a bug and I'm not reproducing it correctly, but I also tested my system's RAM (after one of my sticks stopped working, I was now left with 512 MB from 1 GB) and found something that didn't please me: I had memory errors. Horray, more broken parts I can't afford to replace! So, now I'm left with another possibility: the code works fine, just like it should, but the memory is eating nodes somewhere and I can't actually track it because the physical hardware is causing the problems.
So, here's my proposal: the code is already LGPL, you can fiddle with it to your hearts content. I'd like to receive any major upgrades you do to the code and any bug fixes, if you'd be so kind. I'll be working on the code myself and will make regular updates as I can, but any feedback would be most welcome. The thing of it is, though, this bug may not be a bug - it may just be my craptastic computer. I'd like to know if YOU can reproduce these results on your end. The specifics are as follows:
1.) The code almost always bugs out when I make it build up many levels of the quad-tree, usually 10+ deep.
2.) It only really happens when I pull away from the ground in a hurry.
3.) The debug version will throw an error 75% of the time when it's using the BuildQueue::adjustLOD() function.
4.) If you look at the Terrain's QNode parent (pTerrain->getParent()) and look at it's neighbors (mNeighbors[0-3]) you'll see one of them is bad!
You'll see one listed as 0xfeeefeee or something like that and it won't be evaluable.
That's about it for that - if it turns out to be a bug, then I'll probably scrap the neighbor system and use another method I have in reserve. It's not quite as fun, but it should do the job (or kill me in the process.)
Here's a shot from the very unfinished system:
As you can see there, the LOD code is sort of working, but not all of the cases have been taken care of. This is also baffling me as the LOD code WORKS with the quad-tree neighbor system all the way down... it just seems to break at the weirdest times...
Anyways, here's the code and media - check the Readme file first as it'll tell you what you need to do. The only thing I forgot is:
You need to put that Front.raw file in your Release/Debug folder. That's the master map for that planet-face.
Enjoy and don't throttle me for the lack of diagrams - they will come soon. Promise