Re: [Plib-users] Need advices to use Plib for a Roam algo

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

> Maltez wrote:

> I have implemented a terrain engine with a ROAM like algo. It's all coded from scratch using
> Opengl with Glut and without a scene graph hierarchy of classes.
> I am evaluating to use a scene graph toolkit to port my engine and the add other
> functionality like sky, tree,... with Plib.
> Plib seems to be very lightweight but powerfull and let a clear access to OpenGl. Such small
> and clever thin toolkit i like.

Thank you!
 
> I'm new to Plib and i would like to have some advices to make the right (or not too wrong)
> use of Plib classes and right use of sub-classing shema.
> My current architecture is as usual : a manager class containing a grid of 10x10 tiles each
> containing 2 bintrees. The manager class refine the mesh with splits/merges when the camera
> frustrum change in a method Update(). The Render() method feeds arrays of vertices/normal/
> texcoord/colors for each tile and then draw them with a glDrawElements() call.

Seems reasonable.

> Now the dumb questions :
> - Is it correct to subclass the ssgBranch class to implement my tile manager class and
> subclass the ssgVtxArray for my tiles class ?

That would be my first guess.

> - another approach seems to use the predraw callback on a ssgBranch containing ssgVtxArray
> and doing all the work in my manager and tile classes (which will not be subclasses of ssgBranch
> and ssgVtxTable) ?

I don't like this.  You have to think about how things like collision detection (Isect and HOT)
will work.  If your node presents a standard ssgVtxTable interface then all that stuff can just
be inherited from the base class.

Also, there are other tools out there that *expect* to be able to use the callbacks and
userdata for their own purposes.

For example, if you use your first approach then it ought to be possible to model the
terrain skins using PrettyPoly.  If you take the second approach then what you have
is something that doesn't really become a part of PLIB/SSG because it doesn't subclass
from it.

> in that case how to get the frustrum i need to the cull the triangles ?

Well, the current "ssgContext" is obtainable (from within an SSG class, it would
be appropriate to use "_ssgCurrentContext") - and that contains:

   sgFrustum *ssgContext::getFrustum () ;

...or perhaps (more usefully?)...

   ssgContext::getProjectionMatrix ( sgMat4 mat ) ;

...you'll also need the current Modelview matrix (because your terrain may have been
rotated or translated) - and that is in

   ssgContext::getModelviewMatrix ( sgMat4 mat ) ;

...you should have a look at ssgContext - there are other useful things in there too.

> - i plan to share one instance of ssgVertexArray, ssgNormalArray,... for all the
>  ssgVtxArray tiles and a refresh the vertices before each draw of each tile. Is
>  there some pitfall with that ?

Think about:

  1) Multiple views of the same model, rendered consecutively. (PrettyPoly and
     my new 'Evil Overlord' project both do this).

  2) The intersection testing traversals. (3D graphics isn't *just* graphics!)

> - how to skip the culled out tile in the cull (and draw) traversal ?

  Well, if your new 'branch' node isn't in the field of view, it won't get
visited in the cull traversal - so you won't get called...that's a problem
for algorithms like ROAM that have 'memory' from one frame to the next.

  I dislike things that demand to be visited every frame - even when they
are outside the field of view because they don't "scale" well.  With the
present SSG scheme, you can easily have a scene that fills up the whole
of memory and overflows into virtual memory - because SSG generally only
has to visit the very top level nodes to be able to cull most of the
scene.

  However, one of the problems (as I understand it) with ROAM is that it
does a lot of incremental stuff (for speed) - so it needs to be run even
if it's not in view.  That may be unavoidable in this case - but we need
to think carefully about that.

> - another approach is put all in a fresh new subclass of ssgLeaf (and no
> use of ssgVtxArray or ssgBranch). What about this technic ?

You could do that...I've found that this is generally a lot more work - but
maybe not in your case.  It's important that you derive from EITHER ssgLeaf
OR ssgBranch - there is no third kind of thing allowed in the scene graph.
However, you don't need to derive from ssgVtxTable/ssgVtxArray...most applications
are quite robust in that respect.

> I would be glad to have some advices, critics or ideas to use Plib for my Roam engine.

Sure - If there is anything I can do to help...feel free to ask.

You might want to subscribe to the PLIB developer's list though - that's a better
place to ask this stuff than the user's list.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net