Ode 0.9 is out! Anyone tried it?

Well, just what it says - ODE has improved a lot since 0.8 (especially I like the trimesh improvements and sleep functions). Has anyone had any luck with it?
I shall try it out tonight (using the version of OgreOde from CVS) and post the results here.

lookin forward

well, first results:

1) was dead easy to use it instead of 0.8 No problems whatsoever.
2) checked demos, check in my own app, all works fine.
3) ODE indeed has improved significatly over the past months, so it is probably a must for everyone to upgrade (soon more changes are expected to come)

P.S. Now tested both with debug and release versions. So, if anyone is interested, I can upload precompiled .lib and .dll libraries. Also, surely OgreOde itself needs some facelift. Is anyone still actually working with it or is it a sort of left-to-die at the moment?

No active maintainer, but patch welcome and new maintainer welcomed.

No active maintainer

Hmm, that's sad. Must admit ODE seems to be a perfect companion to Ogre

but patch welcome

You mean to the CVS? Guess, I could that, integrating ode 0.9 and doing a few improvements here and there... However, what is the stage of develepment at this point? I mean, like what's done, what needs to be done? And, err, secondly, how do you use CVS?

I haven't kept up to date with OgreODE, but has anybody been successful with character collisions and sliding?

I played around with OgreODE a looong time ago, and the character controller class was horrible. It consisted of a capsule on top of a sphere, and trying to apply and cancel out forces, to move the character around. Does anybody use physics in games that don't involve wheels?

2 kungfoomasta
Yep, there are several other models 4 u 2 use. For instance, a raycast model with multiple geometries for head, body, arms, etc. Or you can use more "proper" models with legs and feet simulations. Finally, no need to use A wheel, use 2 wheels

ODE 0.9 gives me problem with landscape, seems my all my code to heightfield collision has been corrupted...

@Aquatix: did you test demo_landscape ? no problem ?

@kungfoomasta: indeed OgreOde lacks some Character Controller physics, but Character Collision works well. (and its consequence ragdoll, but that one needs lots of tweaks to work.) What's sliding ?

If you walk into a wall/fence/rail at an angle, you collide with the wall, and then start sliding along the wall. I've read 2 papers on how to do it, but I'm not great with collision handling, and found it difficult to achieve. You have to use normals to determin a sliding plane and then push the object along the sliding plane. Also consider cases with corners.

@tuan kuranes Both yes and no. It works pretty well, but certain weird errors are appearing here and there... Managed to fix most of them, but will need extra couple of days.
Also, currently the code of OgreOde is quite tied up with the Ogre's FrameListeners. I am just wondering, do you think it would be better, if the code be rewritten to have a separate (update) action, so as to support apps with a separate do...while loop?

@kungfoomasta As I see it, OgreOde does not intent to actually have a Character Class in it (unless I miss something). If you use a model+ray version, it all works like a charm. Here's how you do it (that's some code I used in my app, but now it changed a bit, but the new is a bit unstable):


GameObjectManager *npcGameObjMgr;
npcGameObjMgr = GameObjectManager::getSingletonPtr();
Ogre::Vector3 loAAB;
BaseEntity = npcGameObjMgr->mSceneMgr->createEntity(npcName,MeshName);
loAAB = BaseEntity->getBoundingBox().getSize();
BaseNode = npcGameObjMgr->mSceneMgr->getRootSceneNode()->createChildSceneNode(npcName,Ogre::Vector3(locx,locy,locz));
BaseEntNode = BaseNode->createChildSceneNode(npcName+"entnd",Ogre::Vector3(0,-abs(loAAB.y/2+0.15-0.15),0));
BaseEntNode->attachObject(BaseEntity);
SkHeadNode = BaseNode->createChildSceneNode(Ogre::Vector3(1,1,1));
BaseSpace = new OgreOde::SimpleSpace(npcGameObjMgr->mpWorld,npcGameObjMgr->mpSpace);
BaseSpace->setInternalCollisions(false);
BaseBody = new OgreOde::Body(npcGameObjMgr->mpWorld);
BaseNode->attachObject(BaseBody);
BaseBody->setMass(OgreOde::BoxMass(90,Ogre::Vector3(abs(loAAB.x)/2,abs(loAAB.y)/2,abs(loAAB.z)/2)));
BaseBody->setOrientation(orintQuat);
SkBody = new OgreOde::BoxGeometry(Ogre::Vector3(0.5,abs(loAAB.y)-0.37-0.3,abs(loAAB.z))-0.02,npcGameObjMgr->mpWorld,BaseSpace);
SkBody->setBody(BaseBody);
SkHead = new OgreOde::BoxGeometry(Ogre::Vector3(0.18,0.27,0.23),npcGameObjMgr->mpWorld); //убрал BaseSpace
SkHeadTr = new OgreOde::TransformGeometry(npcGameObjMgr->mpWorld,BaseSpace);
SkHead->setPosition(Ogre::Vector3(0,abs(loAAB.y/2-0.2),-0.02));
SkHeadTr->setEncapsulatedGeometry(SkHead);
SkHeadTr->setBody(BaseBody);
BaseRay = new OgreOde::RayGeometry(0.9-0.15,npcGameObjMgr->mpWorld,BaseSpace);


