Placing a dynamic rigid body ontop of an animated body

[tomhog]

Hi

I've been using osgBullet for a project for a few days now. So far
everything is going well, i have the scene at a good scale for my
purpose (cm) and have successfully built staks of cylinders etc and
thrown spheres at them to knock them over.

I'm now trying to place some cylinders onto a moving platform. I'm
using the some code from one of the examples to create the animated
bodu and mesh

/* BEGIN: Create animated box */
/* OSG Code */
float armLength = 2.0f*unitScale;
osg::Vec3 platformHalfSize = osg::Vec3(0.75f*unitScale,
0.025f*unitScale,0.25f*unitScale);
osg::Vec3 platformOffset = osg::Vec3(0,0-platformHalfSize.y(),-
armLength);


osg::MatrixTransform * box =
osgBulletUtils::createOSGBox(platformHalfSize);
osg::AnimationPathCallback* apc = new
osg::AnimationPathCallback( createAnimationPath( worldOffset
+platformOffset, armLength, 240 ), 0, 1 );
box->setUpdateCallback( apc );
_root->addChild( box );

/* Bullet Code */
btRigidBody * boxBody = osgBulletUtils::createStaticBTBox( box,
osg::Vec3( 0, 0, 0 ) );
boxBody->setCollisionFlags( boxBody->getCollisionFlags() |
btCollisionObject::CF_KINEMATIC_OBJECT );
boxBody->setActivationState( DISABLE_DEACTIVATION );
_dynamicsWorld->addRigidBody( boxBody );

/* osgbBullet Code */
osgbBullet::RefRigidBody * boxRigid = new
osgbBullet::RefRigidBody();
boxRigid->setRigidBody( boxBody );
box->setUserData( boxRigid );

osgbBullet::RigidBodyAnimation * rba = new
osgbBullet::RigidBodyAnimation;
apc->setNestedCallback( rba );
/* END: Create animated box */

However although the cylinders do interact with the collison shape
etc, they seem to be having a strange extra force applied. The
platform move around in a circle. in my view as it move to the left
all the cylinder slide to the left as if not being draged but being
pushed.

Does anyone know if i might have missed something?

Cheers
Tom

PS
The create StaticBTBox for reference,

btRigidBody* osgBulletUtils::createStaticBTBox(osg::MatrixTransform*
box, osg::Vec3 center)
{
btCollisionShape * collision =
osgbBullet::btBoxCollisionShapeFromOSG( box );

osgbBullet::MotionState * motion = new osgbBullet::MotionState();
motion->setTransform( box );
motion->setParentTransform( osg::Matrix::translate( center ) );

btScalar mass( 0.0 );
btVector3 inertia( 0, 0, 0 );
btRigidBody::btRigidBodyConstructionInfo rb( mass, motion,
collision, inertia );
rb.m_linearSleepingThreshold = rb.m_linearSleepingThreshold *
osgBulletUtils::getScaleFactor();
btRigidBody * body = new btRigidBody( rb );

return( body );
}

Which has just made me think, do i need to actually make it dynamic
and give it mass?

[Paul Martz]

The code you quoted is just moving a box from an OSG animation path, and will
push dynamic objects around, but dynamic objects won't push it around, so it's
kinematic. Whether you want this same effect or not is up to you and your
application.

As for the issue with how the cylinders are moving, it almost sounds like they
are not transformed correctly, as if the transform for the moving box is somehow
affecting their position. If you are using AbsoluteModelTransform for the
cylinders, this should not be the case, their motion (except for physics) should
be independent of other transforms. So, even if they are "under" the box
transform, their motion won't be affected by it. Indeed, this is the problem
AbsoluteModelTransform was intended to solve: to allow Bullet to have complete
control over the model portion of the modelview matrix, regardless of OSG hierarchy.

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

[tomhog]

Hi Paul

Thanks for the reply,

> The code you quoted is just moving a box from an OSG animation path, and will
> push dynamic objects around, but dynamic objects won't push it around, so it's
> kinematic. Whether you want this same effect or not is up to you and your
> application.

Yes this is all I want to do, I basically want to stack cylinder/cans
on a moving platform to make them harder to shoot

> As for the issue with how the cylinders are moving, it almost sounds like they
> are not transformed correctly, as if the transform for the moving box is somehow
> affecting their position.

