The integration of PAL with OSG would in my opinion, be a waste of resources. PAL isn't maintained well, and doesn't support all of the features of the engines that it contains. In addition, documentation is -really- scarce for it. I do agree with Robert though, that any additions made to OSG source should be generic to any particular engine; however I'm not opposed to contributing to a library that specializes in a particular engine beyond the scope of those changes.
On Tue, Nov 4, 2008 at 3:57 AM, Max Pfingsthorn <[EMAIL PROTECTED]>wrote: > Hi, > > there is the Physics Abstraction Library > (http://www.adrianboeing.com/pal/index.html , > http://pal.sourceforge.net). I'm not sure to what extend that is > useful, but it seems to be rather popular. It already abstracts ODE, > Bullet, and other, even commercial, engines. Possibly worth a look. > > I actually plan to use OSG (or Ogre3D, the jury is still out) with PAL > for a robotics simulator, which might become the successor of USARSim > (http://usarsim.sourceforge.net). Some more direct integration between > OSG and some physics abstraction (PAL or homegrown) would be great! > > Cheers, > max > > On Tue, Nov 4, 2008 at 10:27 AM, Robert Osfield > <[EMAIL PROTECTED]> wrote: > > Hi Guys, > > > > It's good to see a number of different users popping with discussion > > of their own work on integrating physics with the OSG. I would be > > great to have an OSG NodeKit for doing physics, but I'm very wary of > > tying to one specific engine as each engine has it's own strengths and > > weakness, and I also don't want to steer people away from making > > particular physics engine choices including closed source ones - such > > as Vortex, users should be able to integrate the best tool for they > > job they can afford. > > > > So I'd like to punt the possibility of having some kind of base > > osgPhyics API that makes it easier to bolt on different physics > > engines onto the OSG. This would require spotting the commonality > > between the different engines and distilling this, for instance the > > osgViewer library does this trick to a certain extent with the > > different GraphicsWindow implementations. You also don't want to hide > > too much of the implementation advanced phyics engine tuning will > > probably require users to grapple with the lower level physics engines > > settings. While abstracting completely is impracticable it'd be good > > to provide the template for the concrete implementations, and also > > make it easier for applications to move between different physic > > engines at the backend. > > > > Is such a lib possible or practical? It'll be more wore initially > > than just an osgODE, osgBullet or osgVortex library but longer term it > > could reduce the cost of maintenance of all these different > > variations. The first step in this direction would be to see the > > code of various physic engine + OSG integration with a view to > > spotting the commonality between them. > > > > Thoughts? > > Robert. > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
