Dear All, I used "OpenTissue" for some physics simulation application with osg for rendering. Vista.bibalex.org As i red the PAL will support OpenTissue sooner.
I think the multi threading is a must, it is the future, because we must use all of our cores specialty in such heave application. My problem with the physics simulation is that the render time only take much time. So what about OpenTissue calculation. it is not a real time physics engine. I used an idea such as Sukender one but with out locking any thread. This because I have one thread(physics) put data in a shared memory and one thread (OSG) read this data. And because it is not necessary to draw all nodes of osg in the same time step of physics. I don't care, draw as much and as fast as you can,this is my case. And this help me a lot spatially in make the navigation in osg very fast. But what is the shared memory. It is of course the position of every node. So what we need to do,i think, is 1- a stander "PositionAttitudeTransform" like node. it is thread or not thread safe. 2- A traversal that read the scene graph in the first step only and fill the physics with its suitable form of node conversion. Of course with or without our hints. So we don't want to "modifying the OSG code much". and use multi threading. of course if we can modified the osg nodes to handle the PAL. it will use much less memory and be more fast for one thread. But it will be much more difficult to make it multi threading. So overall speed will be less. I can work with you on osgPhysics if you want. I am in Egypt :) Thanks, Ahmed Nawar Software Engineer, ICT Department, Bibliotheca Alexandrina, P. O. Box 138, Shatby, Alexandria 21526, Egypt, Tel: +(203) 483 9999, Extension: 1463, Email: [email protected], Web Site: www.bibalex.org, ________________________________________ From: [email protected] [[email protected]] On Behalf Of Paul Martz [[email protected]] Sent: Thursday, January 15, 2009 1:18 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started! > Well, is it possible to run "n times PUT", and then one time the > standard frame (update/cull/draw)? If so, there should be no > problem. It's possible to do it that way, but the display frame rate will suffer if the physics computation gets expensive. In my own work, I am stepping the physics simulation once, then calling osgViewer::Viewer::frame(), and I'm already seeing framerate issues when interactions get complex. If you want to step the physics simulation multiple times, it'll be even more of an issue. I think putting the physics simulation in a separate thread will make this less of a problem. It's also simpler, because it doesn't require osgPhysics to invade osgViewer, which I personally think is a bad idea. OSG has a lot of mechanisms that allow you to do physics without modifying the OSG code. I'm able to do a full Bullet physics simulation in my project, and haven't modified one line of OSG (just derived a few classes). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
