Page 14 of 17

Posted: Wed Oct 27, 2004 8:44 am
by thegame
YAY !!! Thanks monster. It was the dumb Makefile problem. I had added it to the makefile but was using the VC project file (I know, I am an ass :? ), but all's well that ends well and WOW the landscape demo rocks !!!

Posted: Wed Oct 27, 2004 8:53 am
by monster
Hurrah! I've never built ODE using VC, I always use make from the command line. Much simpler!

Posted: Wed Oct 27, 2004 9:11 am
by thegame
Heh... I tried that - apparently migrating from linux makes me a n00b in windows, nmake was too alien for me so I switched to the _trusted_ Visual Studio Environment :wink:

Posted: Wed Oct 27, 2004 9:37 am
by monster
nmake was too alien for me
That's because you're not supposed to use nmake to build ODE, from the file ode-0.5/INSTALL;
(1) get the GNU 'make' tool. many unix platforms come with this, although
sometimes it is called 'gmake'. a version of GNU make for windows
is available at:
What it misses out from these instructions is that you'll need to set up the VC environment by running vcvars32.bat (in the MSVC bin directory) from the same command line you use to 'make' ODE. Or, an installation option will register those variables when you install MSVC, or you can use the "Visual Studio .NET 2003 Command Prompt" which will already have those variables registered too.

I think all this is covered in the ODE WIKI.

Posted: Wed Oct 27, 2004 10:31 am
by Whitebear
I built Ode 0.5 with OPCODE (config = single-trimesh), OgreOde with samples successfully.
But... :( . The Jeep has sunk.

Posted: Wed Oct 27, 2004 11:05 am
by thegame
You have to build the TerrainCallback Primitive into ODE. You can find complete instructions in the ode-0.5/contrib/TerrainCallback/ directory. Recompile OgreOde after you do it. Look throught the last 4-6 posts if you run into any trouble.

Posted: Wed Oct 27, 2004 11:45 am
by Whitebear
I'll try it. Thanks!

Posted: Wed Oct 27, 2004 12:03 pm
by monster
Indeed. As it says in OgreOde_readme.txt in the ode-0.5 directory;
If you want to use the Terrain collision primitive, follow the instructions in the readme file in $ODE_TOP/contrib/TerrainCallback and define OGREODE_TERRAINGEOMETRY in the file OgreOdePreReqs.h

Posted: Fri Oct 29, 2004 10:33 am
by chooikw
I have some problems using ogreode,please refer to


Posted: Fri Oct 29, 2004 4:19 pm
by Falagard

Just wanted to let you know that I compiled it up no problem, and the demos are awesome.

I worked with ODE about 3 years ago, and back then it was a royal pain to compile. Back then it took a couple nights of struggling to get everything I wanted to compile - trimesh stuff wasn't part of the main distribution, and had to be downloaded separately, etc.

Anyhow, latest version of ODE is so much easier. Although you use makefile, I suggest trying out a build using VC 7.1, which is in fact easier than makefile now.

Did have to manually add the terrain support .cpp file to the ode project, but that was a no brainer.

Demos are great. Love the helicopter. Very nice work. I haven't actually looked too deeply into your interfaces, except for the landscape/jeep demo which is cool.

I'm thinking of using ODE for controlling a player for a 3rd person perspective game, using the terrain callback code for colliding with ground, primitives such as boxes and capsules for testing against everything else, such as trees, houses, etc.

The idea is based, in part, on this article at Gamasutra: ... n_03.shtml

It sounds like a good idea in some ways, and overkill in others. A complete physics engine for player control? I wouldn't actually be using the physics for much other gameplay since it's going to be an RPG and not a platformer. Yet, if I didn't do it with physics, I'd still want to use OpCode for the collision detection, and have to implement my own gravity, sliding against barriers such as walls, etc. anyhow. Also, with a physics engine in place, I could possibly add in some new gameplay elements if I wanted to, and at the very least some nice looking eye candy in places.

What are your thoughts on the subject, monster, or anyone else?

P.S. the texture shadows - I didn't realize that mSceneMgr->setShadowFarDistance(30); would actually fade out shadows like that as shadows got further than the 30 meters. It looks awesome!



Posted: Fri Oct 29, 2004 11:39 pm
by sinbad
I just compiled OgreODE today, and monster, you've done a fantastic job.

I've contributed my 2 ha'penny's worth:

1. I've added VC7 project files / solutions
2. I've knocked up a patch to make modding ODE to include the terrain and 2D plane joint contributions a little easier. I haven't committed this to CVS since I'm not sure where you want to put it. I've uploaded a temp copy, please put it / mention it where you'd like. Note that you still need to manually copy across the new dTerrainCallback.cpp file since I can't generate a patch including that (since I don't have add access to ode CVS).
3. The custom material in the landscape demo could really do with a vertex morphing option :)
4. Personally I think you should uncomment OGREODE_TERRAINGEOMETRY and OGREODE_PLANARJOINT by default, since the former is required to run the landscape demo

HTH :)

