gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Ko, M. <MAN...@ca...>]

The scene-graph should be the foundation of any realtime renderer. The
parent-child is to put a good heirarchy. I don't find it essential to have
both a parent and child link. And the child link is jst a concept. U can
use an array for containers (which I do).

A good heirarchy is essential to any good culling or collision testing. Or
for sharing sub-trees. A well abstracted heirarchy allows a good separation
of overall scene access function be separated from the most optimal
renderer specific representation. Which allows a single RT core rendering
but supports multiple DirectX versions, or OpenGL and Direc3D. Besides, the
scene-graph is needed to interface to an animation or physics engine well.

-----Original Message-----
From: Aaron Drew [mailto:ri...@ho...]
Sent: Saturday, September 02, 2000 4:56 PM
To: gda...@li...
Subject: [Algorithms] FW: [CsMain] Scene Graphs


I've read many discussions on this list as to the pro's and con's of various
solutions to storing, rendering and processing 3D objects but the
scene-graph hasn't really made much discussion since I've been subscribed.

I can't seem to find much on the web in regards to their usefulness apart
from a few papers on VRML and Java3D.

I'm having trouble seeing how the added cost of unnecessary traversal of
nodes and the memory overheads of parent/child links in a scene would be
worth the added effort but I'm curious as to the thoughts of the many
experienced developers on this list.

Do scene-graphs pay off?

If so, how?

Managing vertex buffers, textures, multiple instances of objects (with
shared vertex data), etc can get rather clumsy without a consistant system
yet everything I've read about scene-graphs suggests that they are simply
traversed and the objects in them rendered. How would I represent (say) an
octree implementation within a construct like
this?

- Aaron

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Ko, M. <MAN...@ca...>]

Yes - and of coz read the classic Performer paper. I believe it is Siggraph
96 by Ruelfe and Hellman.

-----Original Message-----
From: Graham S. Rhodes [mailto:gr...@se...]
Sent: Tuesday, September 05, 2000 7:14 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs


At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs: Wired
or Tired" to discuss this, although not necessarily from a game development
standpoint.

Here are a couple of links that should give you part of the content of that
presentation (if you don't have the SIGGRAPH proceedings already):

http://www.intrinsic.com/technology/presentations.htm
http://www.cs.brown.edu/research/graphics/research/siggraph99/scenegraph/

Graham Rhodes

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Aaron
> Drew
> Sent: Saturday, September 02, 2000 7:56 PM
> To: gda...@li...
> Subject: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> I've read many discussions on this list as to the pro's and con's
> of various
> solutions to storing, rendering and processing 3D objects but the
> scene-graph hasn't really made much discussion since I've been subscribed.
>
> I can't seem to find much on the web in regards to their usefulness apart
> from a few papers on VRML and Java3D.
>
> I'm having trouble seeing how the added cost of unnecessary traversal of
> nodes and the memory overheads of parent/child links in a scene would be
> worth the added effort but I'm curious as to the thoughts of the many
> experienced developers on this list.
>
> Do scene-graphs pay off?
>
> If so, how?
>
> Managing vertex buffers, textures, multiple instances of objects (with
> shared vertex data), etc can get rather clumsy without a consistant system
> yet everything I've read about scene-graphs suggests that they are simply
> traversed and the objects in them rendered. How would I represent (say) an
> octree implementation within a construct like
> this?
>
> - Aaron
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Stephen J B. <sj...@li...>]

 
> At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs: Wired
> or Tired" to discuss this, although not necessarily from a game development
> standpoint.


I think scene graphs are like so many other aspects of making high
performance applications - we used to write machine code - compilers
were considered terribly inefficient.  Now compilers are getting
better (so they are less wasteful) - machines are getting faster
(so we care less) - and machines and our programs are getting
COMPLICATED (so writing machine code is less possible).

Hence, whilst it's theoretically possible to make your game
run faster by writing it all in machine code - nobody does
that anymore.

I think the same thing happens with API's like OpenGL.  When
it first appeared, everyone wanted to get at some lower level
'bare metal' interface to the hardware for speed.  I don't think
anyone is advocating that anymore...for much the same reason
that we don't use raw machine code anymore.

Well, Scene Graph API's are quite possibly the next stage of
evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
DOING you can get better performance by writing your own
low level engine to the 'raw' OpenGL.  But as multi-pass
rendering, shadows, etc get more and more complicated and
the machines get faster and the scene graph API's get better,
I believe there comes a point where you shrug your shoulders
and say "who cares" about the small performance loss that
comes from a generic rendering API versus something more
optimised to your application that you could have written
yourself.

Just as with compiler technology, the point where you decide
to switch depends a lot on how demanding your application
is and how skilled you are.  Red hot x86 machine coders
writing state of the art games were writing machine code
long after the amateur Tetris clone writers had switched
to C compilers.

Another aspect to this was that when OpenGL first appeared
on the PC, lots of people complained that it stifled their
creativity and wouldn't let them get at pixels in the
frame buffer.  It's really noticable how those sorts of
complaints have tailed off over the last few years...I
think we hear the same things about scene graph API's.

  For some people "it forces us all into the same mold"
  For other people "it liberates me from having to think
     about the polygons so I can concentrate on higher
     level stuff"  -- like physics for example.
 
Finally, what forced people into using OpenGL (or D3D
for that matter) was sheer hardware necessity - and it's
my view that this too will happen to scene graph API's.

We are already seeing with nVidia T&L cards that you
need to lock your data into particular chunks of memory
and send data to the card in carefully chosen chunk sizes
if you want to get the very best performance.  Those are
the kinds of *ugly* things that applications shouldn't
have to deal with - they should be hidden inside a well
written scene graph API - and if it were standardized
across various cards, it could hide these kinds of
hardware differences that OpenGL and D3D cannot.

SGI's new 'shader language' is an example of this too -
it's not a 'scene graph' API - but another way to look
at a higher level rendering API.  As scene graph API's
are to geometry, so shader languages are to state. They
can play nicely together too.

Scene Graph/Shader API's *will* be the next step - it's
just a matter of when the balance tips in their favor.

One thing that DOES concern me though is the lack of any
prior 'open' standardization efforts in this area.  I was
saddened that OpenGL++ didn't ever appear.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Akbar A. <sye...@ea...>]

hey,

>Hence, whilst it's theoretically possible to make your game
>run faster by writing it all in machine code
you would have to be one very smart person to pull this one off. topping of
what the compilers' are generating is getting harder and harder (iirc vc7 is
coming out later this year), plus there is the time it takes to write good
low-level code :|

>When it first appeared, everyone wanted to get at some lower level
>'bare metal' interface to the hardware for speed.
yes, i find this quite funny. remeber when everyone was like "give us the
metal" and saying other things like this. then when they finnally got it
with the psx2 a lot of them ran into problems (but they learnt a lot ;)


>lots of people complained that it stifled their
>creativity and wouldn't let them get at pixels in the
this is somewhat true. there where some really cool demos back in the dos
days that never made the converge to OpenGL.

in general scenegraphs are good, they lay out a lot of foundation work so
you don't have to reinvent "to much" of the wheel.

btw, new movies up at www.sgi.com.




peace,
akbar A.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stephen J Baker
Sent: Tuesday, September 05, 2000 1:22 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs



> At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs:
Wired
> or Tired" to discuss this, although not necessarily from a game
development
> standpoint.


I think scene graphs are like so many other aspects of making high
performance applications - we used to write machine code - compilers
were considered terribly inefficient.  Now compilers are getting
better (so they are less wasteful) - machines are getting faster
(so we care less) - and machines and our programs are getting
COMPLICATED (so writing machine code is less possible).

Hence, whilst it's theoretically possible to make your game
run faster by writing it all in machine code - nobody does
that anymore.

I think the same thing happens with API's like OpenGL.  When
it first appeared, everyone wanted to get at some lower level
'bare metal' interface to the hardware for speed.  I don't think
anyone is advocating that anymore...for much the same reason
that we don't use raw machine code anymore.

Well, Scene Graph API's are quite possibly the next stage of
evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
DOING you can get better performance by writing your own
low level engine to the 'raw' OpenGL.  But as multi-pass
rendering, shadows, etc get more and more complicated and
the machines get faster and the scene graph API's get better,
I believe there comes a point where you shrug your shoulders
and say "who cares" about the small performance loss that
comes from a generic rendering API versus something more
optimised to your application that you could have written
yourself.

Just as with compiler technology, the point where you decide
to switch depends a lot on how demanding your application
is and how skilled you are.  Red hot x86 machine coders
writing state of the art games were writing machine code
long after the amateur Tetris clone writers had switched
to C compilers.

Another aspect to this was that when OpenGL first appeared
on the PC, lots of people complained that it stifled their
creativity and wouldn't let them get at pixels in the
frame buffer.  It's really noticable how those sorts of
complaints have tailed off over the last few years...I
think we hear the same things about scene graph API's.

  For some people "it forces us all into the same mold"
  For other people "it liberates me from having to think
     about the polygons so I can concentrate on higher
     level stuff"  -- like physics for example.

Finally, what forced people into using OpenGL (or D3D
for that matter) was sheer hardware necessity - and it's
my view that this too will happen to scene graph API's.

We are already seeing with nVidia T&L cards that you
need to lock your data into particular chunks of memory
and send data to the card in carefully chosen chunk sizes
if you want to get the very best performance.  Those are
the kinds of *ugly* things that applications shouldn't
have to deal with - they should be hidden inside a well
written scene graph API - and if it were standardized
across various cards, it could hide these kinds of
hardware differences that OpenGL and D3D cannot.

SGI's new 'shader language' is an example of this too -
it's not a 'scene graph' API - but another way to look
at a higher level rendering API.  As scene graph API's
are to geometry, so shader languages are to state. They
can play nicely together too.

Scene Graph/Shader API's *will* be the next step - it's
just a matter of when the balance tips in their favor.

One thing that DOES concern me though is the lack of any
prior 'open' standardization efforts in this area.  I was
saddened that OpenGL++ didn't ever appear.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Scott L. <va...@be...>]

> Hence, whilst it's theoretically possible to make your game
> run faster by writing it all in machine code - nobody does
> that anymore.

Unless of course they're Playstation 2 developers and they
have no other choice >-)...

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Graham S. R. <gr...@se...>]

I don't know if you all are aware of this (but some probably are), but SGI
has released their Open Inventor scene graph engine (version 2.1 or maybe
2.2 I think) as open source, see this link:

http://oss.sgi.com/projects/inventor/

It is an extensible/programmable scene graph engine that is quite powerful.
It has a "standard" file format as well, and built-in loaders and writers
for that format. It includes some simple animation engines, but as with all
of the engine you can write your own, customized engines.

I've developed a rather extensive application using Open Inventor (the TGS
versions and SGI versions) for about 4 years now, and I consider myself an
expert. And I'd like to mention these rather large issues that exist with
Open Inventor (SGI's version at least):

1) There be bugs in SGI's version! For example, the SoCalculator animation
engine sometimes locks up and doesn't work when you write vector equations!
That engine also sometimes gets the sign wrong when multiplying terms
together. These two are fixed in (at least 2.5 and later) TGS versions.

2) The SGI version isn't really fantastic for very large models, though that
might not be too much of a problem for some games right now.

3) The TGS version will likely continue to be a commercial product for sale.
A pity (if you want it for free) since it has many enhancements, such as
continuous level of detail for large model display, as well as the bug fixes
mentioned above and more.

