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

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

Jon Anderson wrote:

> Well, when I first started, I attached all the Terrain and the Patches as
> user data on a ssgBranch and ssgVtxTable, respectively.  That  was okay to
> get it up an running, but made it clunky to use.

Yes - I can imagine.  It would also be hard to eliminate the problem of
people attaching 'conventional' ssgVtxTables to the Terrain's ssgBranch
node - which could be messy!  Obviously you can tell people not to do
that - but it would be nicer if that was something the compiler could
just toss out.
 
> >Can I see the code?  It would be easier to discuss.
> 
> I'll post it somewhere tonight.

Thanks.

I'm beginning to wonder whether you need to use SSG's mechanisms to
connect up the Patches to the Terrain at all. Would it be so terrible if
the terrain was an ssgLeaf - that happens to have the patches stored
somehow in a way that lies outside the present SSG tree structure.

Well, maybe I should hold off until I can see the code.
 
> >Not that I know of...but those are pretty simple by comparison to your
> >efforts - all you need is alternative 'cull/hot/isect' member functions
> >derived from an ssgBranch node.
> 
> Okay, that's what I thought.  I probably need to study the code a bit
> more.  I wasn't sure if these were implemented as member functions, or if
> it was an external iterator running over the tree that performed these
> functions.

No - pretty much everything in SSG happens inside the classes - it's more
flexible that way.  Each class can decide how to cull and draw itself - and
how to respond to collision tests and such like.  Virtual functions allow
each piece of functionality to be swapped out as needed by each derived
class.  That makes building things like ssgSelector nodes *really* easy
and clean.

Having said that though, OTHER packages may well be walking the tree
with external iterators - and some of the new optimisation and
transformation tools presumably do that.

If we want to model terrain using PrettyPoly, we'll need to think
rather carefully about how that fits together.
 
-- 
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