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

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

Maltez wrote:
> 
> > For example, if you use your first approach then it ought to be possible
> to model the
> > trrain 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.
> 
> How could PPE be aware of my subclasses ? is there some dynamic library
> loading (plugin) ?

No - I was assuming your classes would become a part of SSG...maybe that
wasn't your intention?

Presuming your classes were inside SSG, then PPE (and every other application)
would just see "some kind of a branch node" and "some kind of a leaf node" - and
so long as your derived classes support all the member functions of those
standard SSG classes, PPE (and other applications) will be happy.

> >   1) Multiple views of the same model, rendered consecutively. (PrettyPoly
> and
> >      my new 'Evil Overlord' project both do this).
> 
> For multiple views, i need to have one manager+tiles per view and share
> heightfiled and pre-computed variances because the manager and tiles states
> are depending on the camera and it's frustrum.
> How to make mgr1 visible and mgr2 invisible to camera 1 and the inverse to
> camera 2 ?

I'm not sure - that's why I asked!  I suppose you'd need to store a LIST of
states inside each node and to pick which set of states to use depending
on the ssgContext that's set when your node is called.
 
> >   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.
> 
> My implement is not like that and it's not the case of the original algo
> don't say about that.
> When the mesh is entirely culled out from frustrum the manager will not be
> called and keep it's last state. All depends on the kind of camera move
> allowed : smooth or not.

Well, it's hard not to allow discontinuous motion...pretty much every
application does that sooner or later.  But even if the camera motion
is "smooth", when you are culled from the field of view - then when you
come back into the field of view, the camera may have moved twenty miles
and be looking at the terrain from the opposite direction.
 
> When you say EITHER, you mean only one class subclassing but not the 2 ?

Sorry, that wasn't very clear.

I mean "Don't derive from ssgEntity or ssgBase - please derive from
ssgBranch or ssgLeaf".
 
> > However, you don't need to derive from ssgVtxTable/ssgVtxArray...most
> applications
> > are quite robust in that respect.
> 
> What do you mean with robust ?

I mean that most (if not all) PLIB applications will be happy if you
feed them a new class that's derived from ssgLeaf or ssgBranch, you
don't have to derive from ssgVtxTable or ssgVtxArray.

Most applications will use ssgLoad() to grab their models and won't
have much knowledge of what's inside that model.

> > 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.
> 
> Ok, i have done that now. But i thought the devel list was for developpers
> of the core Plib not users like me which are developping with Plib but not
> modifying it. I don't want to bother the real developpers with newbie
> question.

Well, I thought your intention was to put this ROAM stuff *into* SSG.  That
would be "A Good Thing" for the community - so if you are doing this as
OpenSourced code then it would be good to put it into SSG rather than as
a separate package.

That's your call though.
 
----------------------------- 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