: www.bibalex.org,
From: osg-users-boun...@lists.openscenegraph.org
[osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz
[pma...@skew-matrix.com]
Sent: Thursday, January 15, 2009 1:18 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users
Hi Sukender,
On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr wrote:
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
(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
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
(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
[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
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
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
Hi Sukender,
On Thu, Jan 15, 2009 at 12:06 PM, Sukender suky0...@free.fr wrote:
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
Hi Sukender,
On Thu, Jan 15, 2009 at 10:48 AM, Sukender suky0...@free.fr wrote:
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
Hi Robert, hi all,
Robert, I didn't say it before, but thanks for giving us your thoughts/ideas.
So there is, IMO, 3 viable solutions:
1. A simple thread safe matrix transform.
Benefits: Simple and fast.
Drawbacks: You may have t and t-1 matrices. Can't do
interpolations/extraploations. That
Hi Sukender, hi all,
I would first introduce the implementation of osgPhysics at present:
1. Create a World (derived from Group) instance.
2. Create some RigidActor (derived from Transform) instances and add them as
the World's children.
3. While the simulation running, the World will have a
Hi Robert, hi all,
I got a question! Robert and I discussed the fact that the future osgAudio
may have a specific update traversal.
1. Do you think it could be wise to do a similar physics update traversal for
osgPhysics?
2. If so, is there a way to code things in OSG so that osgPhysics could
Hi Sukender,
Gratulations to the newly started project!
I had created a subforum (osgPhysics) on our forum. I've also connected the
[osgPhysics] tag with this forum. Hence we have a direct place where to post or
where to read the related questions ;)
Best regards,
art
--
Read
Hi Art,
I forgot to ask you about the tag on the forum, and you did it! Marvelous! :)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Wed, 14 Jan 2009 15:59:08 +0100, Art Tevs stud_in...@yahoo.de a écrit:
Hi Sukender,
Gratulations to the newly
Well, the problem is that physics don't run at the same rate as
display. For instance, we should run a physics update traversal
at 100Hz, and the normal update traversal the fastest possible
(well, limited by the VSYNC).
Then the physics update would run in a separate thread, and you'd need
I'm using PAL for a physics integration with delta3d. I'm still confused
about why people want to integrate things like physics and audio into a
scene graph, but that aside, I am adding features and such to PAL since
I have commit access.
We should all work together implementing features in
Hi Paul, Sukender et al,
On Wed, Jan 14, 2009 at 5:01 PM, Paul Martz pma...@skew-matrix.com wrote:
Then the physics update would run in a separate thread, and you'd need some
mechanism to pull the physics state into OSG during the update traversal.
I guess I don't understand why this pull
Hi Paul,
Thanks for the answer... and thanks for improving osgPhysics by the way of
discussion.
Well, the problem is that physics don't run at the same rate as
display.
Then the physics update would run in a separate thread, and you'd need some
mechanism to pull the physics state into OSG
Hi David,
Thanks for the info. And yes, you're right about implementing features in PAL.
About the integration of audio and physics, we aim at giving users an easier
access to features often coupled with scene graphs. Doesn't it make sense for
you? Or maybe we're not talking about the same
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
Sukender wrote:
Hi David,
Thanks for the info. And yes, you're right about implementing
features in PAL.
About the integration of audio and physics, we aim at giving users an
easier access to features often coupled with scene graphs. Doesn't it
make sense for you? Or maybe we're not talking
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)
Hi Hannes(?)
PAL is an abstraction layer for real-time simulation, such as games. However,
there is nothing against adding support for complex physics to PAL or
osgPhysics. This is true that it is not our first intention for osgPhysics but
the project is a layer to whatever you need. So maybe
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
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
-users] [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
27 matches
Mail list logo
