ODEItem v0.10

#101 That's cool Clint :).
I scrapped this because of that very reason !

Thanks alot.

#102 very welcome!

There are still a few other problems I'll be looking into later today. I really want to use this, so I hope we can get them worked out.

1. objects sitting in their steady state occasionally randomly rotate for a split second, then go back to the proper rotation.
2. objects in their steady state ocasionally vibrate for no reason.
3. after adding more than a small number of odeitems, the entire system crawls to an almost standstill, about 1 frame every 4 seconds or so, something is obviously looping way too much :)
4. collision of odeItems and player, not handled the way I would like them, I would really like them to be handled properly with friction being applied to the player also. so that you could say, stand on an ode object that was sliding down hill and you would slide as well as the object.

If anyone else has done any work on these issues, please let us know. I'll post here with any other fixes/improvements I find.

note: I am using the ODE release 0.5

#103 I'll just do this free flow as I fix things..
in ODEItem::onAdd()

there is the following call:
dGeomSetBody (this->getId(), mBodyID);

this is unecessary (at least with ode 0.5 ) because we are basically implimenting our own geometry system, and only using ode to work with teh bodies. as long as you set mBodyID to be the body you create (as is already done) you don't need to make that call.

also in ode 0.5, you have to make your own dGeomSetBody function if you will be doing your own collision detection as we are with this resource, I dont' think this was necessary before. This involves commenting out the implimentation of the function in the ode library source, and writing your own version of the function. Here is what I'm using:

void dGeomSetBody (dGeomID id, dBodyID bodyID)
{
	//from ODE documentation
	//  This function is called in the body destructor code 
	//  (with the second argument set to 0) to remove all 
	//  references from the geom to the body.

	ODEItem *obj = dynamic_cast<ODEItem*>(Sim::findObject(id));
	if(obj) {
		obj->setBodyID(bodyID);
	}
}

also:
mWorkingQueryBox is not used in ODEItem currently, so it looks like you can remove any reference to that in the ODEItem stuff if you want.

#104 updateMove is currently only called from
dGeomMoved, which in turn is only called when a body that is attached to another body is moved, so if you are only going to have a single sphere/ box type of body per ode item, then you can get rid of the updateMove code


I am doing so, and I am changing dGeomMoved to look like this

void dGeomMoved (dGeomID id) {
	ODEItem *obj = dynamic_cast<ODEItem*>(Sim::findObject(id));
	if(obj) {
		Con::errorf("Attempting to move ode body, is there an attached ode body? ode object id: %d",obj->getId());
		return;
	}
}

#105 I got it to build, but:

==>createODEItem();
Object 'ODEBox' is not a member of the 'GameBaseData' data block class
starter.fps/server/scripts/ODEItem.cs (27): Register object failed for object (null) of class ODEItem.
==>createODECan();
Object 'ODECan' is not a member of the 'GameBaseData' data block class
starter.fps/server/scripts/ODEItem.cs (0): Register object failed for object (null) of class ODEItem.

I've not idea what that means, but it happens when I type those two lines into the console.