This gives you a character model with a body and a head on a ray. It can do walking/running/sliding and the rest of them nice things. Just don't forget your (update) method.


int collideSuccess = 0;
GameObjectManager *npcGameObjMgr = GameObjectManager::getSingletonPtr();
std::map<std::string, TerrainObject*>::iterator itTerrains;
std::map<std::string, TerrainObject*>::iterator itTerrainsEnd;
itTerrains = npcGameObjMgr->mTerrainObjects.begin();
itTerrainsEnd = npcGameObjMgr->mTerrainObjects.end();
BaseBody->setDamping(10,10);
BaseRay->setDefinition(BaseNode->getPosition()+Ogre::Vector3(0,-0.15,0),Ogre::Vector3::NEGATIVE_UNIT_Y);
for (; itTerrains != itTerrainsEnd; ++itTerrains) {
if (BaseRay->collide(itTerrains->second->TerrainGeom,npcGameObjMgr)) { collideSuccess = 1;}
}
if (collideSuccess == 1) {
_isGround = true;
BaseBody->wake();
BaseBody->setPosition(npcGameObjMgr->mpContact->getPosition()+Ogre::Vector3(0,1.05-0.15,0));
BaseBody->setAngularVelocity(Ogre::Vector3(0,0,0));
BaseBody->setLinearVelocity(BaseBody->getLinearVelocity()*Ogre::Vector3(1,0,1));
}
if (_isGround == true) {
BaseBody->setOrientation(Ogre::Quaternion(BaseBody->getOrientation().xAxis(),Ogre::Vector3::UNIT_Y,BaseBody->getOrientation().zAxis()));
_isGround = false;
}


can you give some additional information on how you move the character? and why are you using an extra geometry for the head?

landscape crashed on me to Tuan ... I get a

Demo OgreOde Landscape has exited due to signal 10 (SIGBUS).

Aquatix are you planning to add the new joint "Prismic-something or other" in your patch? And also BallJoint can have some parameters set on it now I think, be nice to have the new bits ;p

Cloud will prolly try and add them in if your not.

Sorry for the late response, and thanks for posting that code Aquatix. I haven't used ODE in a while, but my team has decided to go with OgreODE.

I'd also be interested in your movement code. Why did you choose a box shape/body and not a capsule one? Have you implemented jumping as well? (gravity)

Hi everyone, sorry for not responding for a while, been too busy these days.

1) Landscape demo - cloud, this is actually strange that you are getting this error. Tried it again myself, but everything seems to be working fine. Are you using the version from the CVS?

2) Character physics - the project I use ODE for is an RPG, so the kind of model implemented is meant to be just like in FPS, etc. The features so far are movement (both walking and running, different speed as you are going uphill or downhill, slower in water or sand, faster on asphalt, etc.), jumping, crouching, fall damage, etc, etc. Later on today (hopefully) I will try to put up all the necessary coding.
Just going a bit ahead of myself - I use box (not capsule) because the overall character body is made like a ragdoll (sort of - that is a geometry for the head, a geom for body, for legs, for arms). This makes it possible to implement such nice things like doing damage to specific parts of the body only.

3) Cloud, to be honest, I didn't yet have a chance to look at the joints yet. All I know for sure, is that still sometimes they may be a bit buggy, so I try to minimise the use of them. However, after about a week or so, I will try to update them, but if you have time to do that before, that would be great!

