ODEItem v0.10
by Pascal · 01/04/2004 (1:38 pm) · 130 comments
Edit: 1/9/04 -- updated to 2nd Release w/ multiplayer and a couple more config features (see docs)
You can download the file from HERE (it was too large with the included .lib files for GG)
see the README.html file for complete installation usage instructions.
A number of short engine changes are required to get it working (three have changed since release 1, see docs)
Included are compiled versions of the .lib files for ODE as well as the slightly modified source.
Take a look at the following Movie Zipfile for a demo (I think its compressed with DivX..)
For those of you familiar with ODE I decided to use the torque engine for collision mechanism instead of the one built into ODE. While this is probably a performance hit (or maybe not, I don't really know enough to say) it does make life much easier as any DTS file with collision meshes should work correctly with the rest of the world including the terrain.
The code will need some modifications to make it useful so check out the ODE Homepage for some more info on the engine. I need to do a revamp of the code an clean up my initial confusion a little so I will probably release a new version in a couple of weeks.
Included are a crate and an trash can to get you started.
Have fun throwing crates around (I did)..
My next step is to try to get some rag dolls working but that may be a little while.
-Pascal
You can download the file from HERE (it was too large with the included .lib files for GG)
see the README.html file for complete installation usage instructions.
A number of short engine changes are required to get it working (three have changed since release 1, see docs)
Included are compiled versions of the .lib files for ODE as well as the slightly modified source.
Take a look at the following Movie Zipfile for a demo (I think its compressed with DivX..)
For those of you familiar with ODE I decided to use the torque engine for collision mechanism instead of the one built into ODE. While this is probably a performance hit (or maybe not, I don't really know enough to say) it does make life much easier as any DTS file with collision meshes should work correctly with the rest of the world including the terrain.
The code will need some modifications to make it useful so check out the ODE Homepage for some more info on the engine. I need to do a revamp of the code an clean up my initial confusion a little so I will probably release a new version in a couple of weeks.
Included are a crate and an trash can to get you started.
Have fun throwing crates around (I did)..
My next step is to try to get some rag dolls working but that may be a little while.
-Pascal
About the author
#22
and thus into the ode lib.. its not a problem with the files added to torque, but in ode itself...
ODE docs: ODE makes heavy use of the stack for storing temporary values. For very large systems several megabytes of stack can be used. If you experience unexplained out-of-memory errors or data corruption, especially on Windows, try increasing the stack size
...
dWorldStep requires memory proportional only to the square of the number of DOF's removed. StepFast1, though, is still linear, but it has nothing to do with the number of iterations per step. So this means the dreaded "There was a big pile-up and ODE crashed without an error message" problems (usually stack overflows) won't happen with StepFast1. Or at least that you'll be rendering at a minute per frame or slower before they do.
...
The general answer to this question then, is: use StepFast1 when you don't mind having a few more parameters to play with to get the system stable, and you want to take advantage of it's speed or memory advantages. If you find yourself running into situations in your simulation where large numbers of bodies come in contact, and dWorldStep becomes too slow, try switching to StepFast1. Many systems will work just fine with nothing more than changing the dWorldStep function call to dWorldStepFast1.
01/05/2004 (3:38 pm)
well it traces back to the world stepand thus into the ode lib.. its not a problem with the files added to torque, but in ode itself...
ODE docs: ODE makes heavy use of the stack for storing temporary values. For very large systems several megabytes of stack can be used. If you experience unexplained out-of-memory errors or data corruption, especially on Windows, try increasing the stack size
...
dWorldStep requires memory proportional only to the square of the number of DOF's removed. StepFast1, though, is still linear, but it has nothing to do with the number of iterations per step. So this means the dreaded "There was a big pile-up and ODE crashed without an error message" problems (usually stack overflows) won't happen with StepFast1. Or at least that you'll be rendering at a minute per frame or slower before they do.
...
The general answer to this question then, is: use StepFast1 when you don't mind having a few more parameters to play with to get the system stable, and you want to take advantage of it's speed or memory advantages. If you find yourself running into situations in your simulation where large numbers of bodies come in contact, and dWorldStep becomes too slow, try switching to StepFast1. Many systems will work just fine with nothing more than changing the dWorldStep function call to dWorldStepFast1.
#23
01/05/2004 (6:32 pm)
Pascal, in my original code, I had a client and a server world. Then in the OnAdd method, it checked wheather it was on the client or server and added the object to the right ode world. It made it a slightly better approximation in between updates, but I never tried it with a lot of lag, so I dont know how much it really helped. I assume it would help more if the lag was larger though.
#24
Very nice looking though.
Matt
01/06/2004 (4:32 am)
I didn't read the whole thing but have you managed to get any joints working or is just limited to loose objects like in the video?Very nice looking though.
Matt
#25
I don't see why joints wouldn't work. (apart from the fact you'd need to code them in. Using shape bones as joints might be a good idea - aka ragdolls)
ODE seems simple enough to use... so i'd guess its a matter of saying "put a joint here... connecting to that joint...blabla", then of course figuring out how to interpret all the data you get back.
01/06/2004 (8:05 am)
Matt,I don't see why joints wouldn't work. (apart from the fact you'd need to code them in. Using shape bones as joints might be a good idea - aka ragdolls)
ODE seems simple enough to use... so i'd guess its a matter of saying "put a joint here... connecting to that joint...blabla", then of course figuring out how to interpret all the data you get back.
#26
Wait and see what Pascal says
Matt
01/06/2004 (9:41 am)
Thats why I was wondering if he planned on doing it or not. If we could come to some standard on it I might try to incorperate some modifier or node type into my rewrite of max2dts. So that info could easily be exported.Wait and see what Pascal says
Matt
#27
e.g i could make a physical zone so the gravity was much higher, so any moving boxes would get "sucked" into it upon contact.
01/06/2004 (10:22 am)
One thing that might be a good idea for this ODE item is to take into account torque's own gravity variable, and also the gravityMod variable available on items, players, and vehicles.e.g i could make a physical zone so the gravity was much higher, so any moving boxes would get "sucked" into it upon contact.
#28
As james mentioned its just a matter of connecting the bodies (all contact between objects are actually "joints" in ode that get deleted an recreated each timestep) There's no interface to do that yet but I tooks Dylan's mods and I'm starting on some enhancements, including variable elasticitiy and friction, client only ODE items (so the server doesn't get too bogged down), and ragdolls (check out http://jet.ro/dismount/ for the stair dismount game btw, also made with ODE I believe).
I'm having trouble deciding whether to try to incorporate a bunch of joints in one shapeBase derived object (more work but could be really cool incorporated into max2dts, also easier to implement ragdolls with), or having individual objects connected with scripts (better interaction with other objects like a car door or a swinging chain). I think each way has its advantages, so maybe I'll just try to do one first.
01/06/2004 (7:36 pm)
Matt, As james mentioned its just a matter of connecting the bodies (all contact between objects are actually "joints" in ode that get deleted an recreated each timestep) There's no interface to do that yet but I tooks Dylan's mods and I'm starting on some enhancements, including variable elasticitiy and friction, client only ODE items (so the server doesn't get too bogged down), and ragdolls (check out http://jet.ro/dismount/ for the stair dismount game btw, also made with ODE I believe).
I'm having trouble deciding whether to try to incorporate a bunch of joints in one shapeBase derived object (more work but could be really cool incorporated into max2dts, also easier to implement ragdolls with), or having individual objects connected with scripts (better interaction with other objects like a car door or a swinging chain). I think each way has its advantages, so maybe I'll just try to do one first.
#29
We could easily write custom helper object that could hold several different kinds of properties for the engine to parse out.
We would have to just see where you were taking it.
Feel free to give me holler when you get there.
Matt
01/06/2004 (8:00 pm)
Ya I use ODE all the time with Quest3d. It a part of the standard package. But with it you add the joints via there model editor. I wasn't sure how you would go bout it with TGE. I was just offering if you needed anything like that. We could easily write custom helper object that could hold several different kinds of properties for the engine to parse out.
We would have to just see where you were taking it.
Feel free to give me holler when you get there.
Matt
#30
A) Store the node movement constraints in the shape file.
Good : Prevents things from moving where you don't want them to.
Problem : Not all modellers support this(unless you use confusing dialogs full of numbers), nor can they export such data. Exporters will need to be modified to write this new data. And what about old meshes?
B) Make the user make a simple animation where it cycles betweeen the minimum and maximum movement bounds for a node. If neccesary, this can be an extra step in the exporting process rather than in torque itself.
Good : Modellers only need to make 1 animation. This can be achieved in all modelling tools.
Problem : May become hopelessly confusing.
C) Determine the minimum and maximum constraints for bone movement via the models current animations.
Good : Even easier to handle. Fits in with existing animations.
Problem : If you have no death animations(aka player lying down etc) for the model, then the ode player will have limited ragdoll movements.
It might be fun to have a combination of joints in shapes and joints connecting world items (e.g the tool in half-life 2 that allows you to pick up and throw objects) :)
01/07/2004 (4:16 am)
What i suggest if you are using the shape nodes and having moving constraints is either :A) Store the node movement constraints in the shape file.
Good : Prevents things from moving where you don't want them to.
Problem : Not all modellers support this(unless you use confusing dialogs full of numbers), nor can they export such data. Exporters will need to be modified to write this new data. And what about old meshes?
B) Make the user make a simple animation where it cycles betweeen the minimum and maximum movement bounds for a node. If neccesary, this can be an extra step in the exporting process rather than in torque itself.
Good : Modellers only need to make 1 animation. This can be achieved in all modelling tools.
Problem : May become hopelessly confusing.
C) Determine the minimum and maximum constraints for bone movement via the models current animations.
Good : Even easier to handle. Fits in with existing animations.
Problem : If you have no death animations(aka player lying down etc) for the model, then the ode player will have limited ragdoll movements.
It might be fun to have a combination of joints in shapes and joints connecting world items (e.g the tool in half-life 2 that allows you to pick up and throw objects) :)
#31
A: It might mean a lot more work to get working throughout th e modelling programs. And if ppl with max are happily using ragdoll efefcts with ODE then people with ms3d shouldnt be left out etc.. It would also be better if it was a torque only modification..
B: this actual sounds quite good...
Could be as simple as making an anim for each bone from min to max.
e.g Bip01_Head_ODE_limits.dsq
Bip01_Neck_ODE_Limits.dsq
etc..
C: This sounds like it would have the best results.. as in effect it would be taking exisintg death animations and making them dynamic. So instead of playing the normal death anim, give control of the bones over to ODE and constrain the bones accroding to a selected anim.
Those could be put in a seperate folder to keep them away from standard DSQ anims..
01/07/2004 (4:51 am)
C sounds like the best option.A: It might mean a lot more work to get working throughout th e modelling programs. And if ppl with max are happily using ragdoll efefcts with ODE then people with ms3d shouldnt be left out etc.. It would also be better if it was a torque only modification..
B: this actual sounds quite good...
Could be as simple as making an anim for each bone from min to max.
e.g Bip01_Head_ODE_limits.dsq
Bip01_Neck_ODE_Limits.dsq
etc..
C: This sounds like it would have the best results.. as in effect it would be taking exisintg death animations and making them dynamic. So instead of playing the normal death anim, give control of the bones over to ODE and constrain the bones accroding to a selected anim.
Those could be put in a seperate folder to keep them away from standard DSQ anims..
#32
-Pascal
01/07/2004 (7:16 am)
I think the way to go with this might just be a constraints/joint datablock the can be linked into a ragdoll with a shapefile. This way the information is in a text file (easy to edit) but could also be outputed from the milkshape or max exporters. Could start with an simple in game editor that saves out a .cs file and work from there. James option C (which I think is a great idea) could be implemented as a starting point for the in game and then the user fine tune it (if, for instance your model doesn't have a touch his/her toes animation). Since torque saves objects and datablocks really it wouldn't be that much work.-Pascal
#33
Anyway, I am gonna try to compile it in now, great resource guys!
01/07/2004 (8:17 am)
Are you guys gonna release a multiplayer resource for easy of installation, or some kind of step by step thing on intalling it on here, would love it if some one could post an easy way to install this feature.Anyway, I am gonna try to compile it in now, great resource guys!
#34
I'm doing a cleanup and revamp of the code right now with Dylan's multiplayer, some more config options, and a shot at ragdolls. If I'm lucky I'll try to get it up tonight or tomorrow with some new docs.
-Pascal
01/07/2004 (10:37 am)
Joshua, I'm doing a cleanup and revamp of the code right now with Dylan's multiplayer, some more config options, and a shot at ragdolls. If I'm lucky I'll try to get it up tonight or tomorrow with some new docs.
-Pascal
#35
01/07/2004 (12:13 pm)
Based on the video above, why are my objects so jumpy-choppy when they are in motion?
#36
On a sidenote: how hard would it be to integrate ODE into the Torque vehicle code, e.g. ODEWheeledVehicle?
01/07/2004 (1:12 pm)
My objects were choppy before I applied the MP changes... you may wanna try that if you didnt already...On a sidenote: how hard would it be to integrate ODE into the Torque vehicle code, e.g. ODEWheeledVehicle?
#37
But actualy making the vehicle is pretty simple, its just a bunch of joints of different types.
For flyers, youd have to apply an impulse upwards every step, based on the velocity.
For wheeled vehicles, it could get trickier.
If you wanted to have vehicles, then I think you would almost definitely need some sort of client ODE world for client side prediction in between ticks.
01/07/2004 (7:23 pm)
It would probably require a rewrite of a majority of the vehicle code.. Probably better to start from scratch really, making an ODEVehicle class or something, then extending it to ODEFor flyers, youd have to apply an impulse upwards every step, based on the velocity.
For wheeled vehicles, it could get trickier.
If you wanted to have vehicles, then I think you would almost definitely need some sort of client ODE world for client side prediction in between ticks.
#38
I tried to see what was wrong, but my knowledge of the collision system is pretty limited.
Also, I need a question answered...
01/07/2004 (10:59 pm)
I just noticed that the ODEItems are not colliding with scaled TSStatics (like trees etc) properly... Everything else collides with them properly, ie the player and projectiles, but not the ODEItems.. they seem to fall right through, occasionally hitting the odd collision poly.I tried to see what was wrong, but my knowledge of the collision system is pretty limited.
Also, I need a question answered...
#39
ODEItem uses a different part of mConvex (getCollisionInfo and getFeatures) than almost all of the other Torque code, except for the Vehicle code. I noticed TSStatic's have their own convex subclass. Since everything else is colliding ok with statics, It would lead me to believe that the getFeatures implementation in TSStaticConvex might be the issue. I tried the buggy with some scaled-up statics and I'm getting a weird behavior as well so I think that's where the issue might be. I'll see if I can spot a quick fix.
(I'll post an answer to the rolling question in the other thread)
-Pascal
01/08/2004 (8:57 am)
Dylan, ODEItem uses a different part of mConvex (getCollisionInfo and getFeatures) than almost all of the other Torque code, except for the Vehicle code. I noticed TSStatic's have their own convex subclass. Since everything else is colliding ok with statics, It would lead me to believe that the getFeatures implementation in TSStaticConvex might be the issue. I tried the buggy with some scaled-up statics and I'm getting a weird behavior as well so I think that's where the issue might be. I'll see if I can spot a quick fix.
(I'll post an answer to the rolling question in the other thread)
-Pascal
Torque Owner Pascal
Is the bug reproducible? Did you do a trace?
According to the ODE doc's it can use up a lot of stack, I've never had an overflow but you could try upping the stack size and see if it helps.