Re: [Plib-devel] ROAM for plib

[Tom H. <to...@bi...>]

At 12:02 AM 4/6/2000 , you wrote:
>Sam Stickland wrote:
>
> > And then I'd like to add frame coherence to it would be would nice, and
> > doesn't sound that hard. (Basically instead of recalculating your triangle
> > mesh every frame you adjust the previous one to fit.
>
>Hmmm - but I'd still want FOV culling on the individual ROAM height grids
>(there could be many of them in an application like FlightGear where terrain
>is paged from disk).

This can be done.

>If a ROAM 'object' is entirely off-screen, then the ROAM algorithm would
>not be executed on that frame for that object.  I really think it's important
>to work that way.

The way you do this is you have each square section of terrain as an 
object. Each object contains two ROAM Bin-tri trees and pointers to its 4 
neighbors. After you've culled each object to the view frustum (AABB works 
great) you take a quick pass through the visible objects and check 
neighbors to see if they're visible. The pointers inside the bin-tri trees 
that point to neighbors would be set to null if neighbors are culled, and 
the pointer to the neighbor if not.

For split only engine this works great. For a frame coherent model what is 
usually done is the objects that are off the screen have their priority set 
to 0 so they are tessellated as little as possible. This is easier than 
trying to find all the neighbor pointers in the tree and set them to null. 
This adds a several hundred triangles that will be clipped by the API to 
the rendering of each frame. This is probably acceptable.

> > And at some point in the future I'd really like to adjust ROAM to work 
> in 3D
> > rather than just 2D so I can add stuff like caves and tunnels to the
> > landscape engine, but that's a far way off at the moment.
>
>That would be very cool.  Sounds tricky though.

Very much so :) If he has a cool plan for it, I'd love to hear it (although 
the algorithms list is probably a better place for it).

>If each ROAM 'object' is independent though, you could build things like
>caves by having a height grid for the floor, another (inverted) one for
>the ceiling and a third for the surface of the ground above the roof
>of the cave.

The problem is defining how the ceiling and the floor come together. I 
don't see how two height fields opposing each other can be used to make 
convincing walls in a cave, but I guess its better than nothing :) If I was 
to go with a full 3D scene I would leave height fields behind and go with 
something else (Beziers with displacement maps perhaps).

>That's nowhere near as nice as a full 3D implementation - but it certainly
>makes caves and overhangs do-able with the present algorithm.

It seems like the area where the two height fields come together would look 
"bad".

Tom