4) The SGI version is IRIX only! It probably can be ported to Linux readily.
And it has been ported to Windows by others (TGS of course, plus Portable
Graphics before they were absorbed by TGS, and at least one other company),
but the Windows ports are not open source.

5) Open Inventor is not really designed to deal with large immersive worlds.
Its fine for inspecting CAD models and collections of objects.

If you're a Linux developer, you might consider using IRIS Performer (to be
OpenGL Performer with next version), which is freely available for Linux
(binaries only). It is better suited for large models and environments, and
it is designed to actively manage performance/frame rate. Probably a better
choice for games, but there is no Windows version and likely never will be.
See this link:

http://www.sgi.com/software/performer/

Graham Rhodes

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Ko,
> Manchor
> Sent: Tuesday, September 05, 2000 12:38 PM
> To: gda...@li...
> Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> Yes - and of coz read the classic Performer paper. I believe it
> is Siggraph
> 96 by Ruelfe and Hellman.
>
> -----Original Message-----
> From: Graham S. Rhodes [mailto:gr...@se...]
> Sent: Tuesday, September 05, 2000 7:14 AM
> To: gda...@li...
> Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> At SIGGRAPH 1999 there was a paper/panel session called "Scene
> Graphs: Wired
> or Tired" to discuss this, although not necessarily from a game
> development
> standpoint.
>
> Here are a couple of links that should give you part of the
> content of that
> presentation (if you don't have the SIGGRAPH proceedings already):
>
> http://www.intrinsic.com/technology/presentations.htm
> http://www.cs.brown.edu/research/graphics/research/siggraph99/scenegraph/
>
> Graham Rhodes
>
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On Behalf Of Aaron
> > Drew
> > Sent: Saturday, September 02, 2000 7:56 PM
> > To: gda...@li...
> > Subject: [Algorithms] FW: [CsMain] Scene Graphs
> >
> >
> > I've read many discussions on this list as to the pro's and con's
> > of various
> > solutions to storing, rendering and processing 3D objects but the
> > scene-graph hasn't really made much discussion since I've been
> subscribed.
> >
> > I can't seem to find much on the web in regards to their
> usefulness apart
> > from a few papers on VRML and Java3D.
> >
> > I'm having trouble seeing how the added cost of unnecessary traversal of
> > nodes and the memory overheads of parent/child links in a scene would be
> > worth the added effort but I'm curious as to the thoughts of the many
> > experienced developers on this list.
> >
> > Do scene-graphs pay off?
> >
> > If so, how?
> >
> > Managing vertex buffers, textures, multiple instances of objects (with
> > shared vertex data), etc can get rather clumsy without a
> consistant system
> > yet everything I've read about scene-graphs suggests that they
> are simply
> > traversed and the objects in them rendered. How would I
> represent (say) an
> > octree implementation within a construct like
> > this?
> >
> > - Aaron
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Stephen J B. <sj...@li...>]

On Wed, 6 Sep 2000, Graham S. Rhodes wrote:

> I don't know if you all are aware of this (but some probably are), but SGI
> has released their Open Inventor scene graph engine (version 2.1 or maybe
> 2.2 I think) as open source, see this link:
> 
> http://oss.sgi.com/projects/inventor/
 
Yes - but Inventor isn't really appropriate for high performance
stuff - that's why SGI have the 'Performer' scene graph for that kind
of thing.

Inventor is more for makeing cute presentations, rapid prototyping,
that kind of thing.

> It is an extensible/programmable scene graph engine that is quite powerful.
> It has a "standard" file format as well...

It's essentially VRML...or more accurately - VRML is essentially
Inventor.

----
Science being insufficient - neither ancient protein species deficient.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Graham S. R. <gr...@se...>]

Steve wrote,

> Yes - but Inventor isn't really appropriate for high performance
> stuff - that's why SGI have the 'Performer' scene graph for that kind
> of thing.

I agree! You'll note that I stated as much in my original post, at the
bottom, item #5 and the following paragraph. (I sometimes have the same
habit as you----replying to a message before I read or fully comprehend the
entire message. Or before I check to see if someone else has replied with
the same response. But I'm getting better!) Its probably good that you
stated your comment on Performer vs. Inventor at the top of your message,
since possibly someone else didn't read to the bottom of my long message.

Even so, you'll be interested to know that our customer has been able to
display models up to around 250,000 polygons (tris and quads) in Inventor,
on an HP Kayak PC with fx2 graphics. Frame rates were not good, though, for
this model. With a 100,000 polygon model frame rates were much better, of
course. Modern consumer T&L boards, which are much better than fx2 graphics,
would result in better performance for the larger model.

It is absolutely true that Inventor does not actively manage performance the
way Performer does. It really is meant for inspecting objects and
manipulating objects rather than navigating through large worlds. I do think
Performer is going to be a better engine for games. But, alas, Performer
doesn't work on Windows or Macintosh. Only Linux and IRIX. And it is
unlikely that it will ever be ported to the more popular platforms.

> Inventor is more for makeing cute presentations, rapid prototyping,
> that kind of thing.

We use it for a bit more than that. We have an Inventor-based model
assembler (developed from 1996 through present) that we use to build models
of NASA's Next Generation Space Telescope (NGST), pressure vessels for
studying Mars habitats. And others have used our tool to assemble various
large aircraft models (e.g., high speed civil transport). We assemble the
model and apply loads and boundary conditions/constraints in our Inventor
app, then invoke a multidisciplinary analysis of the assemblies, and finally
import and animate the results in Inventor. For example, we've done an
analysis of the NGST where nonlinear structural vibration was induced by
radiation loading from the sun in space. The animation data is over 300MB of
motion and scalar contour data (12000 time steps) for the vibrating space
telescope. Inventor handles it just fine. The model itself is not as big as
the large models mentioned above, though. We do the postprocessing as well
in a Performer app, which maintains a relatively constant frame rate
compared with the Inventor app.

