View Full Version : Physics implementation

02-08-2007, 08:12 PM

I've been looking through Torque Game Builder and also found this tool referenced in the Clanlib forums. It looks pretty cool, but I'm very curious about what physics implementation is being used. The physics looked like some work had been put into it, which was surprising because in the few minutes that I played around with 'em, I didn't see any flaws.

Can the physics encounter tunnelling problems, or is it doing something more than bitmap based collision maps?

[Edit] I looked more closely at the scripts and it appears that you are using a penetration resolution step, which implies that the physics is doing iterative stepping and not using swept collisions. I've been WAAAAAY too lazy to build a tool that allows my physics engine's collision outlines to be edited, and you probably wouldn't mind a robust physics implementation.

My physics engine guarantees that there can never be interpenetration, so impulse or penalty based methods of collision resolution are never required. All collision tests are swept (entire area that object passes through in a time interval is tested for collisions), and there are no constraints on the configuration of the object outlines (convex, concave, animated and rotating, doesn't matter what), and best of all, I am getting > 1000 fps in my current test project. Anyhow, I would love if one of the lead developers on this project would engage in conversation with me about how we might be able to do an integration of projects.

I can't show you anything that I have currently, unless you are willing to install the evaluation version of Corman Common Lisp. I'm aware of the issues of using Lisp, so I'm syncing my very old C++ version back up to par with the last 8 months of Lisp only development.

-Tim K.

02-09-2007, 04:44 AM
Hi Tim,

That's right, it's not using swept collisions - it fixes penetration with verlet integration based on Olivier Renault's code here (http://www.members.lycos.co.uk/olivierrenault/).

In practice tunnelling doesn't seem to be a problem with the examples because the physics simulation locks at a minimum 60 hzs regardless of framerate, so as long as speeds don't get crazy and walls aren't too thin, things usually work pretty well, pushing things out of eachother and of walls.

The good thing about this is the engine doesn't break or send things flying at high speeds if you pasted 10 apples into the exact same place - they would nicely push apart.

Would surely love to see a C++ version of your physics to check it out!