Posted: Sat Oct 30, 2004 10:50 am
by Troglodit
2 Monster

I know that it sounds foolishly, but can you upload files with corrections necessary for work with Plane2D and Terrain collision primitive?
Just I am not naitive speaker and may be I dont completly understand, what you mean in readmes, because i has an error after complete changes in files:

Code: Select all

   Creating library ..\..\lib\Release/OgreOde.lib and object ..\..\lib\Release/OgreOde.exp
ode.lib(collision_kernel.obj) : error LNK2001: unresolved external symbol "int __cdecl dCollideTerrainCallback(struct dxGeom *,struct dxGeom *,int,struct dContactGeom *,int)" (?dCollideTerrainCallback@@YAHPAUdxGeom@@0HPAUdContactGeom@@H@Z)
..\..\lib\Release/OgreOde.dll : fatal error LNK1120: 1 unresolved externals
and one more question

before I change files for connect Plane2D and Terrain collision primitive, i
just compile ogreode and samples. in Demo_SimpleScenes i found strange bug -- just friction is 0 (capsules, boxes and balls was slided).
I know, that is my fall but may be you know what is wrong ?

Posted: Sat Oct 30, 2004 11:08 am
by Falagard
If you're compiling from Visual Studio, add the dTerrainCallback.cpp file to the project and try to compile again.

If you're using makefile, you forgot the step to add it to the makefile.


Posted: Sat Oct 30, 2004 6:51 pm
by Troglodit
all works ! Thank you !

Posted: Sun Oct 31, 2004 4:01 am
by Falagard
Regarding my post about player control and ODE, I did some further searching on the ODE mailing list and came up with a lot of good info.

I'm going to first try implementing this: ... tch=player

Using a modified version of the Plane2D joint.

Comments are welcome, and I'll let you know how it goes.


Slowness in the Helicopter demo

Posted: Sun Oct 31, 2004 4:31 am
by Robomaniac
I start the helichopter demo in Simple Scenes demo, and the fps starts at around 40 ish, then drops to 0.0x after about 5 seconds. Has anyone else seen this kind of drop, i know i don't have the greatest machine, but i don't expect it to be that high of a drop.

1.1 ghz amd duron
radeon 9600 aiw 128 mb
512 mb ram

Posted: Sun Oct 31, 2004 5:31 am
by Falagard
Robomaniac, are you running ODE compiled in debug or release?

I'm running in release with a 1.5 ghz Athlon with a GeForce 4 with no noticable slowdown.


Posted: Sun Oct 31, 2004 8:37 am
by IoN_PuLse
I've tested all the OgreODE demos on several machines, from athlons to P4s, from GF4ti's to GFFX5600's, no slowdowns or problems.

Re: Slowness in the Helicopter demo

Posted: Sun Oct 31, 2004 10:11 am
by Zigma
Robomaniac wrote:I start the helichopter demo in Simple Scenes demo, and the fps starts at around 40 ish, then drops to 0.0x after about 5 seconds. Has anyone else seen this kind of drop, i know i don't have the greatest machine, but i don't expect it to be that high of a drop.

