IrrODE - an Irrlicht - ODE wrapper (now with SVN)

[Zurzaza]

I gotta check that. Are you using a GeomBox as collision geom? And does the model remain in that position, or does it slowly sink into the ground? If it would then some surface parameters might be wrong.

I tried used both trimesh and box, but they show the same result.
The mesh slowly go down to horizontal axis in about a minute...
See This Video

[Brainsaw]

Can you provide a testprogram/testmesh? This way I could check the problem more easily.

Btw: I'm gonna watch the video at home, am currently at work and I shouldn't download videos here

[Zurzaza]

Can you provide a testprogram/testmesh? This way I could check the problem more easily.

Btw: I'm gonna watch the video at home, am currently at work and I shouldn't download videos here

ok, do you prefer source code or the compiled program?
This is the source --> http://www.copypastecode.com/26953/
pass to enter: irrode

I'm sorry about italian comments....

See you soon

[Brainsaw]

I took a look at the code you posted, and it seems OK to me. Just one thing: your model contains animations, is that right? This might be the cause of problems, IrrOde doesn't support animated meshes. Well ... it supports them, but it always takes the data from the first frame to calculate the collision object (no matter if it's a trimesh or a box or something else). You could try to set the animation to the first frame and see what happens then.

[Zurzaza]

I tried to add the following code to my program:

mesh->setCurrentFrame(0);
mesh->setAnimationSpeed(0);

Nothing happens, the mesh now is "only static", but the issue persists.

[Brainsaw]

I uploaded a new version yesterday. It does now contain a little tool that enables you to define the surface parameters in a central XML file so you don't have to re-define them for every single level you make.

IrrOdeSurfaceEdit.exe: this is a little tool you can use to define a set of surface parameters to be used in your project. It gives you the possibility to define all parameters known from the IrrOdEdit plugin for IrrEdit. In IrrOdEdit you can specify you surface parameter file with the attribute "surfaceDefinitions", and the API provides a method "CIrrOdeWorld::setSurfaceXml". All parameters can then be referenced by their name either in IrrOdEdit with the attributes "name(_mat<number>)" and "useDefined" or queried from the API with "CIrrOdeManager::getSurfaceParameter".

Here is a screenshot of the tool:

@Zurzaza: Can you upload the model or email it to me? Or, even better, the whole project (sources and models) so that I can take a look at what's acutally happening. It's hard to tell something from just a little Snippet.

[Zurzaza]

@Zurzaza: Can you upload the model or email it to me? Or, even better, the whole project (sources and models) so that I can take a look at what's acutally happening. It's hard to tell something from just a little Snippet.

The model is "sydney" from irrlicht "media" folder, and the map is "map-20kdm2.pk3", from the same folder.
I'm going to send you an email with source code

EDIT: See your pms...

[Brainsaw]

Thanks. I hope I find the time to check it next weekend.

[Eigen]

I recently decided to switch my project over to irrOde and I have a couple of questions.

When dealing with static geometry I don't need a CIrrOdeBody, right? Is it only needed for dynamic objects? Because when I add a body to static geometry it starts falling due to gravity. Hence I simply create a CIrrOdeGeomTrimesh. (I deal with physics in code, not in irrEdit) Now, how can I specify which mesh to use for creating the physics objects? I'd like to have one mesh for rendering and one for physics.

Another question is this: I create a CIrrOdeGeomRay but it seems it doesn't collide with any static geometry I have created (using Trimesh, no CIrrOdeBody). It only collides with spheres I create (these have bodies). So I gather that rays only detect bodies, not geoms? So how can static geometry have bodies when they need to be static and not move around.

Thanks in advance. I really like irrODE

[Brainsaw]

Welcome aboard Eigen,

It's right. the CIrrOdeBody is just for dynamic objects. If you want to create a CIrrOdeGeomTrimesh in code do it like this:

- create a CIrrOdeWorld object. All further IrrOde nodes must be descendants of this
- create the mesh you want to display. Must be descendant of the CIrrOdeWorld node you created before (no necessarily a direct child)
- now create a CIrrOdeGeomTrimesh with the mesh you created before as parent
- if you want to use another mesh for collision than for rendering you can add another child of the CIrrOdeGeomTrimesh you created before. IrrOde does then use this mesh to create the collision information whereas the first mesh is used to display

You can check the trimeshes in the IrrOdePlayground example, I think I use two meshes, one for collision and one for display, in that demo. You also have an option to create the terrain in that demo as a trimesh.

I'll have to check the CIrrOdeGeomRay. I might skip all contacts that are not bodies, but I'm currently not sure (you know ... source code not around as I'm currently at work). It should collide with static objects as well. I think I use this for the helicopter in IrrOdeCar, to measure the altitude.

[Eigen]

Thanks for looking into this. I checked the helicopter altitude and it's calculated using getHeight() on the terrain node instead of a ray.

[Brainsaw]

Yes, you're right. I looked at it yesterday, and I realized that what you describe comes from my code. The ray check is only done if one of the objects is dynamic, I'll have to change this (for IrrOdePlayground, the initial project, it was fine this way, but this has to be changed). I'll post a message here when I'm done with the change.


Oh ... and I was so convinced that I used the ray to get the helicopters height that I searched the code for about 25 minutes and wondered why the terrain is found and the other static objects not. I **have** to add more documentation.

[Brainsaw]

So, here we go: I uploaded a new version with the following changes:

- I fixed a little bug with the motor/servo. If the bodies attached to the motor/servo got internally disabled a change of the servo or motor had no effect, so I do now enable the bodies attached to a servo / motor when the parameters change (servo position, motor velocity, motor power)
- With the changes from the point above I was able to fix the IrrOdeCar application. Now all objects are controllable again (even the car and the tank). It was never a problem with the helicopter, because for moving it forces are applied directly, not through a joint
- I modified the ray checks so that both static and dynamic objects are detected. Check the IrrOdePlayground example to see the effect. If you don't aim at one of the objects, and if you are not too far away from the terrain (pretty close actually) the info text will show the distance to the terrain. @Eigen: this should help you.

[Eigen]

Thanks, it works now But I got a few more questions.

Is there a way to exclude certain bodies from ray detection? Preferably by ID. My collision ray starts within the player collision sphere and it keeps detecting the player not the world.

And how to force a body to stay upright, I mean a up-vector constraint, so the body would allways stay up.

Sorry to bother you so much.

[Brainsaw]

Hello,

I don't know of a way to skip certain geoms, I think you should calculate a position outside you character's sphere and start the ray from there. I guess using vector3d<T>::rotationToDirection would help(http://irrlicht.sourceforge.net/docu/cl ... a19278474d). Call this method from the character's rotation vector and use the character's initial foreward vector as parameter (with a length slightly more than it's radius.

For the upright issue you could take a look at one of opende's howtos:
http://opende.sourceforge.net/wiki/inde ... ht_capsule. The CIrrOdeEventStep event is fired after each step of the simulation. I think even if you set the maximum angular speed to zero you should correct the values after each step, because of the calculation accuracy.