OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Project osgPhysics started!

Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> osgPhysics [osgPhysics]
View previous topic :: View next topic  
Author Message
Paul Speed
Guest





PostPosted: Wed Jan 14, 2009 10:11 pm    Post subject:
Project osgPhysics started!
Reply with quote

My experience is admittedly limited here, but I think some of us are
coming from the position that your physics "graph" is an entirely
different thing than the render "graph". The two are often completely
orthogonal.

In one case you may have physics body represented by something simple
like a ball... where as for various implementation reasons your scene
graph may need to be a whole pile of objects. Conversely, sometimes a
whole mess of physics parts/bodies/bones/whatever may decompose into a
single mesh and a custom shader to move the points around.

While there may be parts similar between a physics "node" and a scene
graph "node", I'm not sure they are similar enough to justify being
related in a class hierarchy.

...and maybe you are already taking all of that into consideration and
I've misunderstood the conversation so far. It just sounds like you are
trying to have the physics engine directly "act" on scene graph nodes
versus transferring values transform information from the physics nodes
to the scene graph nodes. I think you will pay dearly for the
"convenience". :)

-Paul

Sukender wrote:
Quote:
Hi David,

Well, what we intend to do is simply provide a "plug" so that you can do what you want. Morover, the osgPhysics' aim is to drive nodes in the graph by the way of physics. We don't plan to make physic objects to be "cullable", or things like that. Changeing the renderer (like raytracing) would not affect things handled by osgPhysics.
I hope this is a bit clearer! :)

About Adrian, I also discussed a few points with him, and I may contribute to PAL too. And yes, he's in Australia... Wang Rui (osgPhysics, osgNV) is in China, and I'm in France... well it may be difficult to be all online for a chat, but we still can work :)

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Quote:
I guess I understand why people do it, but I would rather that OSG kept the limited scope of being a scene graph, that is with the features just of doing 3d rendering. I think a more limited scope makes it more useful as a drop in component of a game engine.

physics and audio, while they are necessary in a game or simulation engine, they are not rendered, and I don't think they belong in a scene graph. In delta3d, we have, and are more and more trying to separate things such as drawing, physics, and audio from simulated objects (actors) so that actors can be composed of these features via componentization and messaging. We would eventually even like delta3d to have the ability to use different renderers.

As technologies like raytracing become more prevalent, the scene graph may have change a fair bit, but that shouldn't affect the audio and physics systems.

Originally we had wanted to work with Robert more closely to make delta3d have game engine features, and osg have the rendering features, but things didn't evolve that way.

Either way, this is not a discussion for the osgPhysics list. I'm making dtPhysics, which appears to have nearly exactly the same goals as you have except that we intend to integrate with delta3d its component system.

I email back and forth with Adrian Boeing a fair bit, and I have commit access to PAL, as I said before, so we would discuss the features and direction of PAL, as we see it. Perhaps PAL needs a mailing list, or maybe we need to do something more like a telecon to discuss things. I don't know where in the world you are. I'm on the east coast of the US. Adrian is, I think, in Australia. So, I'm not sure how practical that is.





------------------
Post generated by Mail2Forum
Back to top
Paul Martz
Guest





PostPosted: Wed Jan 14, 2009 11:18 pm    Post subject:
Project osgPhysics started!
Reply with quote

Quote:
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



------------------
Post generated by Mail2Forum
Back to top
Paul Martz
Guest





PostPosted: Wed Jan 14, 2009 11:25 pm    Post subject:
Project osgPhysics started!
Reply with quote

Ditto this post. In my Bullet work, the physics representation is based on,
but separate from, the OSG visual representation. The two "graphs" are only
tied together at Transform nodes that allow Bullet to drive the
transformations of the visual representations of rigid bodies.

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-----Original Message-----
From:
[mailto:] On Behalf Of Paul Speed
Sent: Wednesday, January 14, 2009 3:08 PM
To: OpenSceneGraph Users
Subject: Re: [osgPhysics] Project osgPhysics started!

My experience is admittedly limited here, but I think some of us are coming
from the position that your physics "graph" is an entirely different thing
than the render "graph". The two are often completely orthogonal.

In one case you may have physics body represented by something simple like a
ball... where as for various implementation reasons your scene graph may
need to be a whole pile of objects. Conversely, sometimes a whole mess of
physics parts/bodies/bones/whatever may decompose into a single mesh and a
custom shader to move the points around.

