I've rewritten my tree-building code to take advantage of the precalculated vertex array.
Now I've completely broken my previously-working code and everything is a mess.
This is daunting, and a little depressing, but it's also something I've gotten used to with this kind of project.
This is what happens when there's no plan to follow.

Speaking of following, I find myself walking very well worn paths, and it makes me unhappy.
As a programmer I usually choose NOT to walk the well-trodden path.
Since I used a relatively conventional approach to hierarchical subdivision of the terrain, and then used a relatively conventional implementation of DLOD, I have run into several typically conventional problems.

"Now's not time to make a change - just sit back and take it slowly".. BAH!

I've decided to scrap this entire project in its current form, and explore some new ideas.
In particular, I have a new idea for a realtime tesselator based on sparse heightmap sampling.
The idea was conceived from several sources : my previous idea regarding 'Sparse Radial Oversampling', Hughes Hoppes' paper on GPU-driven 'geometry clipmaps', and most importantly, my experience working with the View Frustum.

Attached is a really crappy image that doesn't really explain anything.
This concept is still in its infancy, and I would LOVE to hear your thoughts!

Essentially, the idea is based on the fact that we can transform a unit cube into a 3D frustum, or a unit square into a 2D frustum.
We define a grid of points in 2D, based on a unit square, then transform them as for a frustum.
The resulting 2D points become 'stretched out' as they become more distant from the camera.
Now we sample our heightmap using those 2D points and our cool bilinear pixel fetch method, build an array of vertices from those sample points, and tesselate between them.
Let's explain that in more abstract terms, to make it clearer.
What we've done is draw a scaled theoretical 2D frustum over the heightmap, identifying the visible heightmap pixels, then we've interpolated some samples within that region, with more samples taken toward the nearplane of the frustum and less toward the farplane, then we've tesselated between those sample points to produce one frame worth of geometry which remains valid until the view changes.

We have to do all this every time the view changes (ie as we move and/or rotate), but lets be objective.
Firstly, we can sample between actual heightmap pixels, so we have nice resolution.
Secondly, the number of triangles produced altogether isnt huge, no more than a few hundred, tops.
Thirdly, we no longer need a huge array of vertices, OR any kind of subdivision tree, so we have saved massively on memory, eliminated precomputation, theres no lookups, theres no tree walking, and theres no culling.
Fourthly, in respect to this EDITOR project, we tend to stop moving to paint the world, so while we're painting, we're probably not being forced to perform any view-dependant re-tesselation.

On the sad side, we have lost the ability to perform simple collision tests against offscreen geometry.
Each and every moving object is going to have to track a small chunk of the world around it, in some way.
But I think its worth it, given the tradeoffs.

Posted on 2007-11-20 21:53:37 by Homer
..looking like an oldschool voxel based terrain raycaster

..cept you will build a vertex buffer instead of writing pixels to the back buffer

Posted on 2007-11-20 23:37:53 by Rockoon
The idea is similar to raycasting, except we're not casting rays (say, from screenspace into worldspace) and looking for intersections.. we're mainly working in 2D, we describe the view frustum as a four-sided polygon in 2D scaled for use as a mask against the HeightMap, and then we plot points along some 2D rays between the two edges representing the near and far planes of the view frustum, to find at each step a floating-point 2D coord used to sample the heightmap and generate a vertex which will appear in the tesselation. This algorithmic method of selecting our sparse sample points avoids us needing to transform a uniform grid of points, and gives us more flexibility and control over the way our pseudo-LOD falls off with distance.

The visual artefact I expect to see is something similar to that which can be seen in a low-resolution geomorphing example, in which some vertices appear to be (and indeed are) moving slightly as the view changes.
However, in this case, the vertices will be static with respect to viewspace, and so there might not be any visual artefact to worry about at all, just have to try it and see :P
Posted on 2007-11-21 00:14:12 by Homer
I'm going to create a whole new project, this time I'll be using the DXSetup application framework from OA32, rather than a 'bare bones' d3d app framework.

I'll be starting at a different place too, my first goal will be to draw an orthographic textured quad to show the entire heightmap, and show the view frustum as four 2D lines drawn over it.
The map should support 'zooming' via UV manipulation, so that will complicate the drawing of those four simple 2D lines.

Once I've done this I'll be satisfied that I can generate view-dependent tesselations without having yet accomplished it, and I'll have a nifty overhead map for my interface which will be alphablended over the top of everything else.

Posted on 2007-11-21 00:51:45 by Homer