1.1 ghz amd duron
radeon 9600 aiw 128 mb
512 mb ram

I have the same problem, after i recompilled with "plane2d terraincalback"
in Debug.

Posted: Sun Oct 31, 2004 11:26 am
by Troglodit
I want to create collide camera (which must not move through other objects). How I can create it ?

Thank you.

Posted: Sun Oct 31, 2004 4:43 pm
by Falagard

Your best bet is to check out here:

It's an online browsable and searchable archive of the ODE mailing list.

Do a search for "camera" and you'll come up with plenty of hits.


Posted: Tue Nov 02, 2004 2:16 pm
by Falagard
I need some help here, because I have no idea what's going on :-) I don't necessarily understand how joints are implemented in ODE, and whether there is a different between ODE's coordinate systems and OGREs.

Let me explain what I'm trying to do:

Player control using ODE physics. Simple as that. Push forward button, move player forward, colliding with the static environment, and interacting with other dynamic bodies in the world. So, move forward, backwards, turn left and right, and jump. Tada! If I could get this working, the possibilities are endless. The first thing that comes to mind are first person shooters, 3rd person shooters, and platformers, but it could be (and would be) used for RPGs as well, for simple movement and world navigation.

Whoever actually gets this working will be the king of the universe!

There are a few ways it can be done, and by reading the ODE forums, they include:

1. Control a body's (player's) velocity and orientation directly. This is regarded by the ODE forums as a bad idea, because you're circumventing ODE's physics system. If you got hit by an object, you wouldn't budge, unless you put special code in there to deal with it.

2. Control a body by using forces or torque. Moving forward adds torque in that direction, etc. Use a sphere or capsule to represent the player, and float it a small distance above the ground so it doesn't collide with the ground all the time. Through a system of using joints to keep the capsule floating above the ground, this will work.

3. Create a joint similar to Plane2D that doesn't enforce the z=0 constraints of that joint. Attach the player to the joint, and the joint to the static environment. Move the joint directly by using motors. You can control the velocity of the motors, and hence control the player almost as freely as with option 1, but without the negative factors because you will still interact completely with other physical objects.

So, based on my limited knowledge of ODE, #3 sounds like the best option.

Here's a link that describes it, and has some modifications to Plane2D to enable it:

Unfortunately, even after making the changes to the Plane2D code, I can't get it to work.

I've modified the OgreODE example called SimpleScenes_Joints to try to get this to work. I've tried a hundred different things, but I'm really just shooting in the dark because I don't actually know what the code is doing.

The result of simply modifying the Plane2D code with the code above, and then adding this to the addForcesAndTorques function of SimpleScenes_Joints is the ball rocking back and forth once J is pressed. It just rocks back forth along what I believe is the Z axis.

Code: Select all

if( left )
      joint2d->setParameterX( OgreOde::Joint::Parameter_MotorVelocity, 40.0f );
      joint2d->setParameterX( OgreOde::Joint::Parameter_MaximumForce, 100.0f );
      joint2d->setParameterY( OgreOde::Joint::Parameter_MotorVelocity, 40.0f );
      joint2d->setParameterY( OgreOde::Joint::Parameter_MaximumForce, 100.0f );

    if( right )
      joint2d->setParameterX( OgreOde::Joint::Parameter_MotorVelocity, -40.0f );
      joint2d->setParameterX( OgreOde::Joint::Parameter_MaximumForce, 100.0f );
      joint2d->setParameterY( OgreOde::Joint::Parameter_MotorVelocity, -40.0f );
      joint2d->setParameterY( OgreOde::Joint::Parameter_MaximumForce, 100.0f );
I actually think that the joint should limit rotation to only the Y axis, so it will only turn the ball around (as a player would rotate). Does this sound right? As far as I know, the modified Plane2D tries to limit rotation around the Z axis.