While there may be parts similar between a physics "node" and a scene graph
"node", I'm not sure they are similar enough to justify being related in a
class hierarchy.

...and maybe you are already taking all of that into consideration and I've
misunderstood the conversation so far. It just sounds like you are trying
to have the physics engine directly "act" on scene graph nodes versus
transferring values transform information from the physics nodes to the
scene graph nodes. I think you will pay dearly for the "convenience". :)

-Paul

Sukender wrote:
Quote:
Hi David,

Well, what we intend to do is simply provide a "plug" so that you can do
what you want. Morover, the osgPhysics' aim is to drive nodes in the graph
by the way of physics. We don't plan to make physic objects to be
"cullable", or things like that. Changeing the renderer (like raytracing)
would not affect things handled by osgPhysics.
Quote:
I hope this is a bit clearer! :)

About Adrian, I also discussed a few points with him, and I may
contribute to PAL too. And yes, he's in Australia... Wang Rui
(osgPhysics, osgNV) is in China, and I'm in France... well it may be
difficult to be all online for a chat, but we still can work :)

Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/


Quote:
I guess I understand why people do it, but I would rather that OSG kept
the limited scope of being a scene graph, that is with the features just of
doing 3d rendering. I think a more limited scope makes it more useful as a
drop in component of a game engine.
Quote:
Quote:

physics and audio, while they are necessary in a game or simulation
engine, they are not rendered, and I don't think they belong in a scene
graph. In delta3d, we have, and are more and more trying to separate things
such as drawing, physics, and audio from simulated objects (actors) so that
actors can be composed of these features via componentization and messaging.
We would eventually even like delta3d to have the ability to use different
renderers.
Quote:
Quote:

As technologies like raytracing become more prevalent, the scene graph
may have change a fair bit, but that shouldn't affect the audio and physics
systems.
Quote:
Quote:

Originally we had wanted to work with Robert more closely to make delta3d
have game engine features, and osg have the rendering features, but things
didn't evolve that way.
Quote:
Quote:

Either way, this is not a discussion for the osgPhysics list. I'm making
dtPhysics, which appears to have nearly exactly the same goals as you have
except that we intend to integrate with delta3d its component system.
Quote:
Quote:

I email back and forth with Adrian Boeing a fair bit, and I have commit
access to PAL, as I said before, so we would discuss the features and
direction of PAL, as we see it. Perhaps PAL needs a mailing list, or maybe
we need to do something more like a telecon to discuss things. I don't know
where in the world you are. I'm on the east coast of the US. Adrian is, I
think, in Australia. So, I'm not sure how practical that is.
Quote:


org





------------------
Post generated by Mail2Forum
Back to top
Ahmed Nawar
Guest





PostPosted: Thu Jan 15, 2009 8:19 am    Post subject:
Project osgPhysics started!
Reply with quote

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: ,
Web Site: www.bibalex.org,


________________________________________
From: [] On Behalf Of Paul Martz []
Sent: Thursday, January 15, 2009 1:18 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osgPhysics] Project osgPhysics started!

Quote:
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




------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Thu Jan 15, 2009 9:10 am    Post subject:
Project osgPhysics started!
Reply with quote

Hi Sukender,


On Wed, Jan 14, 2009 at 8:59 PM, Sukender <> wrote:
Quote:
Well, multithreading *is* an issue, but we need to address the problem.
I guess the order of steps would be:
- When it is time to update the physics, run the "physics update traversal" (say "PUT") in a physics thread
- PUT
- PUT
- ...
- When the times come to update the display, lock the physics thread so that no PUT runs
- Run the "display update traversal" ("DUT") in a display thread. During this, copy physics positions/orientations to transforms.
- Unlock the physics.
- PUT (physics thread), cull and draw (display thread)
- and so on.

Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea?


I would suggest supporting decoupling of the rendering and physics
threads as much as possible, without either one blocking the other.
The way I would tackle this would be via thread safe data buffers that
can be read by the rendering thread, and written to by the physics
thread, this buffer would typically be a matrix (or similar transform
representation) with a time stamp, new entries would be push to the
end of buffer, and then the rendering thread would pull at the time
interval required - perhaps interpolating between two entries or even
estimating the position beyond last entry if physics is lagging
behind. This type of buffer need only have one mutex and would only
be locked when the physics thread pushes data into it, and when the
rendering thread pulls data from it. This way neither threads should
be halted and will run happily decoupled.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 10:49 am    Post subject:
Project osgPhysics started!
Reply with quote