4) 2 everyone: how do you use OgreOde in your project in terms of its stepper? Do you use the FrameListener's FrameStarted and FrameEnded, or do you directly put step() and synchronise() in your loop? Also, which stepHandler do you prefer and with what settings?
The reason for asking is that I think right now OgreOde is offering perhaps too many choices for the steppers/step_methods, etc. And, perhaps, it would be to a benefit for all, if the choices be reduced, but made more suitable for particular situations (say a Stepper for FPS/Action game, a Stepper for Racing, a Stepper for SimpleSimulations/Collisions only)

Wow, I'm glad to hear you've accomplished so much in terms of the character movement/collision handling!

This is asking much, but it would be great to have a minimal demo of the ninja walking on the default terrain.cfg, and with some objects to show sliding. If you give me code to work with, I can try to make the demo myself. It's been a while since playing with ODE, but people really need an easy solution to character movement. It's in high demand, but a lot of libraries don't easily support it.

Can't comment on the stepper, sorry..

Hmm it could be my OS X setup... Simple Scenes is working fine and all, I'll have a look more closely when I can find time and will.

I've done the new joint "prismatic and rotoide" which I called it SliderHingeJoint, haven't properly tested it yet and added BallJoint bit. Theres another joint an LMotor, not looked into that just saw it in ode's enum's.

I meself use the ForwardFixedStepHandler with StepHandler::QuickStep, stepperSetup(2,2) if you use that. Along with my StepListener class I have a addChildListener so I can make any other class thats a stepListener be called by the StepListener, I write all the update code in prestep()'s. Basically copied the idea of GOOF's InputListener for cascading events. Actually it might be nice to add a addChildListener and removeChildListener to StepListener.

ok here my 2 cents on the stepper:

I am programming on a 3rd person action rpg and I use the ExactVariableStepListener with StepHandler::Quickstep and a fixed timestep of 20 ms each. To decrease the count of clipping errors, I changed the value of computation iterations using World::setQuickStepIterations(). I currently use 10 iterations, but I remember that I tried values up to 200. Results are getting better to the cost of performance of course, though I still am not completely satisfied with the simulation, there still appear to be clipping errors here and there. Would be interested in different experiences.

@Aquatix: Did you try the character model that is described in the wiki? I use it and it would be nice to know about the advantages of your concept over that one. (over or what preposition in this case?)

rewb0rn, are you referring to the older wiki article about the capsule on top of a sphere? I tried that method a long time ago, and it was pretty horrible (at that time). Sometimes the capsule/sphere would fall over, or bounce rapidly back and forth, and when I ran up or down sloped ground, the sphere at the bottom would store momentum, and alter the movement of the character (either against the direction I wanted to go, or with it.. and at varying speeds). Standing on sloped ground would make the sphere start rolling down it.. I tried sleeping and waking the character when going on hills, but that didn't work. (when you wake it up it still has some forces built up, I couldn't cancel them out)

Are you using the capsule over sphere method? How does that work for you?

it works acceptable. i reduced the unintended movement on hills by adding more fraction, still its not perfect and besides the character is able to walk up every slope up to 90°, havnt found a way to change that yet.
here is a video of my character, i have already posted it somewhere here in the forums some months ago..
http://www.youtube.com/watch?v=pobMWENwcQg

So, here's my 2 cents on the character model:

First, some theory: so far, there have been 3 major types of physics modelling of a moving character - Ray Model (1), Driving Model (2, aka miniCar), Realistic Model (3).
They are VERY different in approach, but all aim to do the same thing - deliver the most easy to use and yet powerfull model of a moving character. Surely, no doubts, model 3 is by far most advanced and realistic model - that is when a character is given legs with all the properly setup joints, and proper movement (I thinks, I've seen a spider simulation here on the forums, using Newton - well this is what I'm talking about). Advantages - realism, Realism and REALISM However, it is very complicated to use, and needs to be debugged a lot. Plus, no machine is going to give you more than 1-2 fps if you have, say 50 of such models at a time. So, quite impractial for games (well, with our level of technology at least.
Models 1 and 2 have emerged round about the same time, so if you play games, then surely you have seen both of them in action. Which one is better? Well, that's for you to decide. I am not going to say that one is 100% better than the other, all I would say surely, is that RayModel is more complicated, than the miniCar (or spere-at-the-bottom or whatever else you'd like to call it), yet it does have several advantages:
- No troubles with the joint
- Precise control over speed, no "drifting'
- Proper strafing (no wonder most shooters use it, e.g. Unreal)
- Easy control of the surface you are on (thus making sounds, varying speed, etc.)
- No jumping about, if rolling over small objects
Actually, just was looking at wiki again, and seen, that the models 1 and 2 have been kinda described there (but BEWARE, checked both articles, and they are out of date, and have too many troubles/bugs/lack of features with them...)