So, I tried modifying the Plane2D code to limit to the Y axis instead, but playing with these values in the plane2dGetInfo2 function:

Code: Select all

VoXYZ (&info->J1l[r0], =, 0, 0, 0);
    VoXYZ (&info->J1l[r1], =, 0, 0, 0);

    VoXYZ (&info->J1a[r0], =, 1, 0, 0);
    VoXYZ (&info->J1a[r1], =, 0, 1, 0);
   dVector3 ax1 = {
	    joint->node[0].body->R[8] };
    dVector3 ax2 = {
	    joint->node[0].body->R[9] };
I tried changing the r0 and r1 values, and the ax1 and ax2 values, so far without success. It does *something*, such as stop the ball from rotating at all when J or L is pressed, and in some circumstances makes the ball fly off in a diagonal direction, but I'm getting frustrated.

Any help would be appreciated. I actually doubt anyone will reply, but it's worth trying.


Posted: Tue Nov 02, 2004 5:35 pm
by Falagard
Sorry for posting so much.

I found this very interesting demo, which includes source code, that has a pretty okay first person camera system. ... round.html

I'm going to look into how it's done, but so far it looks like it's setting the linear velocity on a sphere which represents the camera, so it's similar to option 1. I think it's basically rolling an invisible sphere around, which represents player movement, by controlling the linear velocity of the sphere directly.

He's using a ray, which apparently in ODE is something like a cylinder that's infinitely long, but I think the only reason he's using it is to detect how far above the terrain or any other object, he is, so the player can't move while in the air. In fact, it's not a bad idea. He sets the position of the ray each frame. Then during the collision detection routine, he has special code to basically ignore ray to object collisions, but keep track of the depth of the collision point, keeping the shortest collision point. Since the ray always runs straight down, it'll collide with anything I guess. I'd think there'd be a problem with overhanging ledges, etc. Hmm.

I guess the main thing wrong with option #1 described above is that the player cannot be struck and thrown by other dynamic objects. For example, if a player is moving forward and a gate swings open quickly and hits me, instead of being thrown backwards, the player would continue to move forward because his linear velocity is still forward. In my case, it won't be an issue, because I'm probably going to be using this for an RPG/Adventure game, where there are less platforming elements.

Also, the whole sphere thing doesn't feel tight enough. You can tell you're rolling, because if you try to walk up a hill that slants off to the right, instead of moving straight up, you "roll" off to the right instead of moving straight. Regardless, I may start with this version for player control, and move onto something else later, because it sorta works and the code is available ;-)


Posted: Wed Nov 03, 2004 3:33 am
by monster
I think the difficulty with using a physics system for this sort of player control is that you want some things to be physically correct, and somethings not so much. There's a recent message on the ODE mailing list from the developers of Bloodrayne 2 regarding character control which seems to back this up;
For character movement in BloodRayne 2, we used our own simple
simulation. Rayne's collision was a capsule (or swept sphere) and had
a corresponding "geom" associated with her (but no body). If she hit
anything that was simulated in a frame of movement, she would add a
force/moment to that object. Then her geom's position was updated.
So they're manually moving the player's geom around, and manually applying impulses to the environment.
He's using a ray, which apparently in ODE is something like a cylinder that's infinitely long
Actually, a ray is a finite length infintely thin line. The ODE docs say;
A ray is different from all the other geom classes in that it does not represent a solid object. It is an infinitely thin line that starts from the geom's position and extends in the direction of the geom's local Z-axis.
And yes, you typically use them to detect intersections with the environment.

Here's a brilliant (:?) diagram of how I think you could set up some geoms and bodies to represent an FPS player. Effectively they're like a kind of unicycle;

Posted: Wed Nov 03, 2004 8:39 pm
by Bren
This would have the same problems mentioned above for sphere navigation -- rolling down ramps when no movement force is added, rolling "sideways" when navigating along a slope, etc. Getting up stairs could be a bitch. And if you were to run into a curb, you'd probably bounce into the air.