Rigid body Physics status

#21 I found my solution in the collision response.

Melv, to start off I was new to the whole rigid body dynamics thing so the first thing I set out to do was to learn how to do all the math and understand it. Just looking at the code left me lost at first. I used Chris Hecker's articles about rigid body simulations to get started: (chrishecker.com/Homepage) After several, mistakes and hours of learning I got all that working. After a little while using resources like (www.physicsforums.com/showthread.php?t=186335) I added friction to the simulation. At this point I noticed that my solution was having the same stalling problems that TGB's solution was. So at that point I was able to logically deduce that velocity was accumulating due to multiple collisions. I couldn't tell if it was because the impulse calculation wasn't enough to push the objects apart, the constant force was overcoming the impulse or if the bodies were inter-penetrating. When I began reading Erin Catto's solution for reducing jittering using sequential impulses (www.gphysics.com/files/GDC2006_ErinCatto.zip I thought about how I might be able to stop the stalling. My temporary solution to the problem was, when calculating the impulse, if the impulse wasn't enough to separate the two bodies (i.e. the linear velocity was still pushing the movable body into the immovable body) zero out the velocity parallel to the constant force (so in case of gravity, just make LinearVelocityY = 0). I suspected that the real problem might be in the collision but this whole system was new to me and my only choice was to trust the collision system to actually separate the bodies. My plan from there was to solve the jittering problem and make it so that the constant force 'ceased' when a body came to 'rest' and then re-apply the constant force once the object received another collision that would move it. I wasn't sure if it was all going to work but that's learning huh? At this point I can say I was getting worn out in this drawn out war and had half a mind to either integrate another physics engine or just call it a day and move on. Any feed back from you on my approach would be very educational.

I've spent a lot of time on this and I'm quite happy with how much I've learned but I wouldn't mind finishing this off soon so I can go back to making a game. It was the sort of thing where I wanted a game with some physics involved but I stopped short of starting the prototype because I saw how broken rigid bodies were. I posted a few times but got no response, so I took it on myself to fix it. Unfortunately I've only been able to work on it in my spare time which has been very sparse.

Thanks for the update. Your video showing the issues is pretty much the same problems I was having. I'm actually quite jealous of your knowledge of the engine and how quickly you were able to identify and rectify the problems and how much time I spent and only getting a partial solution. I feel like I spent a lot of time barking up the wrong tree (I guess I was right next to the right tree though) I'd be interested to see exactly what you fixed and why it was a problem in code. At this point I want it to be over but I'm such a Bulldog when it comes to problems that I want to know how to fix them even though someone else already did it.

Also, yea, I'm very interested in having this fixed so I can get back to my prototype.

#22 Wenceslao,

I do admire your approach: it doesn't work so I'll roll my sleeves up and fix it, that's a good attitude. :)

I've still got some testing to do on this before I'll official stamp it as final but I'm pretty confident that it's working for the majority of cases.

It's interesting that you mention removing the linear velocity along the collision normal and I did exactly that. The trouble is that whilst this works perfectly for rigid-body, for other detection modes it's disasterous. For instance doing this when using the "bounce" mode would stop it bouncing correctly. That meant a special case for rigid-body which wasn't what I was looking for.

The biggest problem was that there were a few fuzzy checks both in the container-search functions as well as in the actual circle/poly sweeps. I modified those to condense down a margin around zero-collision-time to effectively give a small gap between collisions (1/10,000th world-unit). Anything within this region is always reported as a zero-time-collision. This then gives you a benefit that you don't end up oscillating in/out of overlap due to linear velocities. The downside is that I've chosen an arbitrary value but it's such a small percentage of a world-unit that unless you were using a screen viewing around 1/100th unit across you wouldn't see it.

One thing that has always been a problem is dealing with overlaps. With the changes I made you do not get overlaps resulting from movement by linear velocity. You can however get overlaps from movement by angular velocity. This is expected as the sweep-tests work by extruding the polygon/circle through time at a specific orientation. This means that the check doesn't include rotation over time so if the object doesn't have a collision through a certain movement, if it's rotating it can end up in an overlap situation after the move.

This can happen continuously if you have an object in resting-contact with a surface being continually "pressed" into the surface with a constant-force. If the object doesn't rotate then no overlaps will occur (post-fixes). However, if the object rotates then it'll rotate into the surface (assuming it's not a perfect circle). This always happens with rigid-body as it generates torque on the objects. There's a whole world of hurt here related to how you handle contacts, iterative solvers etc. You can create hacks to get around edge-cases like this but they're always going to be hacks and open to failure.

Indeed I'm thinking of changing things around slightly in relation to angular velocity. It might be better to consider applying a tentative rotation before the sweep tests thus sweeping using the final rotation. This is only partially useful as you don't know where you're going to collide and what the rotation would be at that point, that's why the final rotation is based upon the time for the move to collision point. I might have a look around to see if there are any quick methods to sweeping using rotation. I'd be amazed if it's quick as it sounds like a continuous problem rather than a discreet one.

Anyway, there are several other key factors and what I'll do is when I'm completely satisfied with the result I'll post-up a long-due plan detailing what didn't work, what did and where to go from here.

The great thing about problems though is that they motivate you to learn a whole bunch of stuff that you wouldn't otherwise of looked at. It's a pain when you're doing it but you come out of it educated. At least that's my experience. :)