Hi Robert,

I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! Smile
Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield <> a écrit:

Quote:
Hi Sukender,


On Wed, Jan 14, 2009 at 8:59 PM, Sukender <> wrote:
Quote:
Well, multithreading *is* an issue, but we need to address the problem.
I guess the order of steps would be:
- When it is time to update the physics, run the "physics update traversal" (say "PUT") in a physics thread
- PUT
- PUT
- ...
- When the times come to update the display, lock the physics thread so that no PUT runs
- Run the "display update traversal" ("DUT") in a display thread. During this, copy physics positions/orientations to transforms.
- Unlock the physics.
- PUT (physics thread), cull and draw (display thread)
- and so on.

Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea?


I would suggest supporting decoupling of the rendering and physics
threads as much as possible, without either one blocking the other.
The way I would tackle this would be via thread safe data buffers that
can be read by the rendering thread, and written to by the physics
thread, this buffer would typically be a matrix (or similar transform
representation) with a time stamp, new entries would be push to the
end of buffer, and then the rendering thread would pull at the time
interval required - perhaps interpolating between two entries or even
estimating the position beyond last entry if physics is lagging
behind. This type of buffer need only have one mutex and would only
be locked when the physics thread pushes data into it, and when the
rendering thread pulls data from it. This way neither threads should
be halted and will run happily decoupled.

Robert.




------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 11:05 am    Post subject:
Project osgPhysics started!
Reply with quote

(coninued...)

I forgot to mention a thing about interpolating. Yes, this could be a nice idea to interpolate (or extrapolate) data, but I think this is a great risk for something that may not be very useful for common physics usage. I belive that realtime engines generally run at something like 50 or 100Hz (one can of course be much slower or much faster), so you may loose much time trying to interpolate; and moreover you may introduce inconstistencies (such as objects interpenetrating). So I guess simply reading the last matrix is enough.
This is what I do in my engine (not multithreaded yet), and it works without lagging. I simply created a main loop that takes care of running physics or display when necesssary.

Maybe you have a different point of view on that? I'd be happy to read!

And what about other types of engines (non realtime)? I suppose interpolating could be possible, but I still think we introduce simulation errors.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 11:48:48 +0100, Sukender <> a écrit:

Quote:
Hi Robert,

I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! Smile
Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield <> a écrit:

Quote:
Hi Sukender,


On Wed, Jan 14, 2009 at 8:59 PM, Sukender <> wrote:
Quote:
Well, multithreading *is* an issue, but we need to address the problem.
I guess the order of steps would be:
- When it is time to update the physics, run the "physics update traversal" (say "PUT") in a physics thread
- PUT
- PUT
- ...
- When the times come to update the display, lock the physics thread so that no PUT runs
- Run the "display update traversal" ("DUT") in a display thread. During this, copy physics positions/orientations to transforms.
- Unlock the physics.
- PUT (physics thread), cull and draw (display thread)
- and so on.

Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea?


I would suggest supporting decoupling of the rendering and physics
threads as much as possible, without either one blocking the other.
The way I would tackle this would be via thread safe data buffers that
can be read by the rendering thread, and written to by the physics
thread, this buffer would typically be a matrix (or similar transform
representation) with a time stamp, new entries would be push to the
end of buffer, and then the rendering thread would pull at the time
interval required - perhaps interpolating between two entries or even
estimating the position beyond last entry if physics is lagging
behind. This type of buffer need only have one mutex and would only
be locked when the physics thread pushes data into it, and when the
rendering thread pulls data from it. This way neither threads should
be halted and will run happily decoupled.

Robert.






------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 11:09 am    Post subject:
Project osgPhysics started!
Reply with quote

Hi Paul,

I'm not really sure the framerate would suffer. Actually this is what I do in my engine (I use ODE). There is absolutely no problem running 3 physics steps and then one display step. Of course this would depend on the complexity of the scene! Anyway, as explained in another post, I created a main loop that takes care of the "framerate" for each part (physics, display) and that fire off steps when necessary (without changing OSG code).
Anyway, threading would of course be better...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 00:18:19 +0100, Paul Martz <> a écrit:

Quote:
Quote:
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





------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 11:15 am    Post subject:
Project osgPhysics started!
Reply with quote

(coninued again... sorry for posting multiple times!)

I got a problem about using a kind of "ThreadSafeMatrixTransform"... What if "object 1" is updated, but not "object 2" when display update traversal (DUT) happens? Well we would see inconsistencies (like interpenetrations) too... So I'm wondering if DUT and PUT are mutually exclusive... What are your thoughts on this?

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 12:04:41 +0100, Sukender <> a écrit:

Quote:
I forgot to mention a thing about interpolating. Yes, this could be a nice idea to interpolate (or extrapolate) data, but I think this is a great risk for something that may not be very useful for common physics usage. I belive that realtime engines generally run at something like 50 or 100Hz (one can of course be much slower or much faster), so you may loose much time trying to interpolate; and moreover you may introduce inconstistencies (such as objects interpenetrating). So I guess simply reading the last matrix is enough.
This is what I do in my engine (not multithreaded yet), and it works without lagging. I simply created a main loop that takes care of running physics or display when necesssary.

Maybe you have a different point of view on that? I'd be happy to read!

And what about other types of engines (non realtime)? I suppose interpolating could be possible, but I still think we introduce simulation errors.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 11:48:48 +0100, Sukender <> a écrit:

Quote:
Hi Robert,

I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! Smile
Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield <> a écrit:

Quote:
Hi Sukender,


On Wed, Jan 14, 2009 at 8:59 PM, Sukender <> wrote:
Quote:
Well, multithreading *is* an issue, but we need to address the problem.
I guess the order of steps would be:
- When it is time to update the physics, run the "physics update traversal" (say "PUT") in a physics thread
- PUT
- PUT
- ...
- When the times come to update the display, lock the physics thread so that no PUT runs
- Run the "display update traversal" ("DUT") in a display thread. During this, copy physics positions/orientations to transforms.
- Unlock the physics.
- PUT (physics thread), cull and draw (display thread)
- and so on.

Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea?


I would suggest supporting decoupling of the rendering and physics
threads as much as possible, without either one blocking the other.
The way I would tackle this would be via thread safe data buffers that
can be read by the rendering thread, and written to by the physics
thread, this buffer would typically be a matrix (or similar transform
representation) with a time stamp, new entries would be push to the
end of buffer, and then the rendering thread would pull at the time
interval required - perhaps interpolating between two entries or even
estimating the position beyond last entry if physics is lagging
behind. This type of buffer need only have one mutex and would only
be locked when the physics thread pushes data into it, and when the
rendering thread pulls data from it. This way neither threads should
be halted and will run happily decoupled.

Robert.








------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Thu Jan 15, 2009 11:22 am    Post subject:
Project osgPhysics started!
Reply with quote

Hi Sukender,

On Thu, Jan 15, 2009 at 10:48 AM, Sukender <> wrote:
Quote:
I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! Smile
Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Perhaps a custom or user data callback would be sufficient for
managing the common data buffer, this way you could adapt the buffer
for different purposes.

As for the cost of the locking and unlocking - this is actually pretty
low, you don't want to be doing thousands of locks/unlocks per frame,
so if you do have a scene with many separate entities that are being
modelled then having composite buffers that have a single mutex
between them, and do a sync data to and from this buffer on batch
rather than each buffer individually would avoid making too many
lock/unlock calls.

As for the interpolation vs choosing the most value, this is something
that could easily be done via an option on the reading side - or
simply have two different update callbacks that read from the buffers
in different ways.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 11:23 am    Post subject:
Project osgPhysics started!
Reply with quote

Hi Ahmed,

Quote:
I think the multi threading is a must [...]

100% agreed :)


Quote:
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???


Quote:
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.


Quote:
I can work with you on osgPhysics if you want.

Well, that's if *you* want! Smile 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/



------------------
Post generated by Mail2Forum
Back to top
Ahmed Nawar
Guest





PostPosted: Thu Jan 15, 2009 11:51 am    Post subject:
Project osgPhysics started!
Reply with quote

Hi Sukender,

Quote:
"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.)


Quote:
Quote:
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.

Quote:
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)


Quote:
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: [] On Behalf Of Sukender []
Sent: Thursday, January 15, 2009 1:23 PM
To: OpenSceneGraph Users
Subject: Re: [osgPhysics] Project osgPhysics started!

Hi Ahmed,

Quote:
I think the multi threading is a must [...]

100% agreed :)


Quote:
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???


Quote:
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.


Quote:
I can work with you on osgPhysics if you want.

Well, that's if *you* want! Smile 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/




------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 12:06 pm    Post subject:
Project osgPhysics started!
Reply with quote

Hi Robert,