> > It is an extensible/programmable scene graph engine that is
> quite powerful.
> > It has a "standard" file format as well...
>
> It's essentially VRML...or more accurately - VRML is essentially
> Inventor.

Folks should keep one thing straight. VRML is a file format. Inventor is
both a file format and an extensible C++ scene graph toolkit. When comparing
Inventor and VRML, you can compare their file formats. And you can compare
the Inventor toolkit with VRML file browsers. In general, it is *not*
accurate to say "VRML is essentially Inventor" or vice versa.

It is true that the VRML version #1 file format was based on the Inventor
file format. Inventor's file format is both a superset and subset of VRML 1.
Inventor has features, such as calculator engines, that the VRML 1 file
format does not have. And VRML 1 has features that were not in Inventor
(billboard node, sky/background node?). VRML 1 is quite obsolete, and
Inventor is not related to the more current VRML97 (version #2 of VRML).

Inventor the *engine* as opposed to inventor the *file format* is a HELL of
a lot more than simple VRML #1 viewers in terms of programmability and
extensibility. It is *not* merely a viewer for simple files. It does allow
you to build interactive scenes and customized 3D interaction, even though
it is not the best SG engine for this kind of application. You can write
OpenGL callbacks to implement cinematics, etc. VRML97 viewers that support
ECMA scripting or EAI allow significant customization and interactivity, but
performance is not as good as Inventor (since customization is often done
with a slower language than C++, such as Java).

There, I think I'm through talking about Inventor and Performer now.

Intrinsic Alchemy (www.intrinsic.com) is a scene graph engine developed I
think by folks who worked on or with Performer. Alchemy does specifically
target the game development market. There are versions for Windows and PS2.

NetImmerse from NDL (www.ndl.com) is another example of a gaming scene graph
engine that works on Windows and PS2.

Both of these engines are going to be far more expensive than Inventor or
Performer, but probably offer better performance for games and better
portability options.

Graham Rhodes

>
> ----
> Science being insufficient - neither ancient protein species deficient.
>
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Matthew M. <ma...@me...>]

You Know;

Hewlett-Packard did an elaborate scene-graph API with fairly advanced
OCCLUSION CULLING, (i.e. more than just portals or HOMs) originally as part
of Fahrenheit. It was called DirectModel, and it has been used to ship
products. (by EAI, for one.) Its primary focus was extremely large datasets
(engine simulations, etc.) It was originally only part of the Visualize
Toolkit.

Now, the interesting part is that they recently gave a grant to the
University of Tuebingen (Germany?) to convert DirectModel to Linux and
release it as open source.

While such release has not yet happened, I do believe I've found the group
that's doing the conversion:

http://www.gris.uni-tuebingen.de/~bartz/proj/large/#occlusion

The project has been renamed to "Large Model Rendering Toolkit."

They don't specifically mention it on the site (I assume it's not ready,)
but there are some enticing papers up there in Acrobat format.

-- Matt

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Graham S. Rhodes
Sent: Wednesday, September 06, 2000 11:27 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open
source + Performer for Linux)


Steve wrote,

> Yes - but Inventor isn't really appropriate for high performance
> stuff - that's why SGI have the 'Performer' scene graph for that kind
> of thing.

I agree! You'll note that I stated as much in my original post, at the
bottom, item #5 and the following paragraph. (I sometimes have the same
habit as you----replying to a message before I read or fully comprehend the
entire message. Or before I check to see if someone else has replied with
the same response. But I'm getting better!) Its probably good that you
stated your comment on Performer vs. Inventor at the top of your message,
since possibly someone else didn't read to the bottom of my long message.

Even so, you'll be interested to know that our customer has been able to
display models up to around 250,000 polygons (tris and quads) in Inventor,
on an HP Kayak PC with fx2 graphics. Frame rates were not good, though, for
this model. With a 100,000 polygon model frame rates were much better, of
course. Modern consumer T&L boards, which are much better than fx2 graphics,
would result in better performance for the larger model.

It is absolutely true that Inventor does not actively manage performance the
way Performer does. It really is meant for inspecting objects and
manipulating objects rather than navigating through large worlds. I do think
Performer is going to be a better engine for games. But, alas, Performer
doesn't work on Windows or Macintosh. Only Linux and IRIX. And it is
unlikely that it will ever be ported to the more popular platforms.

> Inventor is more for makeing cute presentations, rapid prototyping,
> that kind of thing.

We use it for a bit more than that. We have an Inventor-based model
assembler (developed from 1996 through present) that we use to build models
of NASA's Next Generation Space Telescope (NGST), pressure vessels for
studying Mars habitats. And others have used our tool to assemble various
large aircraft models (e.g., high speed civil transport). We assemble the
model and apply loads and boundary conditions/constraints in our Inventor
app, then invoke a multidisciplinary analysis of the assemblies, and finally
import and animate the results in Inventor. For example, we've done an
analysis of the NGST where nonlinear structural vibration was induced by
radiation loading from the sun in space. The animation data is over 300MB of
motion and scalar contour data (12000 time steps) for the vibrating space
telescope. Inventor handles it just fine. The model itself is not as big as
the large models mentioned above, though. We do the postprocessing as well
in a Performer app, which maintains a relatively constant frame rate
compared with the Inventor app.

> > It is an extensible/programmable scene graph engine that is
> quite powerful.
> > It has a "standard" file format as well...
>
> It's essentially VRML...or more accurately - VRML is essentially
> Inventor.

Folks should keep one thing straight. VRML is a file format. Inventor is
both a file format and an extensible C++ scene graph toolkit. When comparing
Inventor and VRML, you can compare their file formats. And you can compare
the Inventor toolkit with VRML file browsers. In general, it is *not*
accurate to say "VRML is essentially Inventor" or vice versa.

