Game Development Community

ODEScript Physics

by Gary "ChunkyKs" Briggs · 12/08/2006 (10:29 am) · 106 comments

Download Code File

ODEScript
The Torque C++ modification

This code is an implementation of the ODE API, making it available to torquescript.

As a whole, the API is a "t" [for Torque] prefix on the normal ODE objects, and converted to think in terms of torque and objects rather than functions;

In C:
dBodyID b = dBodyCreate(world);
dBodySetLinearVel(b, x, y, z);

In TorqueScript:
datablock tdBodyData(bodydb) { foo="bar"; }; // foo="bar" is ignored
$b = new tdBody() { worldsim = $odeworld; datablock = bodydb; } ;
$b.SetLinearVel(x,y,z); // C Style
OR
$b.SetLinearVel("x y z"); // TorqueScript Style
Note that both calling styles are supported.


Build Instructions:

1) Edit shapeBase.h, and find this [around like 70 or so]:
friend class ShapeBase;
friend class Vehicle;
and add:
friend class ODEShape;
2) Add all the .cc/.h files in odescript/ to your build, and remember to link with ODE.
3) If you want projectiles to collide with ODEShapes, you'll need to edit game/projectile.cc and add "StaticShapeObjectType |" to your Projectile::csmStaticCollisionMask.

For more detailed instructions for each platform, check buildinstructions.lyx in odescript/.


Thanks to Ray "Noolness" Gebhardt for all his Torque help, including specifically, writing ExampleGameBase and ExampleCollider, from which all my objects derive.


ODERocks
The Torquescript demo of ODEScript

This is a mod for TGE, that should be run with starter.fps or similar, once you have ODEScript [the c++ source modification] built into your Torque install. Run the game with "-mod oderocks" on the command line

Once you're in-game, hold down the C or V button to see a small UI of physics buttons.

This isn't really anything exciting, it just serves to demo some of the objects in ODEScript, and has been used extensively by me during development


Here's a few videos of what it looks like in action:
First Demo [basic chain, single bodies]: youtube.com/watch?v=cA-ncyU51G8
Second Demo ["ragdolls", buoyancy]: youtube.com/watch?v=gjEeN5er6aM
Third Demo [Juggling, Inverse Kinematics]: www.youtube.com/watch?v=PEe55nibKHA

Chunky (-;

icculus.org/~chunky/
#61
04/16/2007 (2:11 pm)
Oh, hey, look at that.
Buoyancy was trivial to add.

Buoyancy is always in the opposite direction to gravity. "up" is such a relative term...
Drag is always in the opposite direction to the motion of the body.

Just unset the "ignorewater" variable on an ODEShape. The resource itself has been updated to reflect this. Rocks are now buoyant by default. Whether or not this fits in with your world view is up to you :-)

Drag and density constants are both in ODEShapeData.

Uh, did I miss anything? Once youtube gets around to compressing it, there'll be a short vid here: www.youtube.com/watch?v=goSnVwTFRBY and another one here: www.youtube.com/watch?v=6SRdKQdV7Ho.

Gary (-;
#62
04/16/2007 (4:29 pm)
Gary,

two thumbs up ! You rock !

Cheers,
Andreas
#63
04/16/2007 (4:31 pm)
Glad you like it :-)

