vrjuggler + osgbullet app not working in Mac

[Juan Sebastián]

Dear all,

I've created a very simple app based on (vrjuggler) OsgNav and
(osgBullet) Hinge samples, in which a RigidBody is created from a
model 10m above the ground (so it should fall). On Windows the objects
fall nicely, but on Mac, the objects stay in the air, as if the
DynamicsWorld didn't have any influence on them.

Am I missing something?

The source, with both Xcode and Visual Studio 2008 projects can be
found in https://github.com/jscasallas/VrjOsgBullet

Any help would be appreciated, thanks!
Juan Sebastian
-------------------------------------
HCI PhD Student
Iowa State University (us)
Arts et Métiers ParisTech (fr)

[Paul Martz]

I've definitely seen differences in behavior between OSX and Windows.

From personal experience, I know that dynamic_cast will often fail on OSX under
the same conditions where it succeeds on Windows. There is a possibility that a
dynamic_cast is failing somewhere, either in osgBullet or in Bullet itself.

osgBullet uses the OSG Notify system for warnings and other messages, so turning
up the Notify verbosity might be worth a try (but no guarantees).

You have both the GLDebugDrawer (so you can see if this is a physics rep/visual
rep sync problem), and also the source code (so you can set breakpoints in the
scene graph Transform or osgBullet MotionState, which is how Bullet would affect
the movement). These are good tools to start with for tracking down such an issue.

You say your code is based on the hinge example... Is the body associated with a
Bullet constraint, such as a hinge?
-Paul

> Arts et M�tiers ParisTech (fr)
>

--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/

[Paul Martz]

I'll also point out that all the examples and tests that ship with osgBullet
appear to behave correctly on OSX for me. If they also behave correctly for you
on OSX, then it should be pretty straightforward to compare your (broken) simple
example with the (working) simple osgBullet examples, and determine the source
of the problem.
-Paul

[Juan Sebastián Casallas]

Paul,

Thanks for your reply! I've answered in the e-mail:

On Mon, Nov 7, 2011 at 11:18 PM, Paul Martz <pma...@skew-matrix.com> wrote:

I'll also point out that all the examples and tests that ship with osgBullet appear to behave correctly on OSX for me. If they also behave correctly for you on OSX, then it should be pretty straightforward to compare your (broken) simple example with the (working) simple osgBullet examples, and determine the source of the problem.
  -Paul

I was about to point that out, all the examples shipped with osgBullet seem to behave correctly on my Mac, what's more, just replacing the code from my main with the code of, say, centerofmass.cpp works fine. The only tangible difference I can think of right now is the use of osgViewer (osgBullet examples) vs. vrj::Osg::App (vrjuggler).

 

On 11/7/2011 2:53 PM, Paul Martz wrote:

I've definitely seen differences in behavior between OSX and Windows.

From personal experience, I know that dynamic_cast will often fail on OSX under the same conditions where it succeeds on Windows. There is a possibility that a dynamic_cast is failing somewhere, either in osgBullet or in Bullet itself.

osgBullet uses the OSG Notify system for warnings and other messages, so turning up the Notify verbosity might be worth a try (but no guarantees).

I didn't know that, I'll try to turn up the verbosity to see if I get something more.

 

You have both the GLDebugDrawer (so you can see if this is a physics rep/visual rep sync problem), and also the source code (so you can set breakpoints in the scene graph Transform or osgBullet MotionState, which is how Bullet would affect the movement). These are good tools to start with for tracking down such an issue.

Actually my little app already has the GLDebugDrawer which helped me a lot to sync graphics and dynamics. The GLDebugDrawer's subgraph seems to be synced with the graphics, and it shows the same thing as in Windows (although the objects would remain in the air). I hope I won't need to dig as deep as setting breakpoints in Bullet to find my error =/.

  

You say your code is based on the hinge example... Is the body associated with a Bullet constraint, such as a hinge?

 