It is true that the VRML version #1 file format was based on the Inventor
file format. Inventor's file format is both a superset and subset of VRML 1.
Inventor has features, such as calculator engines, that the VRML 1 file
format does not have. And VRML 1 has features that were not in Inventor
(billboard node, sky/background node?). VRML 1 is quite obsolete, and
Inventor is not related to the more current VRML97 (version #2 of VRML).

Inventor the *engine* as opposed to inventor the *file format* is a HELL of
a lot more than simple VRML #1 viewers in terms of programmability and
extensibility. It is *not* merely a viewer for simple files. It does allow
you to build interactive scenes and customized 3D interaction, even though
it is not the best SG engine for this kind of application. You can write
OpenGL callbacks to implement cinematics, etc. VRML97 viewers that support
ECMA scripting or EAI allow significant customization and interactivity, but
performance is not as good as Inventor (since customization is often done
with a slower language than C++, such as Java).

There, I think I'm through talking about Inventor and Performer now.

Intrinsic Alchemy (www.intrinsic.com) is a scene graph engine developed I
think by folks who worked on or with Performer. Alchemy does specifically
target the game development market. There are versions for Windows and PS2.

NetImmerse from NDL (www.ndl.com) is another example of a gaming scene graph
engine that works on Windows and PS2.

Both of these engines are going to be far more expensive than Inventor or
Performer, but probably offer better performance for games and better
portability options.

Graham Rhodes

>
> ----
> Science being insufficient - neither ancient protein species deficient.
>
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Graham S. R. <gr...@se...>]

Matt wrote,

> Hewlett-Packard did an elaborate scene-graph API with fairly advanced
> OCCLUSION CULLING, (i.e. more than just portals or HOMs)
> originally as part
> of Fahrenheit. It was called DirectModel, and it has been used to ship
> products. (by EAI, for one.) Its primary focus was extremely
> large datasets
> (engine simulations, etc.) It was originally only part of the Visualize
> Toolkit.

Wasn't DirectModel supposed to be rolled into Fahrenheit? I think someone at
Sense8 (owned by EAI now) mentioned that to me a year or two ago.

Also, SGI OpenGL Optimizer is similar, and is available for free for
Windows, in its binary form. I'm not sure what they've done on it recently.

I know someone who has used Optimizer and Performer enough to compare their
level-of-detail features. I wish I remembered what he said, but I do
remember that one or the other provided much better performance than the
other. I'm thinking that Performer was better, but I wouldn't swear to it.

I have an SGI 320 workstation running Windows NT on my desktop here at the
office.  It uses the SGI Cobalt 3D chipset. Its performance is abysmal
compared to the new nVidia and ATI offerings. But it does have an
interesting hardware-assisted occlusion culling capability, and a
corresponding OpenGL extension. I think the HP fx graphics have something
like this as well.

> Now, the interesting part is that they recently gave a grant to the
> University of Tuebingen (Germany?) to convert DirectModel to Linux and
> release it as open source.

Now that is interesting...

Graham Rhodes

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Stefan B. <ste...@te...>]

> Hewlett-Packard did an elaborate scene-graph API with fairly advanced
> OCCLUSION CULLING, (i.e. more than just portals or HOMs)
> originally as part of Fahrenheit. It was called DirectModel, and it has
been
> used to ship products. (by EAI, for one.) Its primary focus was extremely
> large datasets (engine simulations, etc.) It was originally only part of
the
> Visualize Toolkit.

  Wasn't this also the basis for the LMX component of XSG?

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Gavan H. <gh...@si...>]

yet XSG has been released by MS and work discontinued I believe, I think
that it is not supported either... this would make a nice candidate for open
source, if MS don't want the code then others might be able to give it some
life....

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stefan Boberg
Sent: Thursday, September 07, 2000 8:24 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open
source + Performer for Linux)


> Hewlett-Packard did an elaborate scene-graph API with fairly advanced
> OCCLUSION CULLING, (i.e. more than just portals or HOMs)
> originally as part of Fahrenheit. It was called DirectModel, and it has
been
> used to ship products. (by EAI, for one.) Its primary focus was extremely
> large datasets (engine simulations, etc.) It was originally only part of
the
> Visualize Toolkit.

  Wasn't this also the basis for the LMX component of XSG?

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Stephen J B. <sj...@li...>]

On Wed, 6 Sep 2000, Graham S. Rhodes wrote:

> Intrinsic Alchemy (www.intrinsic.com) is a scene graph engine developed I
> think by folks who worked on or with Performer. Alchemy does specifically
> target the game development market. There are versions for Windows and PS2.
> 
> NetImmerse from NDL (www.ndl.com) is another example of a gaming scene graph
> engine that works on Windows and PS2.
> 
> Both of these engines are going to be far more expensive than Inventor or
> Performer, but probably offer better performance for games and better
> portability options.
 
You might also want to look at my scene graph API 'SSG' - which is somewhat
like Performer - but *much* simpler...and runs on anything that supports
OpenGL and can run basic C++ ...and it's OpenSourced/free.

   http://plib.sourceforge.net/ssg

There has been a boom in interest in SSG over the last few months.
SSG has been around for about 3 years now as a more or less solo
project - but for the last 3 or 4 months there have about a dozen
developers actively working on it.

----
Science being insufficient - neither ancient protein species deficient.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Ko, M. <MAN...@ca...>]

I completely agrees with akbar and Stephen on this. Even if you decided not
to use an off the shelf scene graph API. Do built one yourself. If you think
you can do a good one. It is not a trivial task to built a good one. This is
an area that I have done quite a lot of work on.

The SGI/Microsoft ill-fated Fahrenheit would be the cross-platform Opengl++.
You know what happened to it. Fahrenheit is actually architected quite well.
But that is another story....

-----Original Message-----
From: Akbar A. [mailto:sye...@ea...]
Sent: Tuesday, September 05, 2000 1:20 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs


hey,

>Hence, whilst it's theoretically possible to make your game
>run faster by writing it all in machine code
you would have to be one very smart person to pull this one off. topping of
what the compilers' are generating is getting harder and harder (iirc vc7 is
coming out later this year), plus there is the time it takes to write good
low-level code :|

>When it first appeared, everyone wanted to get at some lower level
>'bare metal' interface to the hardware for speed.
yes, i find this quite funny. remeber when everyone was like "give us the
metal" and saying other things like this. then when they finnally got it
with the psx2 a lot of them ran into problems (but they learnt a lot ;)


>lots of people complained that it stifled their
>creativity and wouldn't let them get at pixels in the
this is somewhat true. there where some really cool demos back in the dos
days that never made the converge to OpenGL.

in general scenegraphs are good, they lay out a lot of foundation work so
you don't have to reinvent "to much" of the wheel.

btw, new movies up at www.sgi.com.




peace,
akbar A.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stephen J Baker
Sent: Tuesday, September 05, 2000 1:22 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs



> At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs:
Wired
> or Tired" to discuss this, although not necessarily from a game
development
> standpoint.


I think scene graphs are like so many other aspects of making high
performance applications - we used to write machine code - compilers
were considered terribly inefficient.  Now compilers are getting
better (so they are less wasteful) - machines are getting faster
(so we care less) - and machines and our programs are getting
COMPLICATED (so writing machine code is less possible).

Hence, whilst it's theoretically possible to make your game
run faster by writing it all in machine code - nobody does
that anymore.

I think the same thing happens with API's like OpenGL.  When
it first appeared, everyone wanted to get at some lower level
'bare metal' interface to the hardware for speed.  I don't think
anyone is advocating that anymore...for much the same reason
that we don't use raw machine code anymore.

Well, Scene Graph API's are quite possibly the next stage of
evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
DOING you can get better performance by writing your own
low level engine to the 'raw' OpenGL.  But as multi-pass
rendering, shadows, etc get more and more complicated and
the machines get faster and the scene graph API's get better,
I believe there comes a point where you shrug your shoulders
and say "who cares" about the small performance loss that
comes from a generic rendering API versus something more
optimised to your application that you could have written
yourself.

Just as with compiler technology, the point where you decide
to switch depends a lot on how demanding your application
is and how skilled you are.  Red hot x86 machine coders
writing state of the art games were writing machine code
long after the amateur Tetris clone writers had switched
to C compilers.

Another aspect to this was that when OpenGL first appeared
on the PC, lots of people complained that it stifled their
creativity and wouldn't let them get at pixels in the
frame buffer.  It's really noticable how those sorts of
complaints have tailed off over the last few years...I
think we hear the same things about scene graph API's.

  For some people "it forces us all into the same mold"
  For other people "it liberates me from having to think
     about the polygons so I can concentrate on higher
     level stuff"  -- like physics for example.

Finally, what forced people into using OpenGL (or D3D
for that matter) was sheer hardware necessity - and it's
my view that this too will happen to scene graph API's.

We are already seeing with nVidia T&L cards that you
need to lock your data into particular chunks of memory
and send data to the card in carefully chosen chunk sizes
if you want to get the very best performance.  Those are
the kinds of *ugly* things that applications shouldn't
have to deal with - they should be hidden inside a well
written scene graph API - and if it were standardized
across various cards, it could hide these kinds of
hardware differences that OpenGL and D3D cannot.

SGI's new 'shader language' is an example of this too -
it's not a 'scene graph' API - but another way to look
at a higher level rendering API.  As scene graph API's
are to geometry, so shader languages are to state. They
can play nicely together too.

Scene Graph/Shader API's *will* be the next step - it's
just a matter of when the balance tips in their favor.

One thing that DOES concern me though is the lack of any
prior 'open' standardization efforts in this area.  I was
saddened that OpenGL++ didn't ever appear.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Timur D. <ti...@3d...>]

