Hi Allen, hi Marcus,
On Thu, 2006-08-17 at 06:43 -0500, Allen Bierbaum wrote:
>
> I think one of the reasons for this is that OpenSceneGraph has an app
> traversal to update animations and other changes in the graph. OpenSG
> currently doesn't support this as a first class traversal. I know we
> would really like to see some type of support for this formalized so we
> can put more logic into the scene graph where it makes sense for our
> applications.
The core reason is that I don't have a lot of experience writing these
parts and so far haven't had the brain bandwidth to really think about
it. Furthermore first-class traversals in OpenSG are necessarily more
expensive than in simpler systems due to the goal of extensibility
without code changes, which makes an additional full traversal just for
possible animations an expensive proposition.
Another big reason is that I wanted to keep OpenSG more flexible than
the usual game engine which allows one view into one scene. OpenSG
allows you to have an arbitrary number of independent scenes and
Windows/Viewports into each one of them, all of which can be
updated/rendered independently (render only for Windows). So integrating
something that is done as a side-effect of rendering doesn't seem to be
a good idea to me.
I could see something that is a separate structure that references the
Nodes. It could be stored as attachments to the root nodes or other
nodes, which would make it cluster- and osb-able. For simplicity's sake
it would be possible to add something to the Window to execute it before
rendering, so that for simple apps things simply work without preventing
more complex apps from being possible.
There are probably a ton of details (like the synced time) that need to
specified, but I don't see it being impossible.
On Thu, 2006-08-17 at 14:33 +0200, Marcus Lindblom wrote:
>
> I think it makes sense to separate 'object-update-with-time' traversal
> and the scene-graph itself. Attempting to bundle everything together in
> one interface (i.e. Node) tends to make things a bit messy in terms of
> dependencies. (I've seen some such systems.)
Do you have links or papers to something like this?
> But yes, some kind of time-dependent framework which would update the
> visual components would be very nice.
No doubt.
> The problem with all systems is that you need to handle ordering of
> update dependencies somehow. I.e. first update transforms from time &
> data, then compute skinning and/or setup shader constants. Adding
> normalization/tangent space and other derived data to this makes it even
> trickier. Usually, we solve such things by create a directed graph from
> each objects dependency and sorting that to get an update order (this is
> only done when the ordering is dirty.)
The VRML approach is essentially a directed data-flow graph, too. Many
general systems try to base all their programmability on that, which
leads to rather serious complications for actual work. But using it at a
high level might make sense.
Overall I agree that it would be very desirable to have, but personally
I just don't have the time to do it (I just moved to a new city, I'm
starting a new job and I'm in the process of getting married. 24 hours
in a day just don't cut it any more... ;). If other people want to take
a shot at it I'd be very happy to support it and make any changes to the
core necessary to simplify things, but I just can't take the lead on
this, sorry.
Yours
Dirk
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
