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