As i see there`s quite a bad situation on SG  scene..
most engines implements thier own propritary scene graphs,
some better some worser, this days 3D Engine = proprietary scene graph. (as
in old days 3D engine was set of fast rasterizers)
but there`s no standart, and now after Fahrenheit blowup, seems there`s no
hope for standart SG in nearest future, unfortuntaly


_______________________
 Timur Davidenko.
 3Dion Inc. (www.3dion.com)
 e-mail: ti...@3d...


----- Original Message -----
From: "Ko, Manchor" <MAN...@ca...>
To: <gda...@li...>
Sent: Tuesday, September 05, 2000 11:48 PM
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs


> I completely agrees with akbar and Stephen on this. Even if you decided
not
> to use an off the shelf scene graph API. Do built one yourself. If you
think
> you can do a good one. It is not a trivial task to built a good one. This
is
> an area that I have done quite a lot of work on.
>
> The SGI/Microsoft ill-fated Fahrenheit would be the cross-platform
Opengl++.
> You know what happened to it. Fahrenheit is actually architected quite
well.
> But that is another story....
>
> -----Original Message-----
> From: Akbar A. [mailto:sye...@ea...]
> Sent: Tuesday, September 05, 2000 1:20 PM
> To: gda...@li...
> Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> hey,
>
> >Hence, whilst it's theoretically possible to make your game
> >run faster by writing it all in machine code
> you would have to be one very smart person to pull this one off. topping
of
> what the compilers' are generating is getting harder and harder (iirc vc7
is
> coming out later this year), plus there is the time it takes to write good
> low-level code :|
>
> >When it first appeared, everyone wanted to get at some lower level
> >'bare metal' interface to the hardware for speed.
> yes, i find this quite funny. remeber when everyone was like "give us the
> metal" and saying other things like this. then when they finnally got it
> with the psx2 a lot of them ran into problems (but they learnt a lot ;)
>
>
> >lots of people complained that it stifled their
> >creativity and wouldn't let them get at pixels in the
> this is somewhat true. there where some really cool demos back in the dos
> days that never made the converge to OpenGL.
>
> in general scenegraphs are good, they lay out a lot of foundation work so
> you don't have to reinvent "to much" of the wheel.
>
> btw, new movies up at www.sgi.com.
>
>
>
>
> peace,
> akbar A.
>
>
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of
> Stephen J Baker
> Sent: Tuesday, September 05, 2000 1:22 PM
> To: gda...@li...
> Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs
>
>
>
> > At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs:
> Wired
> > or Tired" to discuss this, although not necessarily from a game
> development
> > standpoint.
>
>
> I think scene graphs are like so many other aspects of making high
> performance applications - we used to write machine code - compilers
> were considered terribly inefficient.  Now compilers are getting
> better (so they are less wasteful) - machines are getting faster
> (so we care less) - and machines and our programs are getting
> COMPLICATED (so writing machine code is less possible).
>
> Hence, whilst it's theoretically possible to make your game
> run faster by writing it all in machine code - nobody does
> that anymore.
>
> I think the same thing happens with API's like OpenGL.  When
> it first appeared, everyone wanted to get at some lower level
> 'bare metal' interface to the hardware for speed.  I don't think
> anyone is advocating that anymore...for much the same reason
> that we don't use raw machine code anymore.
>
> Well, Scene Graph API's are quite possibly the next stage of
> evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
> DOING you can get better performance by writing your own
> low level engine to the 'raw' OpenGL.  But as multi-pass
> rendering, shadows, etc get more and more complicated and
> the machines get faster and the scene graph API's get better,
> I believe there comes a point where you shrug your shoulders
> and say "who cares" about the small performance loss that
> comes from a generic rendering API versus something more
> optimised to your application that you could have written
> yourself.
>
> Just as with compiler technology, the point where you decide
> to switch depends a lot on how demanding your application
> is and how skilled you are.  Red hot x86 machine coders
> writing state of the art games were writing machine code
> long after the amateur Tetris clone writers had switched
> to C compilers.
>
> Another aspect to this was that when OpenGL first appeared
> on the PC, lots of people complained that it stifled their
> creativity and wouldn't let them get at pixels in the
> frame buffer.  It's really noticable how those sorts of
> complaints have tailed off over the last few years...I
> think we hear the same things about scene graph API's.
>
>   For some people "it forces us all into the same mold"
>   For other people "it liberates me from having to think
>      about the polygons so I can concentrate on higher
>      level stuff"  -- like physics for example.
>
> Finally, what forced people into using OpenGL (or D3D
> for that matter) was sheer hardware necessity - and it's
> my view that this too will happen to scene graph API's.
>
> We are already seeing with nVidia T&L cards that you
> need to lock your data into particular chunks of memory
> and send data to the card in carefully chosen chunk sizes
> if you want to get the very best performance.  Those are
> the kinds of *ugly* things that applications shouldn't
> have to deal with - they should be hidden inside a well
> written scene graph API - and if it were standardized
> across various cards, it could hide these kinds of
> hardware differences that OpenGL and D3D cannot.
>
> SGI's new 'shader language' is an example of this too -
> it's not a 'scene graph' API - but another way to look
> at a higher level rendering API.  As scene graph API's
> are to geometry, so shader languages are to state. They
> can play nicely together too.
>
> Scene Graph/Shader API's *will* be the next step - it's
> just a matter of when the balance tips in their favor.
>
> One thing that DOES concern me though is the lack of any
> prior 'open' standardization efforts in this area.  I was
> saddened that OpenGL++ didn't ever appear.
>
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Stephen J B. <sj...@li...>]

On Wed, 6 Sep 2000, Timur Davidenko wrote:

> As i see there`s quite a bad situation on SG  scene..
> most engines implements thier own propritary scene graphs,
> some better some worser, this days 3D Engine = proprietary scene graph. (as
> in old days 3D engine was set of fast rasterizers)
> but there`s no standart, and now after Fahrenheit blowup, seems there`s no
> hope for standart SG in nearest future, unfortuntaly
 
The worst part of it is that without a standard SG, there is no
way to promote the writing of generic 3D file loaders - which is
something that's badly needed IMHO.

----
Science being insufficient - neither ancient protein species deficient.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Patrick E. H. <hu...@tr...>]

>> but there`s no standart, and now after Fahrenheit blowup, seems there`s no
>> hope for standart SG in nearest future, unfortuntaly
> 
>The worst part of it is that without a standard SG, there is no
>way to promote the writing of generic 3D file loaders - which is

So where does Inventor and the *.iv format fit into this now that (I
believe) it has become an open-source environment?

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Graham S. R. <gr...@se...>]

I posted some details about Open Inventor in my other message on this
thread, and about IRIS/OpenGL Performer as well. Mainly some comments and
links.

Of course, VRML97 is a "standard" SG format as well.

Graham Rhodes

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of
> Patrick E. Hughes
> Sent: Wednesday, September 06, 2000 12:01 PM
> To: gda...@li...
> Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> >> but there`s no standart, and now after Fahrenheit blowup,
> seems there`s no
> >> hope for standart SG in nearest future, unfortuntaly
> >
> >The worst part of it is that without a standard SG, there is no
> >way to promote the writing of generic 3D file loaders - which is
>
> So where does Inventor and the *.iv format fit into this now that (I
> believe) it has become an open-source environment?
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Stephen J B. <sj...@li...>]

On Wed, 6 Sep 2000, Patrick E. Hughes wrote:

> >> but there`s no standart, and now after Fahrenheit blowup, seems there`s no
> >> hope for standart SG in nearest future, unfortuntaly
> > 
> >The worst part of it is that without a standard SG, there is no
> >way to promote the writing of generic 3D file loaders - which is
> 
> So where does Inventor and the *.iv format fit into this now that (I
> believe) it has become an open-source environment?

