pTymN
02-08-2007, 08:12 PM
Howdy,
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.
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.