Major contact stability improvement

arno
Posts: 2
Joined: Sun Jul 01, 2012 11:11 am

Re: Major contact stability improvement

Post by arno »

Hello Erwin,

I managed to put the body which had the random move inside the BasicDemo project. I didn't realized before it would be so simple and it's a great way to test it.

I put the diff of BasicTest.cpp here : http://pastebin.com/qQLBh71x
If you prefer another way (the complete file for example) tell me, and I will upload it. I used the last released bullet version available in the download directory (bullet-2.80-rev2531)

You can see the movements if you zoom in the center ("z" key). Pressing "w' may make it more easy with the wire look.
It seems that it finally come to rest after some time, but the collision constraints are not met.

If you decrease the scale of the body by a factor 10 (I mean to divide all COIN_xxx_xxx defines per 10), it appears a lot more. I have currently this smaller scale in my application (I used 1=1meter, max sized body is 3 meters long, and these are a compound of a 2mm thick/12cm diameter cylinder and a 18mm cube). I should probably try to change the scale? If I lower the step-size it improves, but without removing it completely. I also tried some parameters like stabilitymargin and the like, but without success.

I know these bodies are thin, so I tried with doubling the thickness, but it doesn't seem enough (ratio becomes : 4 thickness to 60 radius), and this is probably from where this behavior comes. I hope I did not made some huge beginner mistake when dealing with this.


I hope I am not wrong when I think the modification Laurent describes could be good for this test, otherwise I will probably open another subject for this, to avoid polluting this one with this.

Thanks for your time !
Laurent Coulon
Posts: 29
Joined: Tue Oct 05, 2010 9:36 pm

Re: Major contact stability improvement

Post by Laurent Coulon »

Hi Erwin,
I have posted a patch for the stability improvements described earlier in the thread.
https://code.google.com/p/bullet/issues ... %20Summary
I also provided a new BasicDemo.cpp file that highlights the improvements.

We spent some time making the set of changes as small as possible. We also found out that by removing a couple of additional improvement from our original solution and putting the erp back in, we could get an improvement that also worked in non split impulse scenarios. This seemed well worth it so we are proposing here a slightly simpler version of our work. We did not experiment but we expect the solver to yield completely stable objects even with significantly higher erp values than the default 0.2.

Most of the changes in the patch are very simple and the first post in this thread should explain them. A few notes about the changes though:
* Rigidbody now stores an old Linear velocity. If users ever want to expose their objects to rotational fields (i.e. persistent torque forcefield over time) it would be necessary to add an old angular velocity as well. Since most persistent forces are linear (like gravity) we did not see the use for this.

* We removed the call to btPlaneSpace1 in the friction loop. The call frequently leads to erroneous friction constraint directions and causes major drift (re-enable it in the basic demo to observe the difference). We did not have time to investigate how to fix it for now, but commenting it out seems to yield acceptable results.

* We cleaned up the code in resolveSingleConstraintRowGeneric and similar functions to be cheaper, more compact and most importantly simpler to understand. This is the only part of the patch that is not actually necessary and is more of an optimization/cosmetic change.

Let me know if the patch works for you and if you see any issues with it.
JHoule
Posts: 14
Joined: Tue May 22, 2012 9:30 pm

Re: Major contact stability improvement

Post by JHoule »

It looks quite promising.

It is definitely much more stable, but we are a bit worried about some cases we encountered.

First of all, we were are to stack 3 cubes using our application by pushing each sideways almost completely:
Three cubes
Three cubes
3cubes.png (17.3 KiB) Viewed 6537 times
We would have assumed that each cube would have tipped, yet they were amazingly stable, even while sliding the bottom cube around. It looks suspiciously stable...


Second, we have a ball being pushed around by a character. The ball starts with an identity matrix, and when our character pushes it, it just slides, with no angular velocity being incurred! It just keeps its orientation fixed in space. Dropping it from some heights will give it a normal roll motion, and from then on, our character's push will affect it normally as well. I was thinking about it, and since our character's body is a capsule (perfectly vertical), I suspect it might be "physically accurate": the capsule pushing the sphere will result in an impulse that is perfectly horizontal, which could, in theory, only slide the sphere sitting on a zero-area point of contact. Then again, waiting for it to stop, and pushing it again makes it roll; it seems to happen only with an identity orientation... Mmhhhh...


Laurent, do you think these are expected behaviors?...
Last edited by JHoule on Thu Jul 12, 2012 4:38 pm, edited 1 time in total.
Laurent Coulon
Posts: 29
Joined: Tue Oct 05, 2010 9:36 pm

Re: Major contact stability improvement

Post by Laurent Coulon »

Those are definitely not expected behaviors. We see no such issues in our engine, but then again we still use Bullet 2.76.

The two issues you describe are identical. it looks like you have no rotations allowed on your objects. An infinite inertia tensor would yield this type of behavior. However since you're saying that the ball will roll if dropped from a height and is then rolling properly this suggests that rotations are somehow locked at first and get unlocked when some event occurs (angularFactor or angularDamping not initialized properly??).

I can't think of anything in the patch we just posted that could be remotely related. It looks more like the merge did something wrong and messed up some other line of code.

When we run the Bullet demo with our patch applied to version 2.80 we do not see the behavior you describe.
Laurent Coulon
Posts: 29
Joined: Tue Oct 05, 2010 9:36 pm

Re: Major contact stability improvement

Post by Laurent Coulon »

Playing a bit with the demos in the unpatched 2.80 version shows a bug similar to what you are describing.
If you run the convex decomposition demo, try grabbing one of the tables off-center and lifting it. One out of every two clicks the table will rotate properly as if it was held by a point constraint at your mouse location. The other time, the table will translate but no rotation will be allowed until you release it.
This also happens in the 2.76 version of the demo. It might just be a bug in the demo mouse grab code but either way it shows that it is possible for an object in Bullet to toggle in and out of a state where translations can freely happen but rotations are all blocked.
JHoule
Posts: 14
Joined: Tue May 22, 2012 9:30 pm

Re: Major contact stability improvement

Post by JHoule »

We've tried to isolate the cause of this...

In your patched btDiscreteDynamicsWorld.cpp, you stopped calling (circa line 506):

Code: Select all

integrateTransforms(timeStep);
and seem to have compensated with (circa line 981):

Code: Select all

body->setWorldTransform(body->getInterpolationWorldTransform());
We have isolated in our code that it is the missing integrateTransforms() that prevents the ball from rolling properly. But it also seems to be an important part of your secret sauce...

We're currently trying to modify BasicDemo.cpp to reproduce the issue outside of our framework. Will post again later...
Laurent Coulon
Posts: 29
Joined: Tue Oct 05, 2010 9:36 pm

Re: Major contact stability improvement

Post by Laurent Coulon »

Hi,
Not calling integrate transforms after the solve is intentional. Objects are moved in predictUnconstraintMotion and if you are doing split impulse, they are moved again in internalWritebackVelocity. The patch does currently break CCD but if you are using CCD nothing the patch attempts to fix should have been an issue in the first place.

Our patch did fail to update the inertia tensor after moving the object though. Here is a new patch for you to try. If this fixes your problem I will post it on Google code. Rename the .txt to .diff

If it does fix your problem however this means you have a bug in the initialization of your rigid body inertia tensor. The behavior you are describing suggests you start with a zero inverse tensor.
Attachments
patch2.txt
(19.99 KiB) Downloaded 245 times
JHoule
Posts: 14
Joined: Tue May 22, 2012 9:30 pm

Re: Major contact stability improvement

Post by JHoule »

Much better!

I'd say with your second patch, it does indeed work.

Now, you say we might have a bug in our initialization, and that might be true, because we had to jump throw hoops since we create rigid bodies without collision shapes, and add the shape afterwards. Looking back at our code, we couldn't find the culprit, but we are aware of another bug where a collision shape is sometimes ignored (haven't isolated that one yet, but it does indicate we do have a bug somewhere). What we can say is that we recompute the inertia tensor when we do assign the collision shape to the body, and if that code didn't work properly, our sphere wouldn't be rolling like it is now. ;-)

OK, so back to your patch.

It does get rid of contact stability issues of boxes on the floor, but it sounds like stacking is now a little less stable (a wall of boxes take less time to fall when we have no deactivation). Also, it sounds like stacked boxes now shake a little more; it's subtle, but once in a while, you'll see a box pop up slightly more than the previous code ever did. It's as if some energy would pile up, reach a threshold value, kill the contact and transform into a collision, then fall again and get back to contact the next frame. Just a theory for now, though.

Also, our rolling ball now has a peculiar behavior... When it has a slow speed, it will sometimes hit something, deflect, roll away, but then magically come back to the recently hit object. This behavior is worst than being simply sticky: the ball actually backtracks to apparently re-enable a contact that, I think, should have disappeared. Similarly, when the ball rolls near a static obstacle, it will sometimes get pulled and change its trajectory before actually hitting the obstacle. I wonder if it could be related to the removed m_restingContactRestitutionThreshold variable that was removed.
Laurent Coulon
Posts: 29
Joined: Tue Oct 05, 2010 9:36 pm

Re: Major contact stability improvement

Post by Laurent Coulon »

Glad to hear this fixes your problem, I will post the new patch.

As far as stacking stability is concerned, as I explained in my recent post what we posted in the patch is a simplified version of our solution that also works with non split impulse. Our full solution was tested at length and lead to vastly improved stacking but we did not include the full changes in the patch (you can take a look at the early post in this thread where I posted our complete version of setupContactConstraint() if you are interested).

Another thing is that we exclusively use split impulse in our engine so the non split impulse version might have an effect on stacking that we have not observed (seems weird considering how the boxes bounce much more accurately on top of each other in the basic demo but you never know).

As far as your sphere popping back or being diverted towards objects I honestly have no idea what the issue could be. I have now tested our patch on all the Bullet demos and saw no such issue. Let me know if you find a repro case.
Flix
Posts: 456
Joined: Tue Dec 25, 2007 1:06 pm

Re: Major contact stability improvement

Post by Flix »

Just to say that I tried the modifications yesterday (together with the modified BasicDemo) and it seems to work better expecially for tiny objects (that used to "shake" up and down in plain Bullet).

I haven't tried to use small objects with constraints and I haven't made many tests yet, but I really hope that this patch will allow a wider range (in dimensions) of objects to be used inside Bullet.

Thank you for posting it !
VicariousEnt
Posts: 50
Joined: Fri Oct 29, 2010 1:37 am

Re: Major contact stability improvement

Post by VicariousEnt »

So some changes have been checked into the main trunk...
http://code.google.com/p/bullet/issues/detail?id=642#c8

I'm curious to see how this improves things and how it compares to the version of Bullet Mr Coulon's company runs. Maintaining the CCD system (which has also been improved now!) is pretty important for most games so I can see why we couldn't take the whole thing. In our own project, the biggest problem with jitters come to light when ragdolls push the limits of their constraints or hang overtop of static geometry. I'm not too sure how much these changes will help with that but I'm looking forward to trying 2.81 when it arrives!
User avatar
Erwin Coumans
Site Admin
Posts: 4232
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Major contact stability improvement

Post by Erwin Coumans »

VicariousEnt wrote: I'm curious to see how this improves things and how it compares to the version of Bullet Mr Coulon's company runs. Maintaining the CCD system (which has also been improved now!) is pretty important for most games so I can see why we couldn't take the whole thing. In our own project, the biggest problem with jitters come to light when ragdolls push the limits of their constraints or hang overtop of static geometry. I'm not too sure how much these changes will help with that but I'm looking forward to trying 2.81 when it arrives!
For a ragdoll you might want to cheat a little, to make the simulation more stable, less jittery:

+ increase the inertia for the limbs (multiply the result of localInertia with a factor)
+ add angular damping to the limbs

Also I'm considering to add rolling friction constraint to contacts, that will reduce jitter too.
User avatar
majestik666
Posts: 66
Joined: Tue Mar 02, 2010 6:13 am

Re: Major contact stability improvement

Post by majestik666 »

Is there a way to actually fake the rotation friction on contacts ?
We do get lots of spinning when using a high friction (probably normal
since all the energy is converted in rotation), would be nice
to be able to reduce that effect a bit.

Francois
User avatar
Erwin Coumans
Site Admin
Posts: 4232
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Major contact stability improvement

Post by Erwin Coumans »

majestik666 wrote:Is there a way to actually fake the rotation friction on contacts ?
Francois
Yes, I implemented and added a first version of rolling friction to Bullet trunk:
http://code.google.com/p/bullet/source/detail?r=2584

See https://www.youtube.com/watch?v=RV7sBAsKu4M

I need to add some more control to avoid undesirable artifacts, in particular objects resting in an unnatural/unbalanced pose.
You can control the rolling friction per objects, it gets combined by multiplication similar to friction. You can override the combined rolling friction in a contact callback (similar to friction/restitution).
User avatar
majestik666
Posts: 66
Joined: Tue Mar 02, 2010 6:13 am

Re: Major contact stability improvement

Post by majestik666 »

Thanks for implementing that !
I'll update our code base and see how it behaves.

Is it something that will stay in there or is it just
some kind of experiment ?
Post Reply