There are dozens of OpenSourced scene graph API's out there.
Inventor becomes yet another.  There are dozens of file formats
out there - .iv becomes yet another (and it's essentially just
VRML anyway - IIRC)

Adding another to the existing pile doesn't make for standardization.

----
Science being insufficient - neither ancient protein species deficient.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Jonathan W. <JW...@bi...>]

on 9/6/00 12:37 PM, Stephen J Baker at sj...@li... wrote:

>> So where does Inventor and the *.iv format fit into this now that (I
>> believe) it has become an open-source environment?
> 
> There are dozens of OpenSourced scene graph API's out there.
> Inventor becomes yet another.  There are dozens of file formats
> out there - .iv becomes yet another (and it's essentially just
> VRML anyway - IIRC)
> 
> Adding another to the existing pile doesn't make for standardization.

Would one size fit all? I have my own set of requirements for a scene graph,
didn't find anything out there that suited these requirements - which is why
I'm forced to write my own. I don't think it is possible to create scene
graph library and make it as generically useful as for example the C++ STL.

Which reminds me, are there any design patterns relating to scene graphs
anywhere? Had a quick look but didn't find anything.

    Jon.

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Graham S. R. <gr...@se...>]

Jon wrote,

> Which reminds me, are there any design patterns relating to scene graphs
> anywhere? Had a quick look but didn't find anything.

"Directed Acyclic Graph"? Could that be considered a pattern?

Graham

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Jonathan W. <JW...@bi...>]

on 9/6/00 1:53 PM, Graham S. Rhodes at gr...@se... wrote:

>> Which reminds me, are there any design patterns relating to scene graphs
>> anywhere? Had a quick look but didn't find anything.
> 
> "Directed Acyclic Graph"? Could that be considered a pattern?
> 
> Graham

There's just a little bit more to it than that :-)

    Jon.

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Stephen J B. <sj...@li...>]

On Wed, 6 Sep 2000, Jonathan Wight wrote:

> >> So where does Inventor and the *.iv format fit into this now that (I
> >> believe) it has become an open-source environment?
> > 
> > There are dozens of OpenSourced scene graph API's out there.
> > Inventor becomes yet another.  There are dozens of file formats
> > out there - .iv becomes yet another (and it's essentially just
> > VRML anyway - IIRC)
> > 
> > Adding another to the existing pile doesn't make for standardization.
> 
> Would one size fit all? I have my own set of requirements for a scene graph,
> didn't find anything out there that suited these requirements - which is why
> I'm forced to write my own. I don't think it is possible to create scene
> graph library and make it as generically useful as for example the C++ STL.
 
I know what you mean (I've written my own scene graphs too)...but the
point of my earlier (L-O-N-G) post was that when things like this
initially appear, everyone feels like they could do better writing
to a lower level and doing it themselves - but as time progresses,
we'll get faster machines, better scene graph API's and there will
come a point where (just as with C++ compilers) it's just better
to use a standard API than roll your own for each new project.

If there was a standard SG API, then there would eventually be
hardware to accellerate it, lots of loaders for standard file
formats, we could have standardized collision detection
libraries, physics libraries...those things are not reasonably
possible currently because there is no standard SG API for them
to work with.

Once all those things exist, I think you'd be much more inclined
to accomodate the (hopefully few) limitations of the SG in order
to reap the benefits of working at a higher level abstraction.

This is precisely the state we were at when everyone was
writing pixels into frame buffers and *thinking* about going
to a standard rendering API rather than writing their own
rasterizers for each new project.  There were the exact same
concerns about (say) OpenGL being not *quite* as flexible as
a renderer you could write yourself - and it was lower in
performance.  Then hardware that could make use of OpenGL
came about and over about a year, everyone forgot about
writing their own rasterizers anymore.

Perhaps we just aren't ready for that next step up yet.
I happen to think that the time is about right.

----
Science being insufficient - neither ancient protein species deficient.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Dave S. <Dav...@sd...>]

Jonathan Wight wrote:
> Which reminds me, are there any design patterns relating to scene graphs
> anywhere? Had a quick look but didn't find anything.
> 
>     Jon.
> 

Good question.  I have just been browsing the popular
API's (Performer, Java3D, PHIGS, etc..) for ideas but that's
a major pain.  

-DaveS

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Dave E. <eb...@ma...>]

From: "Stephen J Baker" <sj...@li...>
>The worst part of it is that without a standard SG, there is no
>way to promote the writing of generic 3D file loaders - which is
>something that's badly needed IMHO.

Standardization is evil.  Okay, a strong statement
to make :)  Perhaps better is to point out that
standardization and innovation are in direct conflict.

From: "Jonathan Wight" <JW...@bi...>
> Which reminds me, are there any design patterns relating to scene graphs
> anywhere? Had a quick look but didn't find anything.

As an abstract problem, if your scene graph really is
a directed acyclic graph, then a streaming system
should save the nodes and arcs of the graph and be
able to load them and recreate the graph.  I cover this
topic in my game engine book to show how an
object-oriented system can do this assuming that the
classes of the node objects are derived (directly or
indirectly) from a base class that has RTTI and some
other basic support.  The arcs of the graph correspond
to the pointer members that point to objects derived
from the base class.  On "save", the system builds a
list of unique objects by a graph traversal.  Each object
knows how to write itself to disk.  Pointer members are
written as is.  On "load" the system has a lot more work
to do.  The main problem is that the pointer members on
disk no longer correspond to valid memory addresses.
So you really need a loader/linker system.

Such a system is extensible to new objects simply by
class derivation.  Each new class implements the
necessary member functions (5 in my system: create
a new object, load from disk, link pointer members,
add self to save-list, save to disk).

--
Dave Eberly
eb...@ma...
http://www.magic-software.com