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.



Flightgear-devel mailing list

Reply via email to