I am in the process of implementing a btPoint2PointConstraint to grab objects with vrjuggler's wand (which is the final purpose of the small app) in a separate branch, but the problem of objects not being affected by dynamics comes from the constraint-free, master branch.

  -Paul


On 11/7/2011 7:25 AM, Juan Sebastián wrote:

Dear all,

I've created a very simple app based on (vrjuggler) OsgNav and
(osgBullet) Hinge samples, in which a RigidBody is created from a
model 10m above the ground (so it should fall). On Windows the objects
fall nicely, but on Mac, the objects stay in the air, as if the
DynamicsWorld didn't have any influence on them.

Am I missing something?

The source, with both Xcode and Visual Studio 2008 projects can be
found in https://github.com/jscasallas/VrjOsgBullet

Any help would be appreciated, thanks!
Juan Sebastian
-------------------------------------
HCI PhD Student
Iowa State University (us)

Arts et Métiers ParisTech (fr)

--

You received this message because you are subscribed to the Google Groups "osgbullet-users" group.
To post to this group, send email to osgbullet-users@googlegroups.com.
To unsubscribe from this group, send email to osgbullet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgbullet-users?hl=en.

Thanks again for answering! I'll try your tips and keep you posted.

Juan Sebastian
-------------------------------------
HCI PhD Student
Iowa State University (us)

Arts et Métiers ParisTech (fr) 

[Doug McCorkle]

Hello Juan,

If your Juggler app works on Windows it should work on Mac. There should be no functional difference between your App class on Mac and Windows. I would double check your code between the two platforms to make sure things work. Paul and I both use osgBullet across both platforms without problems.

Doug

> To post to this group, send email to osgbull...@googlegroups.com.
> To unsubscribe from this group, send email to osgbullet-use...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/osgbullet-users?hl=en.
>
>
> Thanks again for answering! I'll try your tips and keep you posted.
> Juan Sebastian
> -------------------------------------
> HCI PhD Student
> Iowa State University (us)
> Arts et Métiers ParisTech (fr)
>

> --
> You received this message because you are subscribed to the Google Groups "osgbullet-users" group.

> To post to this group, send email to osgbull...@googlegroups.com.
> To unsubscribe from this group, send email to osgbullet-use...@googlegroups.com.

[Paul Martz]

On 11/7/2011 4:19 PM, Juan Sebasti�n Casallas wrote:
> I was about to point that out, all the examples shipped with osgBullet seem to
> behave correctly on my Mac, what's more, just replacing the code from my main
> with the code of, say, centerofmass.cpp works fine. The only tangible
> difference I can think of right now is the use of osgViewer (osgBullet
> examples) vs. vrj::Osg::App (vrjuggler).

About the only thing osgViewer provides that is critical to Bullet's proper
functioning is the FrameStamp. The elapsed seconds are passed as a parameter to
Bullet's stepSimulation() routine. I'd hate to sound like I'm asking "is it
plugged in?", but you should verify that you're passing in a non-zero elapsed
time parameter.

For the proper rendering of any physics sim, you need a loop that calls
stepSimulation(), then renders. That loop must be executed repeatedly,
otherwise, objects will just hang in the air and never fall. All the
osgViewer-based examples have such a loop. Again in the "is it plugged in?"
vein, you might want to verify that VRJ is executing your loop repeatedly.
Perhaps there is a difference between VRJ on Windows and OSX such that VRJ
renders only the first frame on OSX, then sits idle.

I'll step out on a limb here and state that I doubt your issue is related to
osgBullet. I bet if you wrote a small VRJ-based Bullet app that used OpenGL for
rendering instead of OSG, you'd have the same issue.

> I hope I won't need to dig as deep as setting breakpoints in Bullet to find my
> error =/.

I see the smiley, nonetheless I'm not quite sure how to respond to that. In my
experience, the beauty of open source software is that, when something goes
wrong, I can step through it in the debugger to find out what assumptions the
code is making, and how my use case is breaking those assumptions.

