plib-users

[Plib-users] VRML Support in SSG?

[Rick M. <rm...@la...>]

I have some .wrl files that I got from NASA, and would like to use them in
SSG (PLIB 1.3.0). I don't know much (read: anything) about VRML, but already
came across a bug in SSG reading VRML files. The VRMLtop_tags struct is
missing a { NULL, NULL } at the end.

In any event, after fixing that, I tried reading in one of these files, and
there was a lot of stuff spewing to the log. I don't know if I'm just
missing files to go with the .wrl file, or if SSG doesn't support VRML 2.0
(as the file claims to be).

Any ideas? Please respond to me as I am getting the digest.

TIA,


------------------------------------------------------------
Roderick Mann                 rm...@la...nsspam

Re: [Plib-users] VRML Support in SSG?

[Gil C. <g.c...@ca...>]

At 03:34 PM 9/15/00 -0700, you wrote:
>I have some .wrl files that I got from NASA, and would like to use them in
>SSG (PLIB 1.3.0). I don't know much (read: anything) about VRML, but already
>came across a bug in SSG reading VRML files. The VRMLtop_tags struct is
>missing a { NULL, NULL } at the end.
>
>In any event, after fixing that, I tried reading in one of these files, and
>there was a lot of stuff spewing to the log. I don't know if I'm just
>missing files to go with the .wrl file, or if SSG doesn't support VRML 2.0
>(as the file claims to be).

At the moment, the VRML loaders are unfinished.  The current priority is 
VRML1, as most CAD and modelling packages will handle that, with fewer 
working with VRML2.  I'm responsible for both loaders, but schedules at 
work are making it tough to get much done on them at the moment.

In the short term, the easiest way to get VRML content into SSG is via one 
of the other mature loaders such as the 3DS loader.  Convert your VRML 
content to 3D Studio format in an external package such as 3D Studio Max, 
and then load it in with the 3DS loader instead.

I can convert the models for you if you don't have Max or another program 
which can do the conversions for you.  Let me know offline if you need me 
to help out.

Regards,

Gil
---------------------------------------------------------------------
3D Graphics Programmer
CSIRO Minesite Imaging Group
Pinjarra Hills, QLD, AUSTRALIA
http://www.dem.csiro.au/research/imaging

"Experience is something you don't get until just after you need it"
---------------------------------------------------------------------

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

[Jon A. <jan...@on...>]

Hi,

I've been working on a really simple implementation of ROAM to work with 
SSG.  It's split into two parts, a terrain class, and a patch class. Each 
patch is just a subset of the terrain, to facilitate frustum culling. Each 
frame, the terrain class initializes, and then tessellates each of its 
patches.  After all have been tessellated, it then renders them.  It 
tessellates them all at once so that it can match edges, and avoid cracks 
in the terrain.

I've implemented the terrain class as an ssgBranch class, and the patches. 
But any pre or post callbacks don't get called on branches.  It seems like 
they only get called on leafs.  So I have to activate the tessellating 
outside of the normal ssgCullAndDraw().  This isn't so bad, except it means 
no culling is done prior to tessellation.

Does anybody have any suggestions on  how to go about this?  Also, has 
anybody every tried to integrate any higherlevel organization like 
quadtrees or octrees into SSG?

Jon

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

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

Jon Anderson wrote:

> I've been working on a really simple implementation of ROAM to work with
> SSG.

Very cool!

> It's split into two parts, a terrain class, and a patch class. Each
> patch is just a subset of the terrain, to facilitate frustum culling. Each
> frame, the terrain class initializes, and then tessellates each of its
> patches.

So a 'terrain' object *contains* the 'patch' objects?

Is that why you need it to be an ssgBranch-derived class?

>  After all have been tessellated, it then renders them.  It
> tessellates them all at once so that it can match edges, and avoid cracks
> in the terrain.

I get it.

> I've implemented the terrain class as an ssgBranch class, and the patches.
> But any pre or post callbacks don't get called on branches.

That's true - because of the sorting of transparency issues we discussed
about a week ago.

However, in your case, you know that all your daughter nodes have the
same ssgState (presumably) - so they'll either all be translucent - or
none of them - so it ought to be safe to use pre-/post- callbacks.

>  It seems like they only get called on leafs.  So I have to activate the tessellating
> outside of the normal ssgCullAndDraw().

That's kindof ugly - I agree.  But if you have derived your own class, why do
you need to mess with callbacks?  You can draw the scene whenever you like.

>  This isn't so bad, except it means no culling is done prior to tessellation.

Yes - I think I understand.

Can I see the code?  It would be easier to discuss.

> Does anybody have any suggestions on  how to go about this?

I think you just need to go a little deeper into the code - you can
(in principal) do the same things that an ssgLeaf does inside an ssgBranch
or vice-versa.

>  Also, has
> anybody every tried to integrate any higherlevel organization like
> quadtrees or octrees into SSG?

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.

-- 
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

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

[Jon A. <jan...@on...>]

>
> > It's split into two parts, a terrain class, and a patch class. Each
> > patch is just a subset of the terrain, to facilitate frustum culling. Each
> > frame, the terrain class initializes, and then tessellates each of its
> > patches.
>
>So a 'terrain' object *contains* the 'patch' objects?
>
>Is that why you need it to be an ssgBranch-derived class?

Yes.


> >  It seems like they only get called on leafs.  So I have to activate 
> the tessellating
> > outside of the normal ssgCullAndDraw().
>
>That's kindof ugly - I agree.  But if you have derived your own class, why do
>you need to mess with callbacks?  You can draw the scene whenever you like.


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.

> >  This isn't so bad, except it means no culling is done prior to 
> tessellation.
>
>Yes - I think I understand.
>
>Can I see the code?  It would be easier to discuss.

I'll post it somewhere tonight.

>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.


Thanks for the suggestions,
Jon

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

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

[Jon A. <jan...@on...>]

> > 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'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.  =)

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.

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.

I have some misc. utility functions defined like getHeight(), but I'd like to
make it work for ssgHOT, etc.

Anyway, you can take a look at the code.

Jon

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

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

[Jon A. <jan...@on...>]

>
>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.

Yes, after poring over the ssg code last night, I think I'll do this.


>
> > 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.

Actually, since the terrain has a pointer to all the height field data. I 
have been just referencing that data directly, rather than trying to 
intersect the resulting mesh.

>
> > 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.

Sure.  This is definitely more of a auxiliary.  It's a pretty simple 
implementation right now, with limited flexibility.  Maybe I'll try 
implementing some things like the variance calculation function as call 
backs to allow an end programmer to customize it better.

>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.

That would definitely be cool.  In fact, I was just about to the point of 
adding that to my little "Walk a quake2 character around on a ROAM terrain" 
game.  =)



Jon

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

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

Jon Anderson wrote:

> >Hence, I think you'll have to call the tesselator function for some region
> >around
> >the intersection inside both isect and hot member functions.
> 
> Actually, since the terrain has a pointer to all the height field data. I
> have been just referencing that data directly, rather than trying to
> intersect the resulting mesh.

Excellent idea.  That should be *really* fast too.  The only 'gotcha'
is that applications can demand that you tell us which triangle was
intersected - it's vertices, etc.  I guess you just have to fake it
so that you give back three terrain height posts.
 
> >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.
> 
> Sure.  This is definitely more of a auxiliary.  It's a pretty simple
> implementation right now, with limited flexibility.  Maybe I'll try
> implementing some things like the variance calculation function as call
> backs to allow an end programmer to customize it better.

Yes - I think that would be useful...of course you could donate it as-is
and set the bazaar loose on those improvements!

                  "Commit early - Commit often"

-- 
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