So, to avoid having two objects updated with 2 different time stamps, is it ok if I:
- Fill matrix buffers with physics timestamped matrices (PUT - physics thread)
- Update in a batch all the display matrices from the latest timestamp that is available over all buffers (display thread)
- Remove data that is before that timestamp on all buffers.

But then, does the batch be done before, or during the display update traversal?

Does a kind of "circular buffer that can grow as vector<>" could be the best structure for the buffer (if we reserve enough at the begining)?

Does that solution cost much RAM if we have a physics that run very frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since there is no reason for the physics to not update all objects?

I suggest then our buffer to be a "Thread safe structure with 2 matrices + 1 time stamp (latest one)".

Your thoughts? :)

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 12:21:47 +0100, Robert Osfield <> a écrit:

Quote:
Hi Sukender,

On Thu, Jan 15, 2009 at 10:48 AM, Sukender <> wrote:
Quote:
I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! Smile
Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Perhaps a custom or user data callback would be sufficient for
managing the common data buffer, this way you could adapt the buffer
for different purposes.

As for the cost of the locking and unlocking - this is actually pretty
low, you don't want to be doing thousands of locks/unlocks per frame,
so if you do have a scene with many separate entities that are being
modelled then having composite buffers that have a single mutex
between them, and do a sync data to and from this buffer on batch
rather than each buffer individually would avoid making too many
lock/unlock calls.

As for the interpolation vs choosing the most value, this is something
that could easily be done via an option on the reading side - or
simply have two different update callbacks that read from the buffers
in different ways.

Robert.




------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Thu Jan 15, 2009 12:11 pm    Post subject:
Project osgPhysics started!
Reply with quote

Hi Ahmed,

Quote:
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.


Quote:
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.


Quote:
I think it will be because DUT is much more faster than PUT.

This ay depend a lot on what you are simulating Smile 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 <> a écrit:

Quote:
Hi Sukender,

Quote:
"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.)


Quote:
Quote:
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.

Quote:
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)


Quote:
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: [] On Behalf Of Sukender []
Sent: Thursday, January 15, 2009 1:23 PM
To: OpenSceneGraph Users
Subject: Re: [osgPhysics] Project osgPhysics started!

Hi Ahmed,

Quote:
I think the multi threading is a must [...]

100% agreed :)


Quote:
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???


Quote:
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.


Quote:
I can work with you on osgPhysics if you want.

Well, that's if *you* want! Smile 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/






------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Thu Jan 15, 2009 12:43 pm    Post subject:
Project osgPhysics started!
Reply with quote

Hi Sukender,

On Thu, Jan 15, 2009 at 12:06 PM, Sukender <> wrote:
Quote:
So, to avoid having two objects updated with 2 different time stamps, is it ok if I:
- Fill matrix buffers with physics timestamped matrices (PUT - physics thread)
- Update in a batch all the display matrices from the latest timestamp that is available over all buffers (display thread)
- Remove data that is before that timestamp on all buffers.

I'd have one time stamp per matrix/value that is pushed in from the
physics thread, and then the rendering thread pulls the appropriate
matrix/maitrces/values according to the time stamp(s) that look most
appropriate.

One could also do a batch copy of from all the buffers to all the
scene graph related values at one time.

As for the data structure required, a custom ring buffer implemented
on top of a std::vector<> would probably work just fine. However, I'm
just waving my hands around, I haven't actually done much work with
physics integration personally, others who've been there and done that
would probably be best placed to give the low level recommondations.

Quote:
Does that solution cost much RAM if we have a physics that run very frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since there is no reason for the physics to not update all objects?

If you running at really high frequences then one would need to take
in account how big these buffers might get, in which case you'd want
to cut down the number of matrices/values you store, perhaps not even
record them every frame, all the rendering thread needs to one
matrix/value per frame.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> osgPhysics [osgPhysics] All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts osgQt project Davide Raccagni Submission 1 Mon Sep 26, 2016 12:03 pm View latest post
No new posts Feedback/guidance sought on move of o... robertosfield General 44 Mon Sep 05, 2016 6:50 pm View latest post
No new posts Add info about External Project and W... Konstantin Podsvirov General 1 Wed Dec 02, 2015 7:18 pm View latest post
No new posts how to use osg in the ATL project . weiskic General 0 Mon Jun 22, 2015 7:35 am View latest post
No new posts Hello and a Couple Quick Getting Star... dsargrad General 9 Sun Apr 12, 2015 1:38 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP