Rigid body Physics status

#1 "...unusable out of the box."

It depends on your application. The out of the box physics are great for a large number of game styles. 1.5 behaviors makes it really really easy to code your own physics in torque script.

I might suggest doing what a lot of community members do. Try to solve the problem themselves, then tell everyone about it.

My 2c

#2 Hi again,

I haven't try TGB1.5.1 since August, was waiting the next 1.5.2 ehhh 1.6.0 (well the next one gonna be 1.8 then 1.9.8 and after you will have to pay for the next version i guess ^^).

Do you know any new things about rigid body Physics ?

#3 Well, I've been playing with the physics system and I've been able to get a rigid body with circular collision to work decently. My question is has anyone created a box that once given a force, will actually settle down again? The past few nights I've been attempting that and all my boxes keep jittering and jumping like a Jack Russel Terrier begging for attention. I"ll post video tomorrow once I solve some computer issues.

#4 Ok, a bit delayed but I took a video where I have a box, the box's properties are shown on screen and I begin adjusting them as they move around. I've checked all settings and have tried almost everything I can think of in order to get this box to just settle down.

In the video the tire is controlled by me. That's just a rigid body with CIRCLE collisiondetectionmode. It works pretty well, but the box is the object in question. I move into it to get it moving, and then everything happens from there.
ca.youtube.com/watch?v=Erby6Nven78

I also display the angular velocity. As you can see, it goes crazy for the box. I'm looking in the source right now but figuring out what's going on may take a while. Anyone out there wanna help?

#5 Your link is timing out on me. I'll try again later.

For an acrobatics focused platform jumper that I'm doing -- I simply turn off gravity on the player when he is on the ground. I also had to tweak the collision poly to be trapezoidal -- a rectangular collision poly allowed him to scale walls in illegal ways.

If you do turn off the gravity, you will probably have to implement some kind of friction script into the object's behavior/code.

Just thinking off the top of my head!

Kevin

#6 Well I started last night a bit and tonight I really read up on my physics, angular velocity, angular acceleration, angular momentum, torque, etc. It's taking a little bit to sink in, I think I just need time to re-read the material. I referenced some stuff they have links to in the source code. My best educated guess right now is that something screwy in the Impulse calculation is going horribly wrong and screwing everything up but I'm not sure. The reference materials I have provide a different equation from the one used in the source and I honestly can't decipher yet what exactly they're calculating. From observation I know that a box will stop moving even though it's angular velocity goes higher and higher till the box just jumps up into the air. When the box is just about to lay flat, one corner on the ground and the edge coming down, right when it hits the ground it generates a huge impulse send the box flying again. (reference the video I posted above)

Anyone know anything else? Anyone from GG reading this? This really is kinda stopping me from assembling my prototype at this point. I could do my own collision responses but I'd rather do them in C++. If I can't get this working by this weekend I'm going to study more and possibly rewrite the collision handler if I can.

#7 I recommend you echo the %normal in your onCollision callbacks. I tried doing this and found that occasionally the %normal was completely wrong, unless I used circle collision detection for the object receiving the callback.

#8 The problem isn't as simple as the normals. It seems that when a rigid body is making contact with another rigid body the impulse is constantly being calculated resulting in the angular velocity accumulating rapidly. In addition there doesn't seem to be any clamping that will allow the body to rest when the amount of momentum is low. So, the constant angular acceleration results in a spike in momentum when the object finally rotates and makes contact with another Rigid body again. That's why in my first video you see the box rotate slowly and then jump back up into the air. I've implemented "Newton's Law of Restitution for Instantaneous Collisions with No Friction" a couple nights ago and I'm currently researching adding friction to the simulation and clamping. You can see my progress here:

www.youtube.com/watch?v=d1PsLW8V03w

It's not the complete solution but I'm working towards that. I've learned a great deal.

#9 Very cool.

#10 Alright, time to bump this thread. I've spent quite a lot of time with all of this and I'm going to report my progress so far. I wrote my own collision response (as stated above) and just introduced friction. After all the debugging and learning to do everything correctly I ended up with a simulation that "looked right" but it was exhibiting the same problems that TGB has, the box will get stuck moving really slowly and the pop up into the air. Eventually I got so frustrated that I wrote a system to render force vectors (something I should have done a long time ago) and keep a history and render them.

Well I'm excited because shortly after all that I found the problem that was causing the funky box behavior. I made a temporary fix and this is what I have now:

www.youtube.com/watch?v=zFul8CQvilA

There's a lot of work to do still. Now that I have the simulation stable I need to implement the collision for both bodies involved, figure out why high coefficients of friction generate energy, implement static friction, putting objects to rest and do some tuning.

NOTE: The box jumping into the air isn't a bug, it's me pressing a key to give the box a random elevation, linear and angular velocity.

#11 DEBUG RENDERING FTW!

Nice bouncing box music video '-)

#12 Just a quick update. Fixed Rigid Body on Rigid Body collisions. Still a couple hiccups now and then but that's to be expected. I'm going to solve the jittering and settling next.

www.youtube.com/watch?v=GvpdRnFoTs8

#13 Very nice work Wenceslao. Do you plan on releasing this as a resource?

#14 Hi,

Recently I've been engaged in resolving some tick-physics issues that were reported. During the completion of that work I came across some funky issues that seem to have cropped up in the collision system. Mostly you won't see this unless you use it as a basis for the rigid-body physics (especially with constant forces applied) as that's probably the most complex/sensitive of the collision responses.

After I completed the work I set about fixing some of the issues I found but before I go into that let me clarify some of the history here.

Originally when I created collision/physics system, a decision was made to not create an expensive iterative solver of forces. Not doing that had the benefit that we could create useful physics that was fast. Not doing it had the effect that overlaps are not solved in the best way possible.

The thing is that this isn't a problem for a majority of game cases unless you are doing some kind of completely open physics-based game, especially when you allow stacking with arbitrary mass objects. This kind of setup *mandates* an iterative solver else problems like objects jittering and overlaps can explode into chaotic behaviour unless you take explicit measures to counter them: the system won't do it for you.

With that said, the existing system should provide a fast and fairly useful rigid-body setup and it has been like that for a long time. What appears to have happened though is that the collision system has had changes which caused the rigid-body to become useless. I'm not sure when this happened or if indeed it has happened gradually as some of the problems I've found are in completely seperate areas.

So, with all that said, it's broken and needs fixing. :)

What I did recently was to create a test-case which would produce several of the bad effects mentioned above, these being: non-trivial interpenetration, velocities exploding and objects getting stuck or slowed down due to trivial interpenetration.

This lead to the following video which highlights how bad it's got: www.youtube.com/watch?v=sCW6ajnFJRM. Pretty bad.

I then sat down and instrumented the engine to hell so that I could trace what was going on. I identified several obvious errors, some of which were related to the usage of the utility comparison functions like "mIsZero". Now whilst these are very useful to remove common-place checks, some of them have tolerances for inprecise floating-point issues. These tolerances are not obvious and when used on key aspects of the engine they can cause problems such as allowing negative values through as zero which is a nice tolerant "is zero" check but bad if negative *means* something!

Now there are several ways of stopping the issue of rigid-bodies having velocity exploding but only one of them address the root cause which is a related to the handling of overlaps, partial collision integrations (small move then collision) and finally near-zero-time collision handling.

Certainly one thing that's evident is that you'll only really see this when you apply a constant force to an object. Doing this can cause an object to be constantly forced against an object and only two things stop it from interpenetrating these being the collision-response and the overlap solver. It's the former that becomes interesting as in the case of rigid-body physics it calculates an impulse function to keep the object from interpenetrating. Now normally this would be enough but it's here where T2D is trying to be too smart for its own good. If you're doing this against another rigid-body then you'll be fine as the forces will seperate the objects but if one is not rigid-body and indeed is immovable then the forces won't necessarily be ideal leading to trivial interpenetrations.

Oh and the problems multiply. I could go on forever about how setting up rigid-body simulations no matter how good the solver can fail if the associated masses/forces involved are disproportionate. Having an elephant sitting on an egg setup as a rigid-body won't work and you'll get interpenetration. In the real world the egg would break because of this imbalance but this is rigid-body and the objects don't break! The moral is that you'll get good results if you keep the relative mass/density/forces of the objects involved in check.

... but, ignoring that and as demonstrated above that even before you start creating problems like that, the current setup is broken.

So, several coffees laters we've got a fixed simulation that tries to handle more gracefully the overlap issue, uses a better collision-margin check, handles the special near-zero-time collision case, deals with linear velocity accumulation when constant forces are being applied etc.

This leads to: www.youtube.com/watch?v=dS4dCEgQq0I

Now as hard as I have worked on this, it doesn't mean that that I've not missed an edge-case and so if anyone here has any simple script setup that demonstrates the problem then I'd be happy to give it a test against my recent changes.

@Wenceslao: I'd be interested in knowing if you address your issues by playing with the collision response or if you looked at the collision overlap issues.

Melv.

#15 Melv,
Does your video include objects with the "CIRCLE" collision detection type? Although not specific to rigid body physics, I've noticed that in 1.7.3, the objects with "CIRCLE" collision have interpenetration problems. The interpenetration is especially bad when using constant forces.

#16 Yes, I found an issue with both the basis poly/circle collision functions both of which are related to the utility functions mentioned above. I introduced a near-zero-time/space collision margin into the calculations for both so that the special handling of near-zero-time collisions can be handled higher-up the call hierarchy. In this case a clamp of the velocity along the normal is taken and the collision reprocessed.

This stops objects fighting in/out of overlap as well as forces accumulating when a constant force is applied, no matter how big the force or its source.

Melv.

#17 ... and to show this I just went into the script and changed the collision mode to circle: www.youtube.com/watch?v=_aG1vKQcp4Q

These objects have random size, friction and velocities.

Melv.

#18 Hey Melv, its great to see this fixed! any idea when we might see it in TGB? and is there any plans to expand the physics to include stuff like joins and soft body dynamics etc? with the increasing interest in physics in games it could be a really good move for TGB.

as always, Keep up the good work.

Neil.

#19 Well hopefully it's fixed for most cases but I'll just ask again that if anyone has any simple script-setup that fails then please send it to me and I'll test it against my changes. I'd love to get as many fixes for physics done in one go.

Unfortunately I can't say when the next release of TGB will be, that's for GG to say.

I personally don't have any plans to extend the physics to include joins and soft body dynamics but I agree with you that there is certainly interest in physics-based games.

If a community member wanted to do that then I'm sure they could make money from doing so!

Thanks for your support.

Melv.

#20

Quote:If a community member wanted to do that then I'm sure they could make money from doing so!

Indeed! But no, personally, I have no plans of doing anything like that . . . mostly because I'm lost when it comes to C++

Thanks for these spectacular physics changes, Melv! Seeing the before and after videos makes it obvious why you are the code ninja that you are.

Kudos and thank-you!