gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Rigid Body Dynamics

#49335 - Mucca - Thu Jul 28, 2005 9:47 pm

So im in the midst of writing a 2D rigid body dynamics engine, and am at the point where the remaining problems are not really obvious, and I was just wondering if anyone had experience writing a 16:16 fixed-point physics engine. The geometric shapes Im using are circles, lines, and quadrilaterals (convex four-sided, no other contraints).

Ive gone the route of a stepped system, ie I dont try to completely disallow penetration by backing up the whole system (through a binary scan or some other means). Rather the simulation progresses in steps of maximum size, adjustable for accuracy. I let penetration occur, attempt to deduce the initial contact point of bodies, and apply necessary impulses.

One of the most obvious tricky situations is when I can't reduce collision to a single contact point, eg when a box falls squarely on a flat surface. For this, Im applying an impulse to the two colliding vertices of the box. Some strange behaviour is occuring here, specifically the combined linear impulse on the two contact points is actually greater than if I apply the impulse to the mid-point of the two points (even when the edge and surface are perfectly collinear), and both produce a subsequent momentum which is actually marginally greater than the momentum carried into the collision. The result is, when I employ 100% bounciness (e=1), the box bounces higher with a two point collision than with a mid-point collision, and boths methods bounce higher and higher each cycle. Im puzzled as to whether this innaccuracy stems from inherent fixed-point innaccuracies (which I doubt), or from using Euler integration ( which I suspect), or maybe my formulas and algorithms are just plain buggy!

Anyone had such frustrations with Euler integration before? What are the best alternatives? Runge-Cutta? I hear tell most of the full-scale 3D physics engine use quaternions, but they look rather complex (haha the pun ha..ha...sorry), and probably way too much for gameboy advance. Im already worried that the thing will ground to a halt with full levels, where you've got multiple bodies, and all the display and logic maintenance that go with that. Regardless, Im positive a physics engine is do-able on gba.

Its always the case - the theory behind such systems (not just phyiscs), are deceptively straightforward, but at the end of the day the system succeeds or fails on the tiniest details.

And of course, eventually, the greatest challenge will be to tune the thing so that the game is fun.

PS if anyone knows of any complete examples of 2D rigid body dynamics engines, Id be mucho grateful, Im all googled out =/, or conversely if anyone feels Im talking double-dutch but they'ld like to know more about this metaphoric language, Id be happy to try explain more deeply and share some ideas.

#49339 - DekuTree64 - Thu Jul 28, 2005 11:15 pm

Probably it's related to your stepping algorithm.

Try thinking about this. Say your object is 1cm above the ground, falling at 2cm/timestep. Then you see that if you move that 2cm down, you'll hit the ground. If you bounce at 100%, that basically changes your velocity to -2cm/timestep.

The problem is that you're actually still 1cm off the ground, so when you bounce back up, you'll still be that 1cm higher than you SHOULD be, meaning you can fall a bit farther than you should before hitting the ground again. Each bounce, you'll build up a bit more speed, at least until you smack your head on the moon and then things might even out :)


Really though, you should be able to keep that from being a problem by making things less bouncy, and probably limiting your max speed too.

I've never done more than play around with rigid body dynamics though. You might want to ask the folks over at the GameDev.net physics forum too, since they have a lot more experience in the area than your average GBADever.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku