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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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
>