TGE-ODE integration 2
by Kage · in Torque Game Engine · 03/31/2005 (12:58 pm) · 154 replies
This is the second part of the ODE-TGE integration. It's still a "work in progress", but I figured I can update the progress whenever major enhancements are made. Demo for this has been removed.
Enhancements/Corrections
-multiplayer option enabled.
-interior object collision is constructed using abstractpolys from vehiclecollision brushes
-corrected the exception problem in the 1st version
-corrected the sign mesh object geom/body labelling, which was causing erroneous behavior
Features (same as before but I'll outline it again)
-terrain collision (height map, default terrain file)
-trimesh collision (.dts files)
-box and sphere collision (.dts files)
-infinite plane collision (.dts file, see the blue strip in the mission)
-interior collision (.dif file)
-ode vehicle (.dts file)
-ragdoll (.dts file, but yet applied to player.cc)
Required Work
-more work on the interpolation
-tie in ragdoll to player.cc
-correct the player response to ode
-verify TGE's default collision notification and damage process
-verify sounds
Let me know what you think.
Contents of the .rar file
-ode.zip & common.zip (leave them as they are)
-dll files
-exe file
You only need to uncompress the .rar file to a folder to play the demo.
edit: added the .rar contents
Enhancements/Corrections
-multiplayer option enabled.
-interior object collision is constructed using abstractpolys from vehiclecollision brushes
-corrected the exception problem in the 1st version
-corrected the sign mesh object geom/body labelling, which was causing erroneous behavior
Features (same as before but I'll outline it again)
-terrain collision (height map, default terrain file)
-trimesh collision (.dts files)
-box and sphere collision (.dts files)
-infinite plane collision (.dts file, see the blue strip in the mission)
-interior collision (.dif file)
-ode vehicle (.dts file)
-ragdoll (.dts file, but yet applied to player.cc)
Required Work
-more work on the interpolation
-tie in ragdoll to player.cc
-correct the player response to ode
-verify TGE's default collision notification and damage process
-verify sounds
Let me know what you think.
Contents of the .rar file
-ode.zip & common.zip (leave them as they are)
-dll files
-exe file
You only need to uncompress the .rar file to a folder to play the demo.
edit: added the .rar contents
About the author
Professional gameplay programmer and have worked in the industry since 2004. Specialized in: animation system, player control, weapon system, AI, combat, camera, physics - ODE/Havok, optimization, and networking.
#42
I agree with Gary that multiplatform is essential for a code-pack as advanced as this one, it is only logical as it extends your possible income once/if you decide to release it as a commercial add-on.
On the technical side (and may I warn you I am in no way knowledged when it comes to these things) I'd really like if you could choose how expensive the physics should be, i.e. if you only want some barrels rolling around vs. full-blown rag-dolls and vehicle physics.
Say if you sit on a less than average system you could turn rag-dolls etc. off too save cpu for other tasks.. see what I mean ??
anyhoo, good luck with in your work.
04/11/2005 (4:01 pm)
Hi Akio, I've been following this thread with great interest, I'm but one of many that would really like to see some advanced physics intergrated in TxE.I agree with Gary that multiplatform is essential for a code-pack as advanced as this one, it is only logical as it extends your possible income once/if you decide to release it as a commercial add-on.
On the technical side (and may I warn you I am in no way knowledged when it comes to these things) I'd really like if you could choose how expensive the physics should be, i.e. if you only want some barrels rolling around vs. full-blown rag-dolls and vehicle physics.
Say if you sit on a less than average system you could turn rag-dolls etc. off too save cpu for other tasks.. see what I mean ??
anyhoo, good luck with in your work.
#44
@Jorgen - CPU overhead is definitely a concern and because of this all ode object collision and physics (integration) are not processed when possible. More on this addressed below.
@Thc-03 - A long list:) Let me address each one here.
>>Automatically disable physics on objects not in camera's view
Doable but still costly. My implementation disables ode object's collision detection and physics when an object comes to rest even if it's in camera view. Frustum culling may be ideal in certain situations but not when you have a racing game using AI vehicles (not all will be in veiw). In addition, when TGE objects are too far from view they are removed from the scene and ODE objects do the same thing - they're removed from ODE world/space.
>>Collisions still detected through dedicated meshes
I integrated ODE to TGE with an idea to keep TGE in tact as much as possible w/o rewriting the dts, dif exporters. The mesh collision is done using "collision-x" details in the dts exports and "vehicle brushes" in dif files. DTS can contain up to nine collision details, and DIF is up to 256 faces.
>>Ragdoll joint limit (an angolation wich the joint can't rotate beyond)
In the works.
>>Particle physics (physics attached to particles, with the ability to disable it)
Not part of ODE but still uses TGE. I think it's working perfectly and I decided not to change how particles are working.
>>Ability to define joints in script (for non-generic physics needs) and place them in the mission editor and/or link with a mesh. (eg, a lamp being shoot will use a joint positioned in the mission editor and linked with the lamp itself to make the lamp swing left and right)
Instead of scripting most of this, I decided it was simpler to construct jointed objects (dts objects) in 3D modelers apps, e.g. Max, Maya, etc., and create bones and label them as "jointball", "jointhinge", "jointslider", etc. This way, scripts are simplified and just need to specify the mass and whether to use collision details or primitive shapes. One example is the jointed cubes in the demo.
Non movable joints (or joints assigned to 0) can be constructed using this method as well:)
All the tips are already handled:)
Thanks for the input guys:)
edit: corrected typos
04/12/2005 (10:39 am)
@Gary - I have resources to release the OSX and Win version, but the Linux version will be delayed:)@Jorgen - CPU overhead is definitely a concern and because of this all ode object collision and physics (integration) are not processed when possible. More on this addressed below.
@Thc-03 - A long list:) Let me address each one here.
>>Automatically disable physics on objects not in camera's view
Doable but still costly. My implementation disables ode object's collision detection and physics when an object comes to rest even if it's in camera view. Frustum culling may be ideal in certain situations but not when you have a racing game using AI vehicles (not all will be in veiw). In addition, when TGE objects are too far from view they are removed from the scene and ODE objects do the same thing - they're removed from ODE world/space.
>>Collisions still detected through dedicated meshes
I integrated ODE to TGE with an idea to keep TGE in tact as much as possible w/o rewriting the dts, dif exporters. The mesh collision is done using "collision-x" details in the dts exports and "vehicle brushes" in dif files. DTS can contain up to nine collision details, and DIF is up to 256 faces.
>>Ragdoll joint limit (an angolation wich the joint can't rotate beyond)
In the works.
>>Particle physics (physics attached to particles, with the ability to disable it)
Not part of ODE but still uses TGE. I think it's working perfectly and I decided not to change how particles are working.
>>Ability to define joints in script (for non-generic physics needs) and place them in the mission editor and/or link with a mesh. (eg, a lamp being shoot will use a joint positioned in the mission editor and linked with the lamp itself to make the lamp swing left and right)
Instead of scripting most of this, I decided it was simpler to construct jointed objects (dts objects) in 3D modelers apps, e.g. Max, Maya, etc., and create bones and label them as "jointball", "jointhinge", "jointslider", etc. This way, scripts are simplified and just need to specify the mass and whether to use collision details or primitive shapes. One example is the jointed cubes in the demo.
Non movable joints (or joints assigned to 0) can be constructed using this method as well:)
All the tips are already handled:)
Thanks for the input guys:)
edit: corrected typos
#45
Gary (-;
04/12/2005 (1:55 pm)
@Akio: What's the level of integration into the platform{whatever} source trees, and the availability of this modification source as a whole? I'm not completely averse to taking a look myself...Gary (-;
#47
04/12/2005 (11:47 pm)
*Applaus* Akio *More Applaus* enters *Insance Applaus* room * Psycotic Applaus* ...
#48
@Thc-03 - Attaching joint to body 0 is defined as "a zero body refers to the static environment" which allows you to 'hang' objects anywhere.
@Burning - thanks:)
I emailed Josh Williams regarding whether GG will be interested in selling this pack, so we'll see what happens.
edit: typos
04/13/2005 (9:22 am)
@Gary - there are no platform dependencies on how ODE works in the game, with an exception of how ODE lib is build. And yes, maybe you'll be able to take a look someday:)@Thc-03 - Attaching joint to body 0 is defined as "a zero body refers to the static environment" which allows you to 'hang' objects anywhere.
@Burning - thanks:)
I emailed Josh Williams regarding whether GG will be interested in selling this pack, so we'll see what happens.
edit: typos
#50
Any dts objects can be created w/ joints (bones) opposed to writing script for it. For example, say I want to create a free floating cube using a joint. For simplicity sake, I'll use a ballJoint as example. If I were to attach one side of the joint to the cube body (joint pos1) and the other to 0 (zero) body (joint pos2), cube will not drop from it's location but it can move about the joint pos2 -- it will be able to revolve around joint pos2 since it's using balljoint.
Does that help?
Edit: Actually this explanation is wrong since there is only one JointPosition to place for balljoints. Here is a better procedure:
-create a cube and body
-create a balljoint above the cube (JointPos)
-attach one side of the joint to the cube
-attach the other to body 0 (static env.)
This will allow you to float the cube in mid air and the cube will move about the joint node above it.
04/13/2005 (2:42 pm)
Hmm, maybe I misunderstood your original thoughts about jointed objects, but let me explain what I had in mind.Any dts objects can be created w/ joints (bones) opposed to writing script for it. For example, say I want to create a free floating cube using a joint. For simplicity sake, I'll use a ballJoint as example. If I were to attach one side of the joint to the cube body (joint pos1) and the other to 0 (zero) body (joint pos2), cube will not drop from it's location but it can move about the joint pos2 -- it will be able to revolve around joint pos2 since it's using balljoint.
Does that help?
Edit: Actually this explanation is wrong since there is only one JointPosition to place for balljoints. Here is a better procedure:
-create a cube and body
-create a balljoint above the cube (JointPos)
-attach one side of the joint to the cube
-attach the other to body 0 (static env.)
This will allow you to float the cube in mid air and the cube will move about the joint node above it.
#51
do you have any thoughts regarding the problem of ragdoll vibrating itself silly while it's just lying on the ground? I've been using geomTransform objects in my ODE ragdoll figure, and get similar behavior which started when I turned on internal collision detection (to keep limbs from passing through each other, as opposed to just colliding against the ground.) Before that it was all calm sailing, after that the dude started vibrating.
What I found upon further debugging was that I was getting lots and lots of "phantom" collisions, between objects that shouldn't have been anywhere near each other. I found a half-assed workaround, but I didn't get it solved yet. Just wondering if your issue is similar or different origins.
04/13/2005 (2:55 pm)
Hey Akio, do you have any thoughts regarding the problem of ragdoll vibrating itself silly while it's just lying on the ground? I've been using geomTransform objects in my ODE ragdoll figure, and get similar behavior which started when I turned on internal collision detection (to keep limbs from passing through each other, as opposed to just colliding against the ground.) Before that it was all calm sailing, after that the dude started vibrating.
What I found upon further debugging was that I was getting lots and lots of "phantom" collisions, between objects that shouldn't have been anywhere near each other. I found a half-assed workaround, but I didn't get it solved yet. Just wondering if your issue is similar or different origins.
#52
I also observe a slight jitter but I'm not sure if there is anything to stop it from happening except to disable the body.
Great ragdoll animation pack by the way:)
04/13/2005 (3:05 pm)
Chris,I also observe a slight jitter but I'm not sure if there is anything to stop it from happening except to disable the body.
Great ragdoll animation pack by the way:)
#54
04/14/2005 (11:07 am)
You have some good ideas, but all jointed objects will be created using dts files for now.
#56
In anycase, I like the feedback I got on my work:)
04/14/2005 (2:59 pm)
Funny thing is that I'm discussing my plans as if GG is interested in my work, but unfortunately this is not the case. From what I can see, there are many indie groups that have done this type of work already and it won't be long before GG will eventually have their own ODE pack.In anycase, I like the feedback I got on my work:)
#57
Oh, also, I finally got to play with it yesterday having found a windows box. Worked very well. Cool!
Gary (-;
04/14/2005 (3:18 pm)
Any chance us linux users could get our mitts on this work anyways?Oh, also, I finally got to play with it yesterday having found a windows box. Worked very well. Cool!
Gary (-;
#58
04/14/2005 (3:35 pm)
We definitely want to check this out Akio. I just wrote you not 15 minutes before you posted here. :) Thanks! 
#60
Would this ODE intergration support a structure for a Beat'em up looking at player model collission, etc..
Toby.
04/15/2005 (10:26 am)
Akio,Would this ODE intergration support a structure for a Beat'em up looking at player model collission, etc..
Toby.
Torque Owner Gary "ChunkyKs" Briggs
Linux is my primary platform, but I wouldn't purchase anything that doesn't work with windows and OSX aswell [since this is Torque we're talking about]..
Gary (-;