This sounded like a good place to start, but so far no luck. The scene
hierarchy is pretty simple and both the moving box and the cylinder
are attached to the root osg node.

I've also tried slowing the animation of the shelf down and adding a
pause at the sart. During the pause before the shelf begins to move
the can sits still on the shelf. As soon as the animation begins to
move the shelf though (really slow) the can begins to move in the same
direction but at least 4 times the speed.

I thought it could be caused by my scaling of the world units by 100
to cm, e.g. i've scaled gravity etc. So I set the world scale
(unitScale) to 1.0 but the added movement still happens.

Here is a link to zip of the main files need for my app, it's for
IPhone but the only thing that needs looking at in
MatchOsgViewController.m is the initBulletWorld and updateScene
functions. Everything else bullet related is in the BulletUtils.h and
cpp.

www.hogbox.co.uk/data/BulletTest.zip

If you could take a look I'd be very grateful, I think i'm missing
something obvious as so far everything has worked great.

Cheers
Tom

[Paul Martz]

On 6/30/2011 2:57 PM, tomhog wrote:
> Hi Paul
>
> Thanks for the reply,
>
>> The code you quoted is just moving a box from an OSG animation path, and will
>> push dynamic objects around, but dynamic objects won't push it around, so it's
>> kinematic. Whether you want this same effect or not is up to you and your
>> application.
>
> Yes this is all I want to do, I basically want to stack cylinder/cans
> on a moving platform to make them harder to shoot

Then there should be no need to make the moving box dynamic, and I expect such a
change would have no effect on your issue.

>> As for the issue with how the cylinders are moving, it almost sounds like they
>> are not transformed correctly, as if the transform for the moving box is somehow
>> affecting their position.
>
> This sounded like a good place to start, but so far no luck. The scene
> hierarchy is pretty simple and both the moving box and the cylinder
> are attached to the root osg node.
>
> I've also tried slowing the animation of the shelf down and adding a
> pause at the sart. During the pause before the shelf begins to move
> the can sits still on the shelf. As soon as the animation begins to
> move the shelf though (really slow) the can begins to move in the same
> direction but at least 4 times the speed.
>
> I thought it could be caused by my scaling of the world units by 100
> to cm, e.g. i've scaled gravity etc. So I set the world scale
> (unitScale) to 1.0 but the added movement still happens.
>
> Here is a link to zip of the main files need for my app, it's for
> IPhone but the only thing that needs looking at in
> MatchOsgViewController.m is the initBulletWorld and updateScene
> functions. Everything else bullet related is in the BulletUtils.h and
> cpp.
>
> www.hogbox.co.uk/data/BulletTest.zip
>
> If you could take a look I'd be very grateful, I think i'm missing
> something obvious as so far everything has worked great.

I wasn't really able to divine anything from your code.

Have you compared your code to the dice example? The initial click and mouse
motion jolts the dice towards the viewer, but subsequent motion just moves the
box around, and if I move it nice and slowly, the dice move right along with the
box. I don't see any of the issues you are describing.

You might also consider wiring in the GLDebugDrawer, which will help determine
if the Bullet collision shapes are not synched to the OSG visual representation.

Finally, you're posting this to the osgBullet group. Can I assume you tried your
app with Bullet and it's demo library that renders using OpenGL, and that you
didn't experience this issue in that testbed? In other words, why do we think
this in an osgBullet-specific issue, and not an issue with how the Bullet
physics simulation is set up / functioning?
-Paul

[tomhog]

Hi Paul

The dice example sounds ideal for comparison, I hadn't run it yet as
I'm on IOS and only have the libs built for everything. I'll try get a
desktop build running in parallel.

>In other words, why do we think
>this in an osgBullet-specific issue, and not an issue with how the Bullet
>physics simulation is set up / functioning?

Now I've stepped through a lot of what osgBullet is doing I think you
may be right and this is an entirely bullet related problem.

I'll take a look through the dice example and let you know my results.

Thanks again for the help
Tom

[tomhog]

Hi Again Paul

I've investigated this a little more and have sort of found the cause,
just not a solution yet. i've setup a post on the bullet forum to see
if they can help

http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=6998&p=24073#p24073

Basically it seems that if I have sub intervals in my step simulation
the friction from the moving platform seems to get applied once for
each iteration. So this works

_dynamicsWorld->stepSimulation(stepTime);

But this doesn't

_dynamicsWorld->stepSimulation(stepTime, 4, 1.0f/240.0f);

The problem witht he first is i have a fast moving bullet in the scene
so get a lot of tunneling with one iteration.

I did try seeing if it was caused by only updating the motionstate
once during the osg update by implementing my own dynamics world and
overriding internalSingleStepSimulation. I then advanced and updated
osg once per iteration


void BulletOsgWorld::internalSingleStepSimulation( btScalar timeStep)
{
_simTime += timeStep;

// then do your per-step code here, the timestep is the proper
1/60 one
p_viewer->advance(_simTime);
p_viewer->updateTraversal();

btDiscreteDynamicsWorld::internalSingleStepSimulation(timeStep);
}

But it still seems to happen.

Weird ay
Tom

[Doug McCorkle]

On Jul 4, 2011, at 12:42 PM, tomhog wrote:

> Hi Again Paul
>
> I've investigated this a little more and have sort of found the cause,
> just not a solution yet. i've setup a post on the bullet forum to see
> if they can help
>
> http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=6998&p=24073#p24073
>
> Basically it seems that if I have sub intervals in my step simulation
> the friction from the moving platform seems to get applied once for
> each iteration. So this works
>
> _dynamicsWorld->stepSimulation(stepTime);
>
> But this doesn't
>
> _dynamicsWorld->stepSimulation(stepTime, 4, 1.0f/240.0f);

When you implement a sub interval time period the coupling between the framerate and the simulation step is critical. We have messed with the sub interval settings and it can have a drastic impact on the final visual outcome. For your setup with high speed objects I am not sure what to suggest but I know that it is tricky to get the two real-time toolkits to work together well.

Doug

[Paul Martz]

On 7/4/2011 11:42 AM, tomhog wrote:
> Hi Again Paul
>
> I've investigated this a little more and have sort of found the cause,
> just not a solution yet. i've setup a post on the bullet forum to see
> if they can help
>
> http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=6998&p=24073#p24073

I don't see any helpful replies there, sadly.

But while reading through that post, I did want to clarify. In your post you
said that you "used a motionstate to manually move the box".

Be aware that you have two representations of your object: a physics
representation (collision shape and rigid body) and a visual representation (OSG
geometry). MotionState's job is to keep the visual representation in sync with
the physics representation. Bullet is what is moving things around, not
MotionState. MotionState just translates the Bullet transform to the OSG transform.

My understanding of MotionState is that it is entirely optional. You can use
Bullet to do a dynamic rigid body physics simulation without any visual display
at all, purely for computational purposes. You would move kinematic objects with
calls directly into the Bullet API in this case. MotionState is really only
there as a convenience to update the visual representation.

More below...

> Basically it seems that if I have sub intervals in my step simulation
> the friction from the moving platform seems to get applied once for
> each iteration. So this works
>
> _dynamicsWorld->stepSimulation(stepTime);
>
> But this doesn't
>
> _dynamicsWorld->stepSimulation(stepTime, 4, 1.0f/240.0f);
>
> The problem witht he first is i have a fast moving bullet in the scene
> so get a lot of tunneling with one iteration.
>
> I did try seeing if it was caused by only updating the motionstate
> once during the osg update by implementing my own dynamics world and
> overriding internalSingleStepSimulation. I then advanced and updated
> osg once per iteration
>
>
> void BulletOsgWorld::internalSingleStepSimulation( btScalar timeStep)
> {
> _simTime += timeStep;
>
> // then do your per-step code here, the timestep is the proper
> 1/60 one
> p_viewer->advance(_simTime);
> p_viewer->updateTraversal();
>
> btDiscreteDynamicsWorld::internalSingleStepSimulation(timeStep);
> }
>
> But it still seems to happen.

Hm. Well, I think you're on the right track here. Your original post contained
code that suggested you were moving the box with an AnimationPath. You might
want to poll the AnimationPath once every substep to get the current position.
Add a printf or osg::notify call to display the xyz translation values for each
substep so you can verify that you're getting *different* values at each substep.

Another possible problem might be that you are updating the position with a call
to MotionState->setWorldTransform. Instead, try calling setWorldTransform on the
rigid body (once every substep, of course, with a transform that you sample from
the AnimationPath).

I'm not sure any of this will work, I'm just throwing out ideas for things I'd
try if I were running into the same issues.

[tomhog]

Hi Again Guys

So I went through a few passes testing and probing and eventually,
while trying the demo someone gave me on the bullet forum, have
discovered the issue to by bullet 2.75 itself.

So I know have a new problem, I have built bullet 2.78 and rebuilt the
osgBullet trunk against it. However now in my demo, nothing moves
anymore as if link between bullet and osg has gone.

Has anybody had luck using bullet 2.78 and osgBullet. Also in the
compatibility matrix on the osgBullet site it says 2.76 should work
but some features will be missing, what features are these?

Cheers
Tom

[tomhog]

Update on this,

I built using 2.76 which doesn't have the original problem and also
seems to work with bullet. Think my problem is solved.

Thanks guys
Tom

PS
Would still be interesting to know why 2.78 didn't even move

[Paul Martz]

On 7/20/2011 5:53 AM, tomhog wrote:
> Hi Again Guys
>
> So I went through a few passes testing and probing and eventually,
> while trying the demo someone gave me on the bullet forum, have
> discovered the issue to by bullet 2.75 itself.
>
> So I know have a new problem, I have built bullet 2.78 and rebuilt the
> osgBullet trunk against it. However now in my demo, nothing moves
> anymore as if link between bullet and osg has gone.

Hm. I don't see a bullet-2.78 tag. 2.77 appears to be the most recent tag. Do
you mean you're working with Bullet's trunk? If so, expect some instability.
(Personally, I've done zero testing of osgBullet with Bullet trunk, having ran
into frequent breakages in the past and having been warned by at least one
Bullet developer that I should just stick to the stable releases.)

> Has anybody had luck using bullet 2.78 and osgBullet. Also in the
> compatibility matrix on the osgBullet site it says 2.76 should work
> but some features will be missing, what features are these?

I believe I added that note because 2.76 removed the Collada functionality that
osgBullet v1.1 used extensively. In the next stable release of osgBullet (maybe
later this year), all references to the old ColladaConverter class, and features
that use it, will be removed. osgBullet trunk is already well on its way in this
direction.
-Paul

[Paul Martz]

On 7/20/2011 7:03 AM, tomhog wrote:
>
> Update on this,
>
> I built using 2.76 which doesn't have the original problem and also
> seems to work with bullet. Think my problem is solved.

2.77 should also work, that's the release that I use almost 100% of the time.

> Would still be interesting to know why 2.78 didn't even move

Yeah. Do all of the osgBullet examples also fail on that version of Bullet?

Sadly, I have seen Bullet minor version number releases break things in the
past: 2.75 changed the way you dynamically update the transforms of a
btCompoundShape, for example. You'd think such changes would merit a major
version number increment. With this kind of track record, it will be difficult
to tell whether the issue you encountered was an intentional API change or just
a bug that has been introduced since 2.77.

[Doug McCorkle]

On Jul 20, 2011, at 12:21 PM, Paul Martz wrote:

> On 7/20/2011 7:03 AM, tomhog wrote:
>>
>> Update on this,
>>
>> I built using 2.76 which doesn't have the original problem and also
>> seems to work with bullet. Think my problem is solved.
>
> 2.77 should also work, that's the release that I use almost 100% of the time.

2.77 works VERY well for us too.

>
>> Would still be interesting to know why 2.78 didn't even move
>
> Yeah. Do all of the osgBullet examples also fail on that version of Bullet?
>
> Sadly, I have seen Bullet minor version number releases break things in the past: 2.75 changed the way you dynamically update the transforms of a btCompoundShape, for example. You'd think such changes would merit a major version number increment. With this kind of track record, it will be difficult to tell whether the issue you encountered was an intentional API change or just a bug that has been introduced since 2.77.

I second what Paul said above. I would stay on stable releases of Bullet.

Doug

[Paul Martz]

Well, it looks like 2.78 *is* released -- as a source zip only. There doesn't
appear to be a tag in their svn repo. (Not sure why that didn't happen. I opened
an issue regarding it.)

At some point in the future, I'll do some testing with this "release" and, if
everything looks good, update the compatibility matrix.
-Paul