Gary (-;
#64
04/16/2007 (4:45 pm)
Oh, and for anyone reading this. If your game is only single-player or few-players, or highspeed network, etc, you can get a lot smoother physics by stepping up the network rate. Try setting these in the console:
$pref::Net::PacketRateToClient = 30; // Up from the default 10
$pref::Net::PacketSize = 450; // Up from the default 300

It's not ideal, but it does make the physics smoother than a very smooth thing :-)

Gary (-;
#65
04/20/2007 (12:00 pm)
buildinstructions.pdf

Detailed build instructions for each platform.

Having now tried building on windows, I suddenly understand why so many people were having problems making it work :-)

Gary (-;
#66
04/28/2007 (12:08 am)
I just updated the resource. Salient changes:
- Presets menu. Hold V in the ODE rocks mod for a bunch of scripted presets for more than just the individual ball.
- Many speed boosts
- All instances of Sim::findObject should have been removed from the simulations loops.
- use dynamic_cast. Incurs run-time performance penalty but only has to be done once and increases stability in case of experimenting developer being stupid.
- Alwaysupdatefromshape, can be used for inverse kinematics, or for making kork drag a bunch of crap around the map with him. Can make use of fixed joints [configurable] for improved simulation behaviour at minor performance cost.
- Twobodies the same error message supressed. Torque is being dumb, and I don't know how to fix it, but complaining about it only slows stuff down
- Buildinstructions updated
- Joint parameters are actually settable as opposed to being functions accepting opaque datatypes only available from C
- Bunch of other stuff. Can't remember.

Gary (-;
#67
05/01/2007 (11:47 am)
concerning the ball and socket joints, in the script it has one co-ordinate for each ball and socket joint, so how does the anchor know what to attach itself to? does it simply link to the center of the object or something?
#68
05/01/2007 (2:08 pm)
Hm. How to explain. Bodies are perfectly rigid. Cannot bend, ever

Exposing my incredible, awesome, Tim-Aste-like artistic skill, here's a picture of two bodies. Their center is the red dot, and there's a force being applied to the bodies, at the green dot, in the direction of the arrow.

icculus.org/~chunky/stuff/wheresmyforce.png
Obviously the first body will end up rotating. Second body will behave exactly the same way; having a small gap in it doesn't make a difference. The body is rigid, so a force being applied works the same. Now imagine that the bodies aren't necessarily even one piece, but behave as if they were:

icculus.org/~chunky/stuff/theresmyforce.png
Now the body isn't even visibly attached to itself, but it's not too much of a leap to imagine it working exactly the same way.

Now add another body next to it. Just like this one, it's not necessarily attached:

icculus.org/~chunky/stuff/nowtherestwo.png
Now imagine that the green dot is a ball and socket joint instead of a place to apply forces. The joint is outside the bodies, but it's behaving like it's rigidly attached to each, still.

So, did that make sense, or did I make everything worse?

Here's the ODE doc on the topic of ball and socket joints

Gary (-;
#69
05/01/2007 (2:38 pm)
Gary,
good explanation ! Answered a question I didn't even know I had :-)

(but stick with coding ... stay away from drawing stuff ... that's the dark side) ;-)

Cheers,
Andreas
#70
05/01/2007 (3:20 pm)
that didn't help -_-

in your code you have one coordinate that both things attach themselves to, so if i think of it the way you just described it makes me more confused.

as i understand it both of the bodys connect to the joint with an anchor; and the anchor is a point on both bodys that connects to the joint. but in your code you only set one joint anchor, so there are three balls in the chain then it two of them should be attached to the same attachment point, so it would look kindof like a triangle. but it doesn't it appears to have two joints, one for each of the things it attaches to.

so i was asking if say you made the anchor at the center of the spheres, and the joint, and the space between, made it look like a chain; and if there was no space between them would it clump together and look like a triangle.

i know that i have a habit of trying to explain things while using only half a thought, so don't bother pointing that out.
#71
05/01/2007 (3:33 pm)
Hm. Are you talking about the chains, here? Or the humanoid?

Ooooh. I get it. "No."

You set a body's position, and set another body's position. Then you connect the two with a joint.

The "anchor" is the place in space where the ball and socket joint exists when you first set it up. It describes the joint, it doesn't describe how the joint is attached to the bodies. The joint is attached to the bodies because that's what the joint *is*. Where the joint is phyiscally attached to the body is entirely moot [which is what I was trying to explain above]


And on the topic of artwork. I showed a video of my humanoid, juggling, to a friend:
Quote:4:45:00 PM Greg: The art is great also. I'm hard pressed to tell your artwork from the example stuff.
4:45:06 PM gjb105: ahahahhahaha
4:45:24 PM gjb105: I've come to the conclusion that I'm a coder not an arist
4:45:31 PM Greg: hehe
4:45:33 PM gjb105: It's just a... period of self-discovery
4:45:52 PM gjb105: You see that cube? Fucker took me three days to figure out
4:46:07 PM Greg: because the picture of a cow wasn't a hint.
The cow he speaks of is the first image in my gallery. I'm not kidding that it took me three days to figure out how to make a cube appear in torque from blender.

Gary (-;
#72
05/01/2007 (3:38 pm)
what?

if you can't control where the joint attaches to the body then how would rag-doll physics work? wouldn't there be the chance of the head being attached upsidedown or something?
#73
05/01/2007 (4:24 pm)
Because you position the bodies before you attach them; when you attach the joint, it presumes the bodies are in the right place. Check out this one again:
icculus.org/~chunky/stuff/nowtherestwo.png
The two bodies have been placed, and then you attach the joint. The joint doesn't have to be inside of a body.


*cries* this is why I write mechanics code instead of teaching it. Sorry, it works, but I can't easily explain it.

Gary (-;
#74
05/09/2007 (8:39 am)
I was wondering if this is compatable with TGEA?

I followed the instructions and found that there is no VS2005\Torque SDL.sln.

In fact there is no folder by that name and no file by that name either. not in the hole SDK.

There is however a vc8/TGEA SDK.sln.

I assumed this to be the most logical thing to stab at. so I followed the directions to the letter assuming this...

I am using VS2005 and followed this steps in its set up:
http://tdn.garagegames.com/wiki/TGEA/InstallVS2005

I get a lot of warnings that lead me on a wild goose chase back to repairing older versions for use with VS2005.

(I come out for the fixes to the error search here:
http://tdn.garagegames.com/wiki/Torque/vs2k5 )
I know this is stepping out of topic a bit, but I don't know if this is related to something I did or this change..... Sorry for being a way newbie on this but any help would be much appreciated.
#75
05/09/2007 (12:50 pm)
I *believe* it should work with TGEA. TSE's core stuffs is still the same as TGE [GameBase, ShapeBase, BitStream...]. I have a TGEA license, so if you reference snippets of code I can look them up, but I don't have a Windows machine that can do that whole TSE thing [*insert Linux TGEA rant here].

If you open up torque_ver.h, you'll find a #define that you can uncomment to tell it you have TGEA, but currently it makes no difference to the build.

You did the right thing by opening that other vc solution.

What are the actual errors you're getting?

Quote:back to repairing older versions for use with VS2005

If it wouldn't link with various obscure errors, you probably need to recompile the libraries or toolkits you're linking against, using the version of the compiler that you're using. This goes double if you downloaded a prebuilt ODE and tried to link it with VS2005 SP1 [SP1 angers me]. You should definitely build your own ODE, whatever.

Anyways. Paste a few of the specific errors here, and I'll see what I can do.

Gary (-;
#76
05/09/2007 (4:13 pm)
I moved the ode.dll to the example folder and I try to run it and I get:

"The application failed to initialize properly (0xc000007b). Click on OK to terminate the application."

My error log in total is uploaded here:

Error Log

I highlighted in yellow the things I think are the issue.
#77
05/09/2007 (4:41 pm)
Let's see:
Quote:c:\tgea_sdk\desolation_ode\engine\odescript\odehelper.cc(102) : warning C4715: 'ODEJointParameterVal' : not all control paths return a value
Not really a problem, and I fixed it a few days ago. You need to edit that file and change the function thus:
const char *ODEJointParameterVal(int param) {
	switch(param) {
		case dParamLoStop: return "dParamLoStop"; break;
		case dParamHiStop: return "dParamHiStop"; break;
		case dParamVel: return "dParamVel"; break;
		case dParamFMax: return "dParamFMax"; break;
		case dParamFudgeFactor: return "dParamFudgeFactor"; break;
		case dParamBounce: return "dParamBounce"; break;
		case dParamCFM: return "dParamCFM"; break;
		case dParamStopERP: return "dParamStopERP"; break;
		case dParamStopCFM: return "dParamStopCFM"; break;
		case dParamSuspensionERP: return "dParamSuspensionERP"; break;
		case dParamSuspensionCFM: return "dParamSuspensionCFM"; break;
		default: return ""; // Add the default: bit
	}
 return ""; // Add this just in case the compiler's trying to be smart
}

Quote:..\engine\platformWin32\dxVersionChecker.cpp(149) : warning C4996: '_wsplitpath' was declared deprecated
C:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(782) : see declaration of '_wsplitpath'
Message: 'This function or variable may be unsafe. Consider using _wsplitpath_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'

..\engine\gfx\D3D\gfxD3DDevice.cpp(39) : warning C4482: nonstandard extension used: enum 'GFXVertexColor::ColorOrdering' used in qualified name
Not my bugs. Just two more in the long list of warnings that GG should fix in their codebases.

The *actual* bug you have is also not a bug of mine. Some Googling indicates you should try:
1) Ensure [5.2.2.j in my build instructions] you've added the library as "ode.lib", even if you're linking against a .dll. [do this first] [check it again]
2) this one on MSDN talks about the embedded manifest file.
3) this one perhaps your platform SDK is out of date?
4) this or this, perhaps you have the fabulous Klez application installed? It supposedly causes errors like that.

That error seems like a common one, but it's outside the realm of my windows knowlege :-/

Gary (-;
#78
05/09/2007 (8:13 pm)
Ill take the problem to another forum. Thank you so much for your valuable time! I really hope to get this working and see this marvel at work.

By the way most of that was over my head but I did get the part that was in your instructions. the rest will take some doing.

(Please if you get time to update your instructions I bet it would save some people possible confusion. I figured it out but others might not.)

Thanks again!
-G
#79
05/10/2007 (11:49 am)
Quote:(Please if you get time to update your instructions I bet it would save some people possible confusion. I figured it out but others might not.)

So you got it fixed? What did you change to fix it?

Gary (-;

PS I *think* that if you want to try out the stuff, it should in theory work best as a demo with Alienforce's starter.fps, assuming the co-ordinates aren't changed. Ever since you first posted, I've been trying to convince Visual Studio to do what I want so I can actually try this...
#80
05/11/2007 (5:28 pm)
I've just updated the resource. Among other things, it now contains an integration guide; something of a Quickstart, if you will, on using ODEScript and getting your first object into the world.

As with all my documentation, it's written using LyX. If you don't have LyX installed, there's a version exported to PDF here: chunky.megastep.org/torque/integrationguide.pdf

Gary (-;