I mean, we can sit hear and speculate about VRJ and make wild guesses all day
(or all week), or you can sit down with a debugger and find out what's going wrong.
-Paul

[Juan Sebastián Casallas]

On Tue, Nov 8, 2011 at 4:05 PM, Paul Martz <pma...@skew-matrix.com> wrote:

On 11/7/2011 4:19 PM, Juan Sebastián Casallas wrote:

I was about to point that out, all the examples shipped with osgBullet seem to behave correctly on my Mac, what's more, just replacing the code from my main with the code of, say, centerofmass.cpp works fine. The only tangible difference I can think of right now is the use of osgViewer (osgBullet examples) vs. vrj::Osg::App (vrjuggler).

About the only thing osgViewer provides that is critical to Bullet's proper functioning is the FrameStamp. The elapsed seconds are passed as a parameter to Bullet's stepSimulation() routine. I'd hate to sound like I'm asking "is it plugged in?", but you should verify that you're passing in a non-zero elapsed time parameter.

I did output the delta_time just before calling stepSimulation() to see if it was working and it did show non-zero values (around 0.3), I got the same results on windows and the same with the osgBullet examples (which work).

  

For the proper rendering of any physics sim, you need a loop that calls stepSimulation(), then renders. That loop must be executed repeatedly, otherwise, objects will just hang in the air and never fall. All the osgViewer-based examples have such a loop. Again in the "is it plugged in?" vein, you might want to verify that VRJ is executing your loop repeatedly. Perhaps there is a difference between VRJ on Windows and OSX such that VRJ renders only the first frame on OSX, then sits idle.

I know that the loop is executed repeatedly, as I said before I output the delta_time just before stepSimulation() and it shows output at every frame.

I'll step out on a limb here and state that I doubt your issue is related to osgBullet. I bet if you wrote a small VRJ-based Bullet app that used OpenGL for rendering instead of OSG, you'd have the same issue.

You're probably right, I finally got my objects falling by adding a separate physics thread (see below), so I should need to do the same thing on an VRJ+OpenGL+bullet app.

I hope I won't need to dig as deep as setting breakpoints in Bullet to find my error =/.

I see the smiley, nonetheless I'm not quite sure how to respond to that. In my experience, the beauty of open source software is that, when something goes wrong, I can step through it in the debugger to find out what assumptions the code is making, and how my use case is breaking those assumptions.

I mean, we can sit hear and speculate about VRJ and make wild guesses all day (or all week), or you can sit down with a debugger and find out what's going wrong.

I agree with you and I do use the debugger a lot (probably more than I should). I had tried adding a breakpoint on stepSimulation, but once on debug I couldn't step into the code (I know there must be something missing on my Xcode project that impedes me to do this, but I'm an Xcode beginner...).

In the end, what the debugger allowed me to do, though, was to realize vrjuggler was already running several threads, which is how I came with the idea of running the physics simulation on a separate thread. I wish I'd know why I don't need to add a separate thread on Windows for physics to work, but right now the thing works (I should try the multithreaded version on windows too, though), I hope I won't run into any concurrency problems later on...

  -Paul

--
You received this message because you are subscribed to the Google Groups "osgbullet-users" group.
To post to this group, send email to osgbullet-users@googlegroups.com.
To unsubscribe from this group, send email to osgbullet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgbullet-users?hl=en.

Thank you very much for your help!

Juan Sebastian

[Paul Martz]

Glad to hear you found a workaround, and I agree it would be nice to know the root cause of the issue.
   -Paul

  -Paul

To post to this group, send email to osgbull...@googlegroups.com.
To unsubscribe from this group, send email to osgbullet-use...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/osgbullet-users?hl=en.

Thank you very much for your help!

Juan Sebastian

--
You received this message because you are subscribed to the Google Groups "osgbullet-users" group.

To post to this group, send email to osgbull...@googlegroups.com.
To unsubscribe from this group, send email to osgbullet-use...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/osgbullet-users?hl=en.