Hi Ahmed, > In my case i will have some of the nodes with time "t" and some with "t-1".
This may be not a problem with OpenTissue, but may be one for other engines. I think we should adress that problem. > 2- what we want is a conversion from OSG scene node to PAL. > this conversion will be done in the first step only. So you build your OSG scene and then create a PAL equivalent? I must say this is a suprising approach! I have the intention of manually creating the physics... because in many applications, physics objects are not exactly what you see (they are often simplified). I suggest that your "OSG to physics" conversion should be an additional (and separated) feature for those who want to use it. > I think it will be because DUT is much more faster than PUT. This ay depend a lot on what you are simulating :) I personnaly won't made such an assertion for osgPhysics. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 12:51:02 +0100, Ahmed Nawar <ahmed.na...@bibalex.org> a écrit: > Hi Sukender, > >>"What happens if OSG updates the scene while the physics do the same???" > In my case i will have some of the nodes with time "t" and some with "t-1". > but this will be fixed in almost the second osg frame ( osg is much more fast > than physics) > and because osg scene graph is separated from physics nodes. this will not > Affect the result of physics. > (Else we have to buffer values.) > > >>> 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. > >> I'm sorry but I don't understand what you mean. > > 1- "PositionAttitudeTransform like node" is your "ThreadSafeMatrixTransform". > In it we must make sure that when PUT change the data The DUT will not change > any value in it while draw. > > 2- what we want is a conversion from OSG scene node to PAL. > this conversion will be done in the first step only. > we can add a abstract conversion method and all nodes must overwrite it. > (it must handle complex scene and this was not in my case. > my case was PositionAttitudeTransform for each graph boxes and spheres i want > to simulate there behave) > > >>So I'm wondering if DUT and PUT are mutually exclusive > I think it will be because DUT is much more faster than PUT. > > thanks, > Ahmed Nawar > ________________________________________ > From: osg-users-boun...@lists.openscenegraph.org > [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender > [suky0...@free.fr] > Sent: Thursday, January 15, 2009 1:23 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started! > > Hi Ahmed, > >> I think the multi threading is a must [...] > > 100% agreed :) > > >> 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. > > Is it like a "ThreadSafeMatrixTransform"? What happens if OSG updates the > scene while the physics do the same??? > > >> 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. > > I'm sorry but I don't understand what you mean. > > >> I can work with you on osgPhysics if you want. > > Well, that's if *you* want! :) Sice osgPhysics is opened to anyone. > Feel free to discuss with us, or propose code changes. And if you want write > access to the SVN repository, then you should give us your SF.net UNIX name. > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > _______________________________________________ > 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
