Dirk Reiners wrote: > 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.
They usually are, even without OpenSG's specific design. Lot's of memory to be touched when there are relatively little 'real work' to be done. > 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. Agreed. > 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. Linking an 'SimpleAnimationMgr' to a window and then updating that so that all animation is computed and the window is rendered is maybe a way to go. Giving the Window knowledge of the animation system sound a bit awkward. > 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? Eberly's WildMagic and it's commercial twin NetImmerse/Gamebryo. The first one I've mentioned before. >> 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. I haven't dug into VRML's data-flow at all (shame on me), but I've seen some of Maya's internals which sound similar to what you say. Quite messy and still doesn't solve everything. In our app, we have some similar dependency problem (updating physics state when you have tracking, grabbing, locking, friction, constraints and are not able to solve the latter two by the academic 'global-equation-system' approach due to time-constraints), and it seems well so far. We are planning on extending it to general object 'updating'. > 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. If I just knew how to start with a separate DLL (OSGAnimation?) and was able to compile it properly, given that the Collada-loader get's done, I could try making something for myself and see how it goes. I could, of course, just cook up a bunch of source files using my own build system (mostly MSVS-vcproj based) and try to keep them only-OpenSG-dependent and then toss them at you to integrate once I reach some kind of critical point. /Marcus P.S. I need to get some work done today. Will be silent for a while now. :) ------------------------------------------------------------------------- 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 Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