Thanks for the feedback,

Melv.

#23 Thanks a lot for the explanation Melv. You're right about just getting down and learning this stuff, if I hadn't I don't think I would have understood anything you just said. :) I see what you're saying about setting the velocity to 0 being disasterous for other modes of collision but would that be the case if all my rigid bodies were set to 'Custom Collision'? I can't test right now otherwise I would real quick. When I read the code I realized that the "Custom Collision" segment was just a stub waiting to be filled in so at first I started working there. After losing a lot of time to experiments, recompiling and having trouble rendering debug data I moved everything to TorqueScript to be able to quickly make changes, recompile and render debug data. After your explanation I can see how my solution sort of "worked".

As for an iterative solvers, that would be something like using sequential impulses correct? I wouldn't mind tackling that since I'm most of the way there but at this point I'd rather wait to get all the bug fixes I can. I realize (especially after checking out the code for Box2d_lite and running it) that it isn't very fast and a lot of bodies can slow it down but it looked interesting.

I can't wait to read your plan detailing what worked and what didn't. I'm thinking any explanations will help clear any fuzziness I still have on the subject. Even more so, I can't wait till you get to release the solution so I can continue on with my game!

I'd like to really thank you for all your work and explanation here in the forums. If I'm ever in the UK I'll drop by to buy you a beer!

#24 You're most welcome.

Yeah, forget the physics, bring on the beer. :)

Thank me when it's released and working. ;)

Melv.

#25 Any idea on when will that be? If it won't be a long time, would it be possible to get the solution before that?

#26 I don't have a handle on when the next update will be unfortunately. I'll ask about the possibility of providing some "test" executables to a handful of people.

Melv.

#27 Hey !

I see some updates around here :)
And the Melv youtube video look's promising !

As the "worklog" was quite important and as i didn'y follow every aspect of every point discussed here i would like to know if it's possible to give a simple TODO list with every fixed situations (by situations i mean when using *this* kind of shape with *that* properties and *those* forces and constraints).

So i know if it's interesting to wait the next release or if it's a good idea to try Torque X with Farseer physics engine (http://www.codeplex.com/FarseerPhysics).

Also a word on performance would be appreciated too.

I'm more than happy that finally Physics fix is on the top of your priority list cause it's been years since i'm waiting to play with the Rigid Body system of my "never used" TGB tool... Hope you understand my point of view.

Thanks to Wenceslao for moving things up around here, hope your prototype is getting well :)

#28 Thanks Rivage! My investigation/coding/learning/fixing wasn't in the collision system because although I 'thought' there might be problems there I had my hands full with just the physics! Melv pinpointed all the issues I found plus others and it seems that he's fixed them all, so for now I decided to put my work on physics on hold. If the collision system has issues, there's no way to tell if anything I write really works (Sequential Impulses for example). In addition I want to see how the built in physics works now that's it's fixed. The videos look really good to me.

In the mean time I decided to begin building a few playground levels that I can use once we get a release, unfortunately, I'm having 2 problems. The collision issues plague collisions on tile maps as well and cause objects to fall through them and I'm having a hell of a time with the tile editor. It seems to like to get into states where it won't save or render anymore requiring a restart on my end. I'm hoping we get a fix at some point soon but in the mean time I'm going to try and work on other aspects of my game.

#29 I have been having similar problems for years. Its funny, I've got my game working rather nicely in 1.2, but upon upgrading to 1.7, its not even close to working. I upgraded hoping to use the expanded functionality and behaviors in 1.7.

It does seem that the answer is always 'work around it'. The problem is that the game I'm working on is simple, but relies heavily on rigid-body physics. If I were to rewrite the whole physics engine (btw: I admire the work you did on that, Wenceslao) I certainly wouldn't use Torque. The reason I got T2D in the first place was the physics working the way they did in 1.2. I'm very glad to hear you've got it basically ironed out, Melv, and am looking forward to seeing the change.

Using the level builder would be much more entertaining than having to hand-code most of the levels in 1.2

#30 Rmullen,

I'd be interested in what kind of rigid-body game you're doing. TGB never tried to be a full rigid-body solution, it was all about have objects react in a way a rigid-body would but there always have been limitations to what I did.

For instance, I never intended for people to construct elaborate rigid-body scenes with objects that stack having many-contact situations and I've posted that time and time again. To do that requires a much slower method than what's there.

I did it for shooting at objects in a space-game where the objects move away and spin or just shoving things around a platform etc.

