Physics/ODE
From TDN
|
ODE, Physics, and Creamy Torque Goodness
Overview
Disclaimer: I'm the author of ODEScript
The intent of this article is to cover reasons for using ODE as opposed to other phyiscs engines [indeed, any physics engines at all], and describe common approaches to this.
It may seem a little backward to start here, and not a little doom-and-gloom, but let's start with reasons to NOT use ODE in TGE.
What's not to want?
ODE is a fully-fledged physics solver that can be used to do many, many, things. You should seriously consider whether or not you actually WANT this in your game. Importantly, Torque already has what most people call "Physics", and these will, likely as not, already solve most of the problems you have.
Torque's physics are, at time of writing, mostly just doing collisions within the world, and moving rigid bodies about. This includes a demonstrably working vehicle system [in fact, there are a few vehicles built into TGE's code as it comes in the box and resources on modifying these to behave like other vehicles], and normal player interactions such as, say, running into walls, and hitting the ground.
This is a respectable physics system and should not be immediately discarded just because you want ragdolls [network-expensive and not immediately better than the [Chris Calef's canned ragdoll pack], different vehicle handling [the car in the TGE demo may not handle like the tank in your game, but without modifying physics yourself, you can use the [Bravetree Tank pack], or more realistic jibs
Most importantly, replacing an entire physics engine is simply a lot of potentially unnecessary work.
What's to want?
My original reasons for working on ODE in Torque are that Torque's physics really are missing a few things that I want for my eventual dream game; Joints, most importantly. After that, comes the sheer flexibility of a full physics system, and the fact that I wanted it all accessible from Torquescript.
Torque doesn't have a real inverse kinematics solver, and that's pretty high on my wishlist. I also already have models coded in ODE that do a few random bits & pieces that I like, and intend to eventually see in TGE.
ODE
[ODE] [Open Dynamics Engine] is an excellent physics system. While it's not Havoc on features, it's not Havoc on price either.
ODE's merits are covered extensively on ODE's homepage, but suffice to say here that it works well for me, its cross-platformness is unrivalled, and it's free. Free as in beer [no monetary costs at all, ever], and Free as in speech [You may choose to use it under the LGPL or BSD licenses].
In terms of sheer number of platforms, ODE works well in my personal experience on Linux, OSX, and Windows. Since this matches the officially supported TGE platforms, it seems a good candidate for integration into Torque, if platform-independance is a primary design goal, it's a good bet.
Other engines
This is an article about ODE and Torque physics, but it wouldn't be complete without a short list of alternatives. A comparison of the merits of each is left to the inquisitive reader.
How much to change?
On the whole, there are what I consider to be two important things to change if you wish to implement new physics in Torque; collisions, and other physics. Additionally, there are different approaches to each of these, covered separately.
Collisions
Torque has a complete, working, collision engine. As demonstrated by [RigidShape], this is more than sufficient for most things. ODEScript studiously avoids replacing this.
It *does* have limitations, though, and for many games, these may be significant. For very high velocities, it's possible for objects to get stuck in terrain. At very small sizes, weird things happen. I've never seen these problems personally, more information is available on the TGE forums.
Until you have demonstrated that Torque's collision detection doesn't work for your application, replacing it is a nontrivial amount of work that may be unneccesary.
Other Physics
Just like the currently working physics, [RigidShape] shows that a lot of other normal interactions are already covered in Torque
The big thing I was shooting for with ODE was joints. These don't currently exist in Torque
At risk of becoming overly reptitive: Until you have demonstrated that Torque's normal physics doesn't work for your application, replacing it is a nontrivial amount of work that may be unneccesary.
Approaches
Right now, there are two major implementations [with code available] of ODE in Torque, each taking different approaches.
ODEItem
[ODEItem] takes the obvious [and arguably sensible] route of implementing ODE objects inside of torque. ODEItem is a resource whose behaviour mimics a rigidshape, but using ODE. It's not intended as a complete implementation of arbtrary physics in Torque, so much as a rigid shape with bonuses.
ODEItem does a healthy amount of code replacement, and I believe uses ODE collisions. It also requires a modified ODE
ODEScript
[ODEScript Physics Resource on GG] ([ODEScript Forum thread]) ([older thread]) takes a different approach, which is to implement ODE objects as TorqueScript objects, and expects the game developer to utilise these from script as they choose
Specific design goals for ODEScript:
- Magical code drop-in; I always have terrible luck with code resources that involve huge amounts of code change, so wanted a resource that could just be dropped into the codebase and added to compilation
- Making the user do work in script instead of C++; Because that's the Torque Way [and that's a Good Thing]
- NOT replacing as much as possible
- Don't replace Torque collision stuff [at all, ever. Unless at some point in future it becomes demonstrably necessary, which it hasn't]
- Don't replace any Torque physics - This is adding a new set of objects to torque, not breaking old ones
- No modification of ODE; because using libraries as they come in the box is a Good Thing
- [not done yet. also, the holy grail] Magical network physics
Approaches without Code
There are other approaches to integrating ODE into torque, including the very good replace-everything approach that Akio took here: [[1]]. Not having released any code, this is therefore not yet something usable by everyone.
Dimensions
Why limit yourself to three dimensions?
ODEScript originally worked in T2D as well as TGE. The most recent iteration of it doesn't work with T2D due to the choice of objects that it is derived from. Past code releases [please read [the old ODEScript thread] worked with it, and the intention is for these to work in future, also.
Noticably, though, T2D has a very good, very fast, physics system with an equivalent to the joints that I so desperately wanted.
Conclusions
There are very few concluding remarks I can make here; so this article will have to just end
Categories: Physics | ODE | TGE | T2D