So, all that said, lets go into coding (sry, kungfoomasta, but I couldn't make a proper demo YET, since it prooved to be not an easy task to take out the necessary code from my app ):
NOTE: the models I use for Player and NPC are slightly different (i.e. Player is a bit more advanced, so below is the model for the Player)

First, some variables (would go in your Player.h):

Ogre::Entity *pBaseEntity; //Your Player.mesh
Ogre::SceneNode *pBaseNode;
Ogre::SceneNode *pBaseModelNode;

OgreOde::Space *pPhysicsCharSpace;
OgreOde::Body *pBaseBody;
OgreOde::Geometry *pGeomBaseBody;
OgreOde::TransformGeometry *pGeomBody;

OgreOde::Geometry *pGeomBaseHead; //Use this for things like head shots, etc. Surely, you can add arms, legs, whatever you need
OgreOde::TransformGeometry *pGeomHead;
OgreOde::Body *pHeadBody;

OgreOde::RayGeometry *pBaseRay;


Now, below is what you do for constructing the player (maybe in Player::initialise() )


pPhysicsCharSpace = new OgreOde::SimpleSpace(pGameObjMgr->mpWorld,pGameObjMgr->mpSpace);
pPhysicsCharSpace->setInternalCollisions(false);
pBaseRay = new OgreOde::RayGeometry(0.90,pGameObjMgr->mpWorld,pPhysicsCharSpace);

pBaseEntity = pGameObjMgr->mSceneMgr->createEntity("PlayerBaseModel","PlayerBase.mesh");

pBaseNode = pGameObjMgr->mSceneMgr->getRootSceneNode()->createChildSceneNode("Player1");
pBaseModelNode = pBaseNode->createChildSceneNode(Ogre::Vector3(0,-1.05,0));
pBaseModelNode->attachObject(pBaseEntity);

pBaseBody = new OgreOde::Body(pGameObjMgr->mpWorld);
pBaseBody->setMass(OgreOde::BoxMass(75,Ogre::Vector3(0.25,0.75,0.15)));
pBaseBody->setAutoSleep(false);
pGeomBaseBody = new OgreOde::BoxGeometry(Ogre::Vector3(0.42,0.7,0.30),pGameObjMgr->mpWorld);
pGeomBody = new OgreOde::TransformGeometry(pGameObjMgr->mpWorld,pPhysicsCharSpace);
pGeomBaseBody->setPosition(Ogre::Vector3(0,0.35,0));
pGeomBody->setEncapsulatedGeometry(pGeomBaseBody);
pGeomBody->setBody(pBaseBody);

pGeomBaseHead = new OgreOde::BoxGeometry(Ogre::Vector3(0.18,0.27,0.23),pGameObjMgr->mpWorld);
pGeomHead = new OgreOde::TransformGeometry(pGameObjMgr->mpWorld,pPhysicsCharSpace);
pGeomBaseHead->setPosition(Ogre::Vector3(0,0.62,0));
pGeomHead->setEncapsulatedGeometry(pGeomBaseHead);
pGeomHead->setBody(pBaseBody);

pBaseNode->attachObject(pBaseBody);


I do hope, all above is pretty self-explanatory. Just some notes:
pGameObjMgr - is my custom class, which kinda manages all the game objects. Basically, you do not need it at all, I just use it here, as a pointer to my current SceneManager, and the global pWorld (i.e. ODE::World), and pSpace (i.e. the default space, that comes with the ODE::World).
NOTE the units - 1 Ogre unit = 1 meter. Character height = 1.8 meter. Finally, Mass is in Kilograms, Speed - m/s (that's meters, NOT miles )

Now, that we have this, lets go to a more complicated part - out update() methods (which gets called every frame).

Also, declare a Ogre::Real pCharAbsHeight in Player.h

Ogre::Vector3 posVect;
Ogre::Real dataTemp1, charAbsHeight;
OgreOde::Contact *tempContact;
int collideSuccess = 0;

std::map<std::string, TerrainObject*>::iterator itTerrains;
std::map<std::string, TerrainObject*>::iterator itTerrainsEnd;
std::map <std::string, WalkableObject*>::iterator itWalkables;
std::map <std::string, WalkableObject*>::iterator itWalkablesEnd;
itTerrains = pGameObjMgr->mTerrainObjects.begin();
itTerrainsEnd = pGameObjMgr->mTerrainObjects.end();
itWalkables = pGameObjMgr->mWalkableObjects.begin();
itWalkablesEnd = pGameObjMgr->mWalkableObjects.end();

charAbsHeight = pCharAbsHeight;
pCharAbsHeight = pBaseBody->getPosition().y;

pBaseRay->setDefinition(pBaseNode->getPosition()+Ogre::Vector3(0,-0.15,0),Ogre::Vector3::NEGATIVE_UNIT_Y);
for (; itTerrains != itTerrainsEnd; ++itTerrains) {
if (pBaseRay->collide(itTerrains->second->TerrainGeom,pGameObjMgr)) { collideSuccess = 1;}
}
for (; itWalkables != itWalkablesEnd; ++itWalkables) {
if (pBaseRay->collide(itWalkables->second->BaseGeom,pGameObjMgr)) { collideSuccess = 1;}
}

if (collideSuccess == 1) {
if (p_JumpRequest == 0) {
p_isCharGround = true;
pBaseBody->wake();
tempContact = pGameObjMgr->mpContact;
posVect = tempContact->getNormal();
pBaseBody->setPosition(tempContact->getPosition()+Ogre::Vector3(0,1.05,0));
dataTemp1 = Ogre::Math::ACos(posVect.dotProduct(Ogre::Vector3::UNIT_Y)).valueDegrees();
pBaseBody->setAngularVelocity(Ogre::Vector3(0,0,0));
pBaseBody->setLinearVelocity(pBaseBody->getLinearVelocity()*Ogre::Vector3(1,0,1));
}
if (p_JumpRequest == 1) {

Ogre::Vector3 JumpPowerV, JumpPowerVF;

JumpPowerV = Ogre::Vector3(pBaseBody->getLinearVelocity().x/2,pCharJumpHeight,pBaseBody->getLinearVelocity().z/2);
JumpPowerVF = pBaseBody->getOrientation()*Ogre::Vector3(p_MoveSideways/8 * pCharJumpHeight,0,p_MoveForward/10 * pCharJumpHeight);
pBaseBody->setLinearVelocity(JumpPowerVF + JumpPowerV);

p_JumpRequest = 0;
p_isCharGround = false;
}
}

if (p_isCharGround == true) {
if (dataTemp1 == 0) pCharSpeedZ = pCharSpeed*p_MoveForward/10;
else {if (pCharAbsHeight > charAbsHeight)
{if (dataTemp1 > 0 && dataTemp1 < 60) pCharSpeedZ = pCharSpeed*p_MoveForward/30*(1-dataTemp1/90);
if (dataTemp1 >= 60) pCharSpeedZ = 0.001*p_MoveForward;}
else {pCharSpeedZ = pCharSpeed*p_MoveForward/10 * dataTemp1/90;} }

if (dataTemp1 == 0) pCharSpeedX = pCharSpeed*p_MoveSideways/10;
else {if (pCharAbsHeight > charAbsHeight)
{if (dataTemp1 > 0 && dataTemp1 < 60) pCharSpeedX = pCharSpeed*p_MoveSideways/30*(1-dataTemp1/90);
if (dataTemp1 >= 60) pCharSpeedX = 0.001*p_MoveSideways;}
else {pCharSpeedX = pCharSpeed*p_MoveSideways/10 * dataTemp1/90;} }

pBaseBody->setLinearVelocity(pBaseBody->getOrientation()*Ogre::Vector3(pCharSpeedX,0,pCharSpeedZ));
p_isCharGround = false;
}
pBaseBody->setAngularVelocity(Ogre::Vector3::ZERO);
pBaseBody->setOrientation(Ogre::Quaternion(pBaseBody->getOrientation().xAxis(),Ogre::Vector3::UNIT_Y,pBaseBody->getOrientation().zAxis()));


Hope that was pretty self-explanatory (I'm not too good at writing tutorials ).
Next, put this in your OIS::ButtonPressed:

case OIS::KC_W:
gPlayer->p_MoveForward = 10;
gPlayer->p_isCharMoving=true;
break;
case OIS::KC_S:
gPlayer->p_MoveForward = -5;
gPlayer->p_isCharMoving=true;
break;
case OIS::KC_A:
gPlayer->p_MoveSideways = 8;
gPlayer->p_isCharMoving=true;
break;
case OIS::KC_D:
gPlayer->p_MoveSideways = -8;
gPlayer->p_isCharMoving=true;
break;
case OIS::KC_SPACE:
gPlayer->p_JumpRequest = 1;
break;


This all should give you a properly moving/jumping character, that goes uphill/downhill, strafes, etc. and does this in a kinda realistic manner. As far as running and crouching goes, then I'll post that later, cause right now this code directly depends upon my particular RPG system (so need to make it more abstract).
Hope that helps in a way.

@rewb0rn:

Thanks for the video link! I didn't see him running over sloped ground or sliding along walls, does he support this?

@Aquatix:

Thanks for the code and information! As far as explanations go, the code is more readable than other code I've seen, so it wouldn't be too hard to figure out, especially if I wrote code using yours as reference. You should also have something for when the keys are released, right? Does your code handle sliding along objects? I know I must sound crazy, but if you don't have sliding, the character movement won't feel normal, when running next to rails, walls, crates, etc.

@kungfoomasta

Yep, here's what goes to the release button

case OIS::KC_W:
gPlayer->p_MoveForward = 0;
gPlayer->p_isCharMoving=false;
break;
case OIS::KC_S:
gPlayer->p_MoveForward = 0;
gPlayer->p_isCharMoving=false;
break;
case OIS::KC_A:
gPlayer->p_MoveSideways = 0;
gPlayer->p_isCharMoving=false;
break;
case OIS::KC_D:
gPlayer->p_MoveSideways = 0;
gPlayer->p_isCharMoving=false;
break;
case OIS::KC_SPACE:
gPlayer->p_JumpRequest = 0;
break;


If I understand correctly what you mean by sliding, than yes, the code above does support that.

@cloud9 (or anyone else as it matters)

I was trying to get into the latest ODE's API changes, but it just seems to be as if the guys are working on a flippin top-secret-nuclear-science project. I mean, there's no forum, no pregenerated API, no comments in the headers, no changelog, the manual and wiki are both way outdated. And that mailing list also seems to be very little of use.
So, has anyone seen a way to get some update on the latest changes?

@tuan kuranes

Was just wondering - is there a particular reason you've moved away from Ode? As I've seen you are currently working with Bullet (am I right?) Just wondering, if there is anything particulary better in Bullet than in Ode? (well, kinda late for me to ask now, but still being just curious )

@aquatix : Ode is not lacking a real developer, not just maintainer, ending in heterogeneous code.
Bullet is done a by a game physic pro, multithreaded, better design, under active coding, faster, active forum&support, and more features (convex decomposition, ccd), and even more are arriving.

That said OgreBullet still is behind OgreOde in terms of outofthebox features (vehicles, raggdolls, explosion)

That said OgreBullet still is behind OgreOde in terms of outofthebox features (vehicles, raggdolls, explosion)
Ahh, that's not really a determining factor, IMHO. They can always be added on if necessary. Besides, doubt anyone, who uses OgreOde used the Prefabs in a raw state - they propobably built custom classes based on them.

Hmm, OgreBullet seems to be a good idea to try out, but the CVS demo doesn't work . Well, must keep trying

OgreBullet seems to be a good idea to try out, but the CVS demo doesn't work
Problem is, Dev is making at least a release a week over there... have to keep CVS compliant..

Problem is, Dev is making at least a release a week over there...
Well, I'd probobably say it ain't a problem, but an avantage rather )

Yeah, and thanks again for that hotfix, can play aroung with the lib now!

Just a heads up on Bullet, it does indeed look promising, but there is no current character controller. I was going to try to figure this out, but I have too many things on my plate. If you (or anybody!) get it working, please share it and let us know! It seems like everybody who implements a great character collision class decides not to share it. If its a documentation or preparation issue, just give us a code dump instead.

It seems like everybody who implements a great character collision class decides not to share it.
Hah, character controllers are indeed some of the most well protected secrects around )))