Gary (-;

#106 This resource is awesome, I've been fiddling with it for the last few days. A couple things that need to be tweaked-

To make the projectiles collide with the ODEItems, add in projectile.cc where it says,

const U32 Projectile::csmStaticCollisionMask = TerrainObjectType |
InteriorObjectType |
StaticObjectType;
change it to look like this.:

const U32 Projectile::csmStaticCollisionMask = TerrainObjectType |
InteriorObjectType |
StaticObjectType |
ODEObjectType;

If your ODE's are invisible until you bump them, make sure that you add to the datablock "enabled=1", it defaults to "0" for some reason.

Also, because in ODE, a typical mass seems to be one or less, as opposed to torque, which does it in hundreds, if you added the applyimpulse from above, you probably need to reduce the force, which is easy:

Change:
dBodyAddForceAtRelPos(mBodyID,vec.x,vec.y,vec.z,pos.x,pos.y,pos.z);

To:

dBodyAddForceAtRelPos(mBodyID,(vec.x)/4500,(vec.y)/4500,(vec.z)/4500,pos.x,pos.y,pos.z);

you can fiddle with the 4500, it isn't really based on anything.

Also, If you want the mass to be in the datablock for changing, first, back up your ODEItem and ODEWorld files, go through ODEItem.h and .cc, and ODEWorld.h and .cc and find all of the places that have the four datablock variables, friction1, friction2, bounceVel, and bounce, and add in a duplicate for mass, ie:

if(mOverride = stream->readFlag()) {
stream->read(&mFriction1);
stream->read(&mFriction2);
stream->read(&mBounceVel);
stream->read(&mBounce);
}

becomes:

if(mOverride = stream->readFlag()) {
stream->read(&mFriction1);
stream->read(&mFriction2);
stream->read(&mBounceVel);
stream->read(&mBounce);
stream->read(&mMass);
}

or for:

addField("DatablockOverride", TypeBool, Offset(mOverride, ODEItem));
addField("friction1", TypeF32, Offset(mFriction1, ODEItem));
addField("friction2", TypeF32, Offset(mFriction2, ODEItem));
addField("bounce", TypeF32, Offset(mBounce, ODEItem));
addField("bounceVel", TypeF32, Offset(mBounceVel, ODEItem));

add:

addField("mass", TypeF32, Offset(mMass, ODEItem));


Other than that, you need to do two things:

in ODEItem.h, in ODEItem: public ShapeBase, find where it says

bool mIsEnabled; // is the body currently disabled
bool mDisableNow;


// ODE vars
dMass mMass;

either comment out or delete the "dMass mMass" line, and in ODEItem.cc, where it says:

if(isServerObject()) {
dMassSetBox (&mMass,1,mObjBox.len_x(),mObjBox.len_y(),mObjBox.len_z());
dMassAdjust (&mMass,1.0);

mBodyID = dBodyCreate (gWorld);
dGeomSetBody (this->getId(), mBodyID);
//dBodySetAutoDisableSF1(mBodyID,true);

dBodySetMass (mBodyID,&mMass);

Change it to:

if(isServerObject()) {
dMass m;
dMassSetBox (&m,1,mObjBox.len_x(),mObjBox.len_y(),mObjBox.len_z());
dMassAdjust (&m, mMass/1000);

mBodyID = dBodyCreate (gWorld);
dGeomSetBody (this->getId(), mBodyID);
//dBodySetAutoDisableSF1(mBodyID,true);

dBodySetMass (mBodyID,&m);

The /1000 from above is also a bit of an arbitrary number, you can fiddle with it, but only leave it in if you want to put in Torque-like masses, like 500. With out it , the kinds of masses would have to be like 0.5.

I think that clears up some of the major problems. Here are some other issues:

ODEItems do not appear in the mission editor- This is probably easy to fix, and it's not so big a problem anyway because you can manually put them in by editing the .mis file. You could even put in a static placeholder and swap it later.

Do the joints work in Torque yet? I haven't tried anything with them, but what happened to the ragdoll idea from above? Has anything happened with that?

If I missed something or got something wrong, I wouldn't be too surprised, but if you backed up your files it should be no harm done, but please post if I've done something wrong.

#107 @ Jeff great work. As far as I know no one has pursued adding ragdoll behavior to Torque. Atleast not in public.

#108 1. contactBodies, curContact, contacts do not need to be stored. saves 7k per class.
2. all collisions are done twice when calculating contacts. only one contact is needed for two bodies. an actually check is made, see dAreConnected, but it can be made much sooner. this saves a lot of time since the convex stuff appears to be pretty slow.
3. mBodyID is only valid on the server, so no client code should actually use it. you can see ode calls are made in ::unpackUpdate which makes no sense.
4. ::updateWorkingCollisionSet calculates a bound box that is expanded in every direction by its velocity. this should only be expanded in the direction of velocity to create a smaller bound box.
5. _isnan is not available on linux and something else should be used.
6. trace into Convex::getCollisionInfo, there are lots of easy/obvious optimizations. this seems to be where the most time is spent when there are lots of odeitems touching each other.

#109 Cameron, how is ode working with tge for you currently? I gave up because of quite a bit of jittering and jumping the odeitems were doing even when sitting still. Had to make the decision that it wasn't absolutley necessary for my game right now, but would love to have it in. Maybe you could post your code as an updated resource if you have things working smoothly?

#110 Is there any chance that this resource will be updated to reflect all the changes and fixes mentioned herein?

If anyone out there has ODEItem working properly, maybe they could post a new resource that's a follow-up to this one?

I've got a project written using ODE using aalib for input and output, that I want to make work in Torque - But every time I've tried to implement this resource in the 1.3 source tree [linux], I come up against some showstopping problem or another.

Thank-you very much,
Gary (-;

#111 Hey All,

I'm sorry I've been pretty far far away from torque development for a while,
if anyone wants to take over the resource and submit a new version I'll
edit the comment on the top to link to that new resource.

-Pascal

#112 @ Jeff
I remember from when I was playing with ODEItem that you can also do collision the other way and it will actually make things a bit easier with projectile collision and radius damage. Instead of adding a collision mask to the projectile (possibly messing up core code) you can also add a mask to the ODE item mask. DamagableObjectType should be the thing to do it.

Note: I would love to come back to this but looking at it in detail with the ODE information (as well as with the newest versions of ODE) makes me think it needs a pretty big overhaul. Item meshes need to be loaded with ODE in mind in order to get the full abilities of the actual physics that ODE can use. This includes joints and other such information. On top of that, it needs a simpler way to translate information from ODE to Torque and back. The best way to get realistic physics taking full advantage of ODE seams to be with ODE doing as much of the physics as possible, translating that to torque for collision, and then sending that back to ODE over the next frame.

Unfortunately, that doesn't solve that pass through problem that's evident on the Vehicles, and on ODEItems if you play with them extensively.

Anyone have any ideas on this?

#113 Clint, there's a number of things you can do to help the jitter problem:

1) remove anything in the odeitem that has to do with disabling the body and start using the dBodySetAutoDisable* functions instead.
2) you'll need to play with the values a bit depending on what you need. here's what i use right now ( not the best but better )

dBodySetAutoDisableFlag ( mBodyID, true );
dBodySetAutoDisableLinearThreshold ( mBodyID, 0.35f );
dBodySetAutoDisableAngularThreshold ( mBodyID, 0.35f );
dBodySetAutoDisableSteps ( mBodyID, 10 );

3) get friction to work!! remove all the friction1 and friction2 stuff. just use one friction value per material and make sure they are actually doing something. this is very important to slowing the objects down and making them stick. otherwise they'll tend to 'slide' or jitter on themselves forever.

4) other things you could try is looking at the type of contacts that are being created while they are jittering. for example, contacts are being created regardless of the value of col->distance. what if col->distance is something really small or 0. maybe culling these out or adding small contacts into one large contact may help?!


