Hi Tim, On Saturday 20 June 2009 19:46:50 Tim Moore wrote: > Actually, I am using osg::Vec3d and osg::Vec4d. I tend to view the SGVec > types as redundant, but that's a personal preference. I don't mind using > SGVec in the property system, but if I do that I would like to add an > operator to SGVec* to provide a conversion to its internal OSG type. Well, from my point of view. I would prefer to have these. The reason is to have something self contained here. Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg.
... also from my past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ... So, even if you will need some more glue code, I would prefer to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area IMO ... > Yeah, but we do that in the OSG "update" phase, which is exactly when these > updates are supposed to happen. Nothing that alters the scene graph can run > during the cull and draw phases, but we have to be able to alter the scene > graph at some point. Note that I distinguish between the application step, which happens before the update step and the real update step which is the update visitor's traversal. And in the mid term, we may run the application step in parallel to the cull draw step. So we will just have a very short serial update step. So, in this model - where I am heading to in the mid/longer term, this listener usage hurts. > The point is well taken, but the property listeners would be on properties > that are directly tied to the effect structures and are not in the main > property tree. For the foreseeable future they will be set from C++ > material animation code, but I don't see a real problem in setting them > from nasal code. It's true that accessing the scene graph safely from > multiple threads is going to be an interesting challenge... May be that does not hurt currently. But if there is a way around that kind of issue I would prefer to take that. May be we will make more use of a more distributed simulation system. In this case the listeners in the viewer would not be an issue anymore, but if you can see a way that would allow the simulation step to run in parallel with cull/draw, it would be good I think. Greetings Mathias ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