Hmm, just wondering, which game do you like character control in? Say from the below:

Unreal Tournament
Oblivion
Battlefield
Cry
Quake/Doom
Half-life/Counter-Strike
Neverwinter Nights (and other D&D)
Other (please describe)


It would really be nice to know. I would be working on a character class atm, just not sure yet whether to continue with ODE, or a more promising Bullet, so the more ideas, the easier it is to implement.

I've played UT, Oblivion, and Half life, but I don't remember anything specific about the character movement. The best example would be...

Any MMORPG game.

Think EverQuest or WoW. Think of people spending massive amounts of time moving around and messing around, like sliding along walls and posts and fences and anything in general. Way back when I played EQ there was a zone that had a special passage, but it wasn't visible, a rock wall texture was hiding the entrance. So our party walked along the mountain walls until we found the cave.

I would say the main prerequisites to any decent character controller would be:

1. Ability to walk over Terrain, bridges, stairs, platforms intermixed without any problems.
2. Be able to jump.
3. Have a limitation that doesn't allow walking over objects that are too tall. (for example, in zelda there were some giant steps, you have to jump up each one, can't just walk up)
4. Moving into an object causes you to slide along the objects surface. This may be hard when it comes to room corners (2 walls, and you will hit them both), or other advanced situations I can't think up at the moment. Also think of 2 npc's walking into each other, and aren't perfectly aligned. They should collide, slide past each other and continue moving (probably why the capsule is used and not a cube)
5. Being able to jump onto platforms, bridges, stairs, objects, etc.
6. Moving up and down hills shouldn't slow down the player. Not realistic, but its expected. If you want to make it configurable to affect the movement, that would be awesome. (and if the hill is too steep, you can't walk up it, part of requirement 3)

