The PC I’ve been developing on for the last few years has finally been relegated to the sidelines as an entertainment PC (9800xt, AMD2800+). The new behemoth will spring into action on Tuesday and I’m really looking forward to seeing what it can do with my planetary terrain. In preparation I’ve been multi-threading the terrain engine, my new processor being a quad core (the Q6600). Sure there are faster processors around with two cores, but four cores is where I can really begin to push some limits. Below is how the terrain engine looks now, with an ice cold moon showing some traces of a frozen substance (not necessarily ice water).
Well Christmas is nearly here. The tree is up, and if it’s anything like last year it will probably stay up until April next year. I am so lazy!
I’ve done some more work on my planetary LoD algorithm, I’m now very happy with the detail and speed I can get out of it, although it can still be improved. The optimization of meshes is both a benefit and a hazard. While they make it very GPU friendly, my implementation was somewhat naive and caused a little too much ‘think’ during mesh construction. I’m well on my way to fixing that now though which will give a dramatic increase in performance. The net effect now is almost as though the planet were being streamed, which in a sense it is, but of course the data is all generated procedurally from a single seed. Currently that data is generated with 20 octaves of simplex driving ridged multi fractal. 20 octaves is actually a little less than I usually use (25 is optimal for <1m detail) but simplex has the attractive effect of generating smooth curves when it bottoms out of it's octave range.
Little Video!
My last blog entry contained a screen shot of my planets surface from an altitude of a few kilometres. Of course that’s still not low enough if you’re going to be landing spaceships at space ports, or even going for a stroll. The key problem here is imprecision at the scale of planets. Floats don’t cut it. Now doubles come to the rescue, but graphics cards think in floats. Your average first person shooter doesn’t worry too much about running out of scale in floats.
Just a quick entry. I’ve made progress with the meshing scheme, and it’s accelerated the terrain engine to the stage where I can fly around near ground level at ~200 frames per second. I haven’t even implemented the parent->node data inheritance yet so I am still generating twice as much noise() as I need to. I’m extremely happy with that speed. Still not using the textures to add detail to the scene, which will improve both the lighting and obviously tremendously increase the visual detail. Again, each terrain mesh is randomly coloured to aid visualization.
I’m still experimenting with quad tree planets, and I’ve implemented the first few ideas I had to optimize them. The first optimization I’ve made involves the meshing of the planet. There are two steps to this. Firstly I don’t rebuild any meshes or vertex buffers unless a split or merge has actually invalidated them. Secondly, and this bit is still experimental, I bunch all the nodes below a certain point into one mesh, for fewer rendering calls and better optimized vertex buffers.
Continue reading ‘Round one of Quad Tree planet optimizations’
But I only just went to bed.
It’s 6.45 in the morning. It’s cold, and it’s still dark. The street lighting is still on casting its own unique melancholy about the dead streets. When the snow comes it will be quite picturesque I suppose. The only faintly optimistic thing is the sound of the coffee machine completing it’s pre-programmed cycle, the jug almost full of my liquid addiction.
I think I have tried just about every single kind of planetary level of detail algorithm in existence in my quest for the perfect planet.
My current experiments hinge on adapting Sean O’Neil ’s planetary QuadTree method. My previous planet used an implementation of Roam 2.0 (essentially a Roam planet but with a chunk of 16 triangles per ‘Roam Triangle’), and while it threw out tons of geometry, it was almost impossible to obtain good normals for because there’s no simple relationship for internal triangles bordering other chunks. It was also not very texture friendly. The advantage of the Quadtree approach is that it solves both these issues, though it isn’t as good at generating masses of geometry.
The interesting thing about writing something that you hope nobody will ever read, is how much effort you end up putting into it.
Now that I’ve built up the expectation that I will succeed in slipping these words past the world un-noticed, for the purpose of laying out this virgin blog, I find myself increasingly paranoid that you, oh inquisitive reader, will lay foul to my plans.
So if you’re here (and why are you here?), be comforted that here is probably not where you wanted to be, so your unhappy misfortune to arrive here by accident is not a measure of your taste, or lack thereof. If however, you have arrived here from the murky past of whence this site was born and then razed in the inferno of the fleeting attentions of the internet - be content in the knowledge that what you’re looking for, or at least something interesting, will be here soon.

Latest Comments