Doing anything more than that requires a much more sophisticated setup to iteratively solve the scene. All of these solutions will be much slower than what's there now because of the iteration of all the forces involved.

I could go away and implement the changes but it'd take a few weeks to get right. It'd be a much more solid rigid-body simulation but it'd impact all non rigid-body stuff in performance terms as well.

My recent fixes have removed the trivial interpenetration issues that were killing the simulation. You can still cause these though by stacking objects and/or setting up situations of overlap with lots of objects close together.

It's much better but there are limits is what I'm saying. That may or may not affect what you're doing.

Melv.

#31 Sure, I understand that. The key is just as you said, something behaving in a semi-believable way. It doesn't have to react realistically, only uniformly. You pointed out the 'elephant on the egg' problem. I've actually seen this happen in the alpha versions of my game (on the older versions of T2D) and it is quite amusing, the smaller shape generally squirts out or pops through the other object, not realistic, but usually predictable.

What I have not been able to negotiate is the stuttering and force build-up that you and Wenceslao both demonstrated. I'll see about polishing a demo of the original version, so you can see what I mean. The game is based on simple shapes rotating, bouncing, hovering, and bashing into one another. Its not a situation where precision is needed. Imagine a super ball bouncing around in a box. When it stops bouncing and begins to roll, you don't expect it to stop, then hop and flip on its own, or get stuck in a wall.

The reason I have not tried to tackle the situation is that I have no experience (beyond high school science) in the math involved in physics simulation. I can barely remember geometry most times. I can muddle through the math necessary for general scripting and game play design, but physics?

#32 The reason I posted was because I didn't want to raise hopes that people can start constructing buildings and things using the rigid-body physics only to have them dashed post release.

It sounds like my fixes will make you happy which is good. :)

Melv.

#33 Well it's been a couple weeks. Has anyone heard anything about a release? Melv, any chance you could provide an executable to the TGB community? I've had some plans on hold for a while now that I'd like to get back to. =)

#34 Stay tuned guys and gals :) We'll have an announcement in the very near future (weeks, not months).

#35 Thanks for the reply Stephen. I can't wait. Can you give us a hint? ;)

#36 Wenceslao, I loved the first video on this post.. cracked me up with all the boxes and what not jittering about. And that crazy music. Anyways.. made me chuckle!

#37 OK. I am a recent owner of TGB Pro Indie. Rigid Body dynamics is a big part of a game I have in mind to develop.

What is the status of the release with the fixes mentioned?

From the sounds of other blog posts and release announcements/notes, version 1.7.3 and above have these rigid body enhancements/fixes in it. However, I am jittering around like it was January 2008. I own TGB 1.7.4.

Is there a place to go find out an exact scenario, settings and everything on how to get things working like in the videos?

Thank you mucho.

#38 All I can tell you is that I finally switch to my own 2D engine and used Box2d as a Rigid Body engine.
It takes me 3 months all in all with my beginner programming level.
I lost more than 2 years with TGB waiting the Rigid Body to be fixed in order to work like Box2D.
I don't think it's possible at this time with TGB 1.7.4.

#39 OK. I am a recent owner of TGB Pro Indie. Rigid Body dynamics is a big part of a game I have in mind to develop.

What is the status of the release with the fixes mentioned?

From the sounds of other blog posts and release announcements/notes, version 1.7.3 and above have these rigid body enhancements/fixes in it. However, I am jittering around like it was January 2008. I own TGB 1.7.4.

Is there a place to go find out an exact scenario, settings and everything on how to get things working like in the videos?

Thank you mucho.

#40 With all due respect, the Rigid-body collision response in TGB was never designed to be a full Box2D engine and never will be so it will never be "fixed" to be Box2D.

The collision response code is about two dozen lines of code in the whole codebase. The jitter is caused by there not being the sophisticated mechanisms in place to deal with resting bodies and stacking such as sleeping etc. Also, because TGB offers-up so many configuration settings it's *really* easy to exaggerate the jittering by applying crazy relative forces. In Box2D, it gets around this in a number of ways, one of which is capped relative masses etc. It also constrains the values to real-world spatial values etc.

If you want a 2D game-engine that provides a solid rigid-body setup then you'll need to roll your own or incorporate Box2D into TGB.

The fixes for TGB were mainly objects getting stuck and other aspects not "fixing" rigid-body. I don't want to sound defensive here but I have said this many, many times before.

@Rivage: I don't think it's fair to say that you've "lost" 2 years waiting and if you have then I would point you to my many posts where I say that TGB only provides a simple collision response in that area. TGB isn't about rigid-body games, it just provides a simple response. I can understand you may have wanted a solid rigid-body engine but all that's ever been provided was a simple rigid-body response which works very well unless you want to start to dealing with resting contacts and stacking.

Again, I don't want to sound defensive and I admire anyone who can't find a feature so they roll their own.

I am more than willing to help anyone get the best out of TGB but there's a limit to how sophisticated the rigid-body set-up can be.

Melv.