Well that's my list of requirements anyway. I'm sure if this was available everybody would be using it.

Just a question: by "Terrain" do you mean direct conversion from heightmap, or a separate "pre-made" trimesh would do?
And is crouching necessary?

I use ETM, but in general, a heightmap generated terrain. Tri-mesh should work also. Say you build a house all as one mesh, you should be able to walk from the heightmap ground into the house, walk around the house, and walk back outside without any problems. (I think this is getting at use of ray casting. I would try to avoid use of ray casting if possible, but I don't know, maybe its essential to have ray casting)

Why don't you like raycasting? That's been used, say in Unreal and most other shooters. Oblivion guys used a model similar to Sphere at the bottom method... Raycasts are a bit harder to setup, but generally prove to be quite well off (plus, as a bonus you get a smooth strair walk, unlike little "jumping" with physical base )

Well if it works, that works for me! But mixing heightmap raycasts with collision detection raycasts seems like a bad idea. I don't know if ODE supports a heightmap shape, but probably assume the terrain is a trimesh, or heightmap shape.

I played with raycasting a while back, its not so bad to use. But how does that work with jumping? Shouldn't we be using dynamics (physics) for that? In my previous work, I hardcoded some jumping distance, and to simulate gravity, I sent a ray downward for a certain length. If hit something, snap to that height, otherwise fall some.

If you wanted to support pushing blocks around, or getting knocked back by forces, etc, you'd need to incorporate some form of dynamics anyway. I guess I left that out of my list of requirements.

Actually all the things you've listed are already done by the model I have And believe me, it's really not as complicated as you think. What you did with the ray about jumping is actually a very wrong thing to do, as it is indeed a very bad practice to try to hardcode things in an already running physics engine. Its actually all way simplier.
Now, let me finish looking at Bullet for now, and if it proves to be worth it, then I'll just implement the model in there (they have a nice demo already, so perhaps just using that would do). Unless you are specifically looking for an Ode solution?

Was just reading the Bullet forums. Looks like you've already been there before me KungFooMasta's character sliding thread
They do seem to be having some delay unfortunately... Especially, considering the fact, that I still cant see charater demo in the latest version. Well, even better then!

My team has selected ODE for use, but I want to convince them to use Bullet, for all the features of Bullet listed by Tuan. I think working with it for bullet would be the most beneficial. And if you run into snags, the active developers are more than willing to give 'advice'. I would say 'help', but from my perspective, they seem a little more geared towards receiving patches and giving direction. But that's only what I've seen, in the short amount of time I've visited their forums.

they seem a little more geared towards receiving patches and giving direction
Well, at least they communicate, unlike the guys from ODE, who just seem to be either dead, or deaf&blind ) Never responded, bastards!

in the short amount of time I've visited their forums.
Heh, just noticed that (see my previous reply).
They ain't exactly the most active community ever, but...


Not sure, if you've seen that, but do have a look:
http://unity3d.com/support/documentation/Components/class-CharacterController.html
That's pretty much an ideal model in my view. Currently, I'd say mine replicates that by 80-85%

And Crytec... heh, near perfection, here goes - very useful seminar:

http://picasaweb.google.ru/jokermax/GDC2007_crytek

Wow, that first link seems spot on in terms of design!!

Slope Limit
Step Offset

Seems they do everything. I agree with their discussion about the doom behavior, being able to turn on a dime. This should be a requirement also, since it supports the character behavior in my personal project. (The character only moves forward, but pressing W/A/S/D changes his direction. So pressing D will face and move right. Pressing A will face and move left. etc.)

I haven't read the slides, they seem pretty advanced.

Aquatix, I'm not sure where you tried to contact the ODE people, but generally the mailing list is very active, usually around 10-20 messages a day, ODE went dark for a loooong time after 0.5, but over the last 6 months or so development has really picked up,

@Grey, well then, maybe I am using outdated data (well, that was like 2-3 months ago...)
Its good they are active again, yet still its a shame there's no forum there, no website updates... not to mention lack of documentation...

