Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

[Steve B. <sjb...@ai...>]

Jon Anderson wrote:

> I've posted the code at:
> http://innovation3d.sourceforge.net/roam
> 
> I also put up some screenshots so you could see how it looks so far.  =)

Looks good!

> I'll try to explain how it works.
> 
> The ssgTerrain is a sub class of ssgBranch.  It basically is a loose
> encapsulation of ssgPatches, which are what contain the ROAM logic.   I used a
> branch rather than a leaf, because I thought it would be conceptually nice to
> be able to add other things to the terrain, such as buildings, trees, etc.
> This might also allow the terrain to tesselate a little higher around those
> objects, if needed.

Ah!  *Now* I see why it needs to be a branch.

(For the uninitiated - since the terrain polygons in ROAM are constructed
on-the-fly depending on the amount of detail is needed (as a function of
range, etc) - the actual polygonal surface is in fact flexing up and down
as you move towards it.  This is (hopefully) set up so you can hardly
see it happening.  HOWEVER, if a tree or a house is planted onto the
terrain - and the terrain flexes like that, it can leave a noticable gap
beneath the object or bury it underground.  Those things are VERY noticable,
so it's possible to tell the ROAM algorithm to keep more terrain detail
around places where 3D objects are placed - specifically to avoid this
artifact.)

> Each patch is:
> 1) An ssgVtxTable representing a quad for the water line.
> 2)  A TriTree structure attached to the ssgVtxTable as user data.  It is the
> TriTree that is actually used in ROAM.
> 
> The actually patch is rendered in a PostDraw callback registered on the
> VtxTable. This way when the VtxTable is culled, the patch isn't rendered.
> 
> The ssgTerrain is added to the scene in the normal manner.  But in the update,
> it's all rendered by:
> t->reset();    //resets all the patches
> t->tesselate();  //tesselates all the patches.
> ssgCullAndDraw( root );
> 
> Because the tessellation occurs outside the CullAndDraw, all patches are
> tessellated, even those who are culled later.

So why don't you do the tesselation inside the 'cull' function of the
ssgTerrain?  After you've done tesselating, you can just call:

     ssgBranch::cull( {whatever} );

...to do the actual culling of the daughter objects.
 
> I have some misc. utility functions defined like getHeight(), but I'd like to
> make it work for ssgHOT, etc.

Right - those typically need "exact" answers - irrespective of how the terrain
is currently triangulated in the visuals.  Also, the terrain may not have
been triangulated by ROAM if that patch has never been in the field of view.

Hence, I think you'll have to call the tesselator function for some region around
the intersection inside both isect and hot member functions.
 
> Anyway, you can take a look at the code.

With pleasure.

Incidentally, I'm assuming this is something that we'd put into ssgAux rather
into the main scene graph API - since not everyone will want it.  So we'd better
talk about ssgaTerrain rather than ssgTerrain.

This fits in really nicely with the FGFS Sky porting effort.

Maybe I should 'donate' the "feature placement" code from TuxAQFH or TuxKart
too.  That's a parser for a simple file format that contains names of objects
and their location in the world - with the option to have them 'planted' onto
the terrain in Z - and optionally in Roll/Pitch also.

With all of those things provided, writing the graphics part of simple outdoor
games would be a snap.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net