Hi Tim, On Thursday 25 June 2009 23:58:42 Tim Moore wrote: > Mathias Fröhlich wrote: > > Hi Tim, > > > > On Thursday 25 June 2009 10:22:54 Tim Moore wrote: > >> OK, but in case you hadn't noticed, libsgmath depends on OSG. > > > > Yes I have noticed that change in the quaternion/matrix. > > If you mean the methods in SGGeod that return osg::Matrix, I wrote them > that way because the values get plugged directly into the scene graph. Sure, no problem or offense here. I just might replace that with something that removes that dependency.
> > I believe that we should get rid of that. > > And yes, the vector storage is from osg. But it is a few line change to > > get rid of that. That was designed for that :) > > And then you can change the ~100 uses of '.osg()' to access that storage. > :) Yes, I know. The read from SG write to osg portion is easy to handle. The other way was to ease the transition and will be way less to change if one needs to... If you want to I can change that so that we *are* independent instead of being nearly independent. > Seriously, I didn't realize that reducing dependencies on OSG in simgear is > a design goal. That's fine, but I would really prefer to not think about > whether I need to pass an SGVec3d or an osg::Vec3d to a function, or > whether a smart pointer should be an osg::ref_ptr or an SGSharedPtr or... I see you point. I would not tell that a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL. Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all. I already did so when I started to switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around. So please avoid having osg::whatever spread around in the whole application ... Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that separation where possible/sensible. More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ... What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing there. Just to be more flexible with extensions in this area we might need, I would like to have our own stuff. So I do not need to introduce a change to Robert and then wait a few months before I can rely on people having that change available in flightgear ... I can find many more benefits of this stuff we have already. The rule of thumb when to use what is simple: If you are in the scene graph most probably osg::... might be a good thing to use. If you are in the simulation, network, input system, property system, wherever not scene graph dependent, use simgears own classes. So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term. Greetings Mathias ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
