Mathias Fröhlich wrote: > Hi Tim, > > On Thursday 25 June 2009 23:58:42 Tim Moore wrote: >> Mathias Fröhlich wrote: >>> Hi Tim,
> >> 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 > ... > I understand the desire, it's just that I thought of simgear as a glue layer between OSG and flightgear, and thus OK to use OSG datatypes everywhere. I'll be more restrained in the future. Anyway, I screwed around a bit with making the SGVec types more directly compatible with OSG functions. Conversion operators don't help much; making osg::Vec types be public superclasses of SGVec helps a lot of course, but I can understand if you don't want to go that route. In the end, I can live with the status quo for my purposes. > 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. We can now rely on std::tr1:shared_ptr and its cousins, through Boost if need be, so perhaps we could come up with some nice templates to paper over the differences between OSG pointers an our own. > 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. Sounds reasonable. Tim ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
