RE: [Plib-users] Plib as a Model Loader

[Tyler O. <Xa...@ho...>]

> Tyler Ohlsen wrote:
> > I'm looking at using plib as a model loader for a flight simulator 
> > type application I'm making, but that's all I want plib for.  (I
don't 
> > want to use plib as my scene graph library)
> 
> The problem with 3D file loaders is that they have to load the model
into 
> some kind of data structure.  The name for that data structure is a
> "Scene Graph".  Hence, loaders for 3D file formats cannot exist wihout

> a scene graph.  Since rendering stuff out of that scene graph is an 
> easily automatable process - and since it makes a lot of sense to use
> a C++ class hierarchy to do the work, it follows that the renderer and

> the file loader are tightly knitted together.
> 
> Tossing out the renderer in order to get the loaders is not generally
a good idea.

Loading from a 3D file into a scene graph is one implementation, you
don't have to do it that way.  I agree that it makes a lot of sense and
that most 3D applications are greatly improved by using scene graphs.
That being said, it would be nice to have the option to use someone
else's scene graph library.  Not that yours is lacking in anything, but
the option is nice.

> > I've played around with the simple scene graph module and I see that

> > calling ssgCullAndDraw throws out the existing projection and 
> > modelview matrices forcing you to use ssg's camera.  I would like to

> > use my own camera and not have to use ssg's camera at all.
> 
> SSG lets you set both the modelview and projection matrix directly.
> 
> It's hard to imagine what "your own camera" could be that SSG couldn't
already handle.

Again, this was a matter of preference.  I would like to use my own
camera if I could (without doing a hack to convert my camera's
orientation representation to ssg's camera orientation every frame).

> > Is there a way to call a draw method of an ssgRoot object that does 
> > not throw out the these matrices and leaves the view culling up to
the 
> > application (it just draws around the current zero point like 
> > glutSolidTeapot and such)?
> 
> No - because SSG needs to know that those matrices are in order to
> do field-of-view culling, Range-switched nodes and such.   OK - we
> *could* read those matrices back from OpenGL in order to find out
> what your camera code set them to - but reading things back from
> OpenGL is something to be avoided at all costs.
> 
> So it's better for you tell use what you want them to be and let
> us send them to OpenGL...that's no different from you sending them
> to OpenGL - but this is more efficient.

But if you're not using ssg as your scene graph (just as a model loader)
then you don't want it to do view culling.  Then ssg doesn't need to
know the current state of these matrices at all.

> >  If there doesn't exist such a method, would
> > there be an interest for me to create one for you all?
> 
> I don't see any conceivable need for that - but if you 
> can come up with something convincing, we could certainly consider it.

I dug into ssg and came up with the following code.  First is an example
usage of what this function gives the application programmer.  This
function has made the integration of ssg (just as a model loader and not
a scene graph) into my application much easier.  It may not be the most
efficient way to do it, but it's not too bad (I know that each leaf's
opengl state is forced).

Example Usage:
---------------------------------
int LoadModel(const char* szFile)
{
  int        iListID = glGenLists(1);
  ssgEntity* oModelEntity = ssgLoad(szFile);
  ssgRoot*   oModel = new ssgRoot;
  oModel->addKid(oModelEntity);

  glNewList(iListID, GL_COMPILE);
  glPushMatrix();
  glRotatef(-90, 1,0,0);            //ssgRawDraw allows for regular
opengl transforms
  glScalef(0.25f, 0.25f, 0.25f);
  ssgRawDraw(oModel);
  glPopMatrix();
  glEndList();

  delete oModel;
  delete oModelEntity;

  return iListID;
}
void RenderModel(int iListID)
{
  glCallList(iListID);
}
---------------------------------

You are welcome to integrate this code into plib if you wish.  Also, if
you have any suggestions of changes I would be glad to hear them.

Implementation:
-----
ssg.h
-----
void ssgRawDraw ( ssgBranch *root ) ;

class ssgEntity : public ssgBase
{
  ...
  virtual void raw_draw ( bool translucent_objects ) = 0 ;
  ...
}
class ssgLeaf : public ssgEntity
{
  ...
  virtual void raw_draw ( bool translucent_objects ) ;
  ...
}
class ssgBranch : public ssgEntity
{
  ...
  virtual void raw_draw ( bool translucent_objects ) ;
  ...
}
class ssgTransform : public ssgBaseTransform
{
  ...
  virtual void raw_draw ( bool translucent_objects ) ;
  ...
}
-------
ssg.cxx
-------
void ssgRawDraw ( ssgBranch *r )
{
  r->raw_draw(false);
  r->raw_draw(true);
}
-------------
ssgBranch.cxx
-------------
void ssgBranch::raw_draw ( bool translucent_objects )
{
  for ( ssgEntity *e = getKid ( 0 ) ; e != NULL ; e = getNextKid() )
    e -> raw_draw ( translucent_objects ) ;
}
----------------
ssgTransform.cxx
----------------
void ssgTransform::raw_draw ( bool translucent_objects )
{
  glPushMatrix () ;
  glMultMatrixf ( (float *) transform ) ;

  for ( ssgEntity *e = getKid ( 0 ) ; e != NULL ; e = getNextKid() )
    e -> raw_draw ( translucent_objects ) ;

  glPopMatrix () ;
}
-----------
ssgLeaf.cxx
-----------
void ssgLeaf::raw_draw ( bool translucent_objects )
{
  if (isTranslucent() != translucent_objects)
    return;

  if (hasState())
    getState()->force();

  draw_geometry () ;
}
-----------


Thanks for creating a great library =)
Tyler Ohlsen