I wouldn't waste too much more time on trying to decipher or fix this resource. i think it would have been more time effective to start with a simple network object class and the ode doc's. there are some really fundamental things broken with this class that would be easier fixed with a fresh start. i'm not sure if anyone has noticed that objects tend to be kind of 'jumpy' when there is a lot of stuff happening, it looks like they kind of stop in mid air and then continue again. this is due to there being no client side prediction. if you look for a comment like '//Set The transform from ODE.' the if statement deals with the server the else deals with a client that isn't warping. meaning a client that is caught up to the server and hasn't received an update. you can see by the code instead of predicting it just sets the current position and rotation effectively freezing it until it receives an update from the server.

anyhow enough ranting, i'm still going to continue to use ode i'm just going to integrate it a little differently.

#114 Thanks for the long explanation Cameron,
I had removed the dissabling code, and I had 'fixed' the friction already.
Thinking over it again and with your description about the client side prediction I suppose what could have been happening is that things were jittering a little chaoticly on the server but I just wasn't seeing it on the client until it would all of a sudden explode.

I think your suggestions of using ode's auto dissabling and handling tiny collisions would help. but I'm not going to get to try it anytime soon. thanks again.

#115 still no luck getting this in.
I cant seem to get any physics engine added(tried Newton as well, no luck adding that either)
im getting the same 35 linker errors as before.
its like its ignoring the lib files or summit of the sort.
ive got it pointing to the right place i know, so im completely confused here.

any ideas?

#116 @Cameron: Have you made any headway on newer version of this resource?

#117 It would be really nice to have the most up to date code. Can someone host the files, or maybe repost it as a new resource so you can upload or something ?

Or send them to Pascal, so he can bring his version up to recent (if its not already)

#118 Wow, this would be so cool. Two things though:

1) I wish someone would please submit their new code with all the changes above, and the newest version of ODE (currently 0.5)... Please...

2) Does anyone know if this works with TSE. I've moved past TGE and would like to know if it's worth my time to try implementing in TSE.

If I have the time maybe I'll try to do the above.

#119 I really need to be be able to move the ODE objects around using some set position call or something...Ive written a console version of the ODEItem:setPosition function...but the crate wont budge....Also is there a way to specify force impulses on these things?..

#120 www.garagegames.com/mg/forums/result.thread.php?qt=30283
I've been working on a slightly different way of doing the whole ODEItem thing. There's a small video in my .plan here: www.garagegames.com/blogs/20342/8256

Gary (-;