On the subject of steppers (several pages back) I was thinking its odd to have a StepListener that doesn't by default call


_world->updateDrawState();


which is the funtion call that makes all yer bodies match up with the Ode bodies its called at the start and end frame events.

presumably if you wanted a StepListener you'd be wanting to do something "personal" to the bodies and so would want the up to date positions and orientations?

Not sure what exactly you mean here, but AFAIK there is the World->synchronise() and it is called automatically either in PreStep or PostStep

I only see synchronise being called at the frameStarted and frameEnded events... could be lots of world steps in there I have about 6, also don't think it's the one that does the updatePosition and updateOrientation. Sounds like it should... but in Body theres a updateDrawState which is updating them, getting called from the maintained list which is getting called from the world updateDrawState. I was confused by it all morning

Aquatix, would a horizontally oriented capsule break the functionality of the character controller? My team's project has few humans, and mostly consists of four legged pets: cats, dogs, rabbits, squirrels, etc.

Absolutely no. Mine too uses some creatures, so the models would need to be laid horizontally instead. As a matter of fact, I will even make this class and share it out. As for the character one, than it will be up in ten minutes, so stay tuned!

In the recent days ODE has yet again been updated a lot (those who follow the CVS might have noticed). Looks like ODE is gaining back its former glory
Anyway, the new features are some new joints (e.g. the "piston" joint, which is like a slide joint, but objects can rotate around the axis as well), a very remarkable new collision space (which brings the hell lot of improvement, if you have big scenes (large outdoors, for instance).
I've already started porting them to OgreODE, but it would take some time, before I'll do them all and submit a patch. And I was wondering - is anyone else busy porting them atm? If so, please say, what have you done or planning to do, so that we don't do the same thing twice

How do you find out about these changes, through the mailing list? Maybe I should check that out.. it would be nicer if there was an easily accessible forum, or if the wiki was updated..

well, they ain't got a proper forum or anything atm, so the info needs to kindof be gathered by bits and pieces.
So, 1st of all, there's thier sourceforge page. Just look at the tracker there and patches. However, before they post pathes to the SVN, sometimes it takes up to several months, but it's getting quicker now.
Secondly, there's the famous (or infamous? ) mailing list (the link leads to the November archive). It's pretty informative sometimes.
And, last but not least - download ODE via SVN only, since the stable releases are not done as quickly, as they are done here, with Ogre, for example. The link was kinda hard to find, heh , so here it is: https://opende.svn.sourceforge.net/svnroot/opende/trunk

P.S. seems like I missed out the fact, that aside from new joint and space, they've added a 16-bit support for TriMeshes. Not really usefull in my case, but if anyone could find a use for that, then OgreOde can be update to take that into account.