Need odejava tweaking help

Game Mechanics
#1

I’ve successfully integrated odejava into my project, but I’m having a hell of a time tuning the physics to get what I consider to be believable behavior. Here’s what I have:

I’ve created a GeomTriMesh from a fractal terrain mesh to represent terrain. I’ve also created a simple box geometry to represent the user. The tri-mesh is added to the Space, the box is added to a body, which is added to the world. (BTW, the odejava API is pretty good, but it needs a ton more docs).

I’ve also, of course, created visual representations of all this using Java3D. The visual geometries exactly match the geometries I’m feeding odejava.

When I turn everything on (after setting the box’s body position to be a couple of meters above the terrain), the box falls as expected and contacts the terrain. Then the box jitters a little (as I would expect) as things settle down. If I wait long enough, the box will start to slide down one of the tilted triangles it’s landed on. That’s cool too. But as the simulation continues, the box doesn’t seem to behave very realistically, and eventually will flip completely over for no apparent reason. I’ve read the ODE docs and understand the issues concerning precision and instability, but I can’t seem to get the system to behave nicely.

I think I need some guidelines on what setting values to feed to ODE. For instance, here’s how I set up the world:


odeWorld = new World();
odeWorld.setGravity(0, -9, 0);
odeWorld.setStepInteractions(2);
Ode.setSurfaceMu(4);
Ode.dWorldSetCFM(odeWorld.getId(), 1);

On each frame of rendering, I do this:


odeWorld.setStepSize(frameTimeSeconds);
odeCollision.collide(odeSpace);
odeCollision.applyContacts();
odeWorld.stepFast();
odeConnection.updateAll();

Notice I’m using the DisplayBin class for the odeConnection variable (that whole API works quite nicely, BTW). Notice also that I’m not changing any of the contact collisions.

Am I doing anying fundamentally wrong here? Can anyone suggest better values or other settings for the world? Should I be doing something with the contact collisions?

-Tab

#2

[quote](BTW, the odejava API is pretty good, but it needs a ton more docs).
[/quote]
I agree, for High Level API you cannot even use ODE’s own documention directly.

This 2 is very small number, try increasing it to e.g. 10.

What is your stepsize? Try e.g. 0.05 for starters.

You can use World.step() instead of stepFast() but it’s notiecable slower and consumes more resources.

By the way, I noticed that you’re calling directly some methods from Ode class. How about using these methods like this:


// Set default surface parameters
            collision.setSurfaceMu(1000f);
            collision.setSurfaceBounce(0.14f);
            collision.setSurfaceBounceVel(0.1f);
            collision.setSurfaceMode(Ode.dContactBounce | Ode.dContactApprox1);

See e.g. org.odejava.test.car.CarTerrain.java example.

It is not required to read/write contact information, you can use them if you wish but it is not mandatory.

One other thing. Odejava is still missing auto disable / enable feature. I’ve done it a month ago about but haven’t committed it to the CVS yet. This also helps things to “calm” down for objects that have small angular or linear velocity. All objects that are moving very little are automatically disabled, note that all disabled objects will be automatically enabled if they come in contact with any enabled object. This speeds up complex simulations and adds moer realism on certain places. Auto disable/enabling has some issues but it’s a nice feature anyway. Have to commit it…

If you still have problems or questions, shoot them out…

Cheers, Jani!

#3

Maybe you can’t use the docs directly - but it’s still fairly intuitive I think at least from a setting attribute point of view.

Guess what? I have some time today shock. I’m going to begin my Odejava/Xith3D guide.

Cheers,

Will.

#4

Jani,

Thanks for the info. I hadn’t explored the JavaCollision class; I just grabbed it’s use from one of the simple tests.

My step size is based on the frame rate, so it’s typically around 0.0125 (and I believe small is good?), but is set on a per frame basis.

I bumped the interactions up to 10 (I don’t understand exactly what this number implies, or how it relates to anything in the simulation), and I set the collision defaults as you posted, but the simulation is even worse. When the box initially falls, it hits the terrain and bounces uncontrollably into the air.

I added a bunch of leading zeros in to the collision’s bounce and bounceVel settings (hoping to imply less bounce?) and it’s just as bad.

That surfaceMu of 1000 seems very high to me, but what do I know? The ODE docs talk about Mu and the two modes ODE can use with it, but it’s not clear how you set either mode. Is that one of the bit values you set in the surfaceMode property? If so, how do I know which mode I’m selecting (there’s nothing in the docs for odejava or ODE)?

I’m pulling my hair out with this. I wouldn’t think it’s this hard to get something that resembles reality. Isn’t there some set of recommended nominal values for all these things that result in something useful?

-Tab

#5

Your stepsize sounds small. The smaller, the better simulation but slower.

How big triangles are you using on your terrain? If your triangles are a lot smaller than e.g. the box colliding into it, then the box can tend to fall through the whole terrain. Generally speaking, you can use large triangles on a terrain but small triangles can be problematic, size related to all other objects of course.

Does the org.odejava.test.simple.TriMesh demo on Odejava work for you properly? You can test it by running org.odejava.xith3d.test.TriMeshExample (needs Xith), or you can convert it to Java3D by copying the relevant lines from org.odejava.test.simple.TriMesh (just the TriMesh geom part). You can test the CarTerrain demo aswell, it’s bigger demo than plain TriMesh.

I assume your triangle index is defined clockwise, if it’s in other way then your collisions wouldn’t work at all. How are you importing your terrain to Odejava, are you using e.g. ASE export from MAX?

This problem sounds pretty wierd… If you raise interactions, you will get better simulation for sure.

ODE 0.39 should be pretty stable both in linux and windows, but e.g. the collision part of code (OPCODE for trimeshes) acts a bit differently beetween different platforms.

I do not know when new version of ODE is coming out, but I feel that we should not go to ODE CVS head at this point, ODE’s own CVS head is under development and sometimes broken.

Are you using linux or windows version?

If you want, send your project to me by zip/tgz package and I can test it on my own development machine.

The default values should be ok for your simulation (simple box colliding with terrain). I’ve simulated hundreds of objects (boxes, spheres) with a large terrain, it works quite well but it has it’s issues.

There’s Collision.setMode(), look previous email that set’s it. See ODE’s own documentation for various modes that can be used.

Check ODE’s own documentation, section “7.3.7. Contact”. All modes are listed here.
Here’s the URL:
http://opende.sourceforge.net/ode-0.039-userguide.html#ref53

As I said, you can send your testcase to me, I can check it out.

Default values act pretty ok for me for simpler simulation sets. You need to tamper with surface parameters when you need that something extra, like real looking driving on a car.

#6

Jani,

First of all, I really appreciate your help with this.

I don’t import my terrain, but rather generate it during app startup. I’m sure the triangles are created in correct vertex order, because I do get collisions, they just seem to be out of control.

My traingles are 4 units on a side, and the box is 2 units square (xz) and 0.5 units high (y). The terrain is laid out in the xz plane in a regular grid and it’s height points (y) are based on a height map.

I’m running all this on Windows XP Pro.

I haven’t tried any of the non-console tests since I don’t have Xith installed. Maybe I can try those out today.

I’ll take another poke at my code today and take a look at the ODE docs again (a good night’s sleep sometimes helps). If I still can’t get satisfactory behavior, I’ll try to get the code in some shape for you look at. My code uses Java3D and the j3d library. Would any of that be a problem for you?

-Tab

#7

Your setup sounds good, it should act very reasonable. I have a hunch that there’s something wierd in the terrain generation part of your code but this is all that I can come up for now…

I think it’s easiest if you send a working project to me as a zip package straight to my email account. I also use mostly Windows XP on my work and freetime projects.

Java3D is not a problem, I have done some simple projects with it.

#8

I believe there are some current issues with collissions between the box geometry and TriMesh.

My generated terrain also has issues (only with boxes - not spheres) and so does the CarTerrainExample by Jani which is a loaded terrain.

I am using Odejava in Linux.

Will.

#9

Will, that might explain some of the behavior I’m seeing.

I’m working on reducing the complecity of my simulation in an attempt to better understand some of the settings, but I’m running into some fundamental questions (that I seemed to have made assumptions about in my original testing, which may be causing me my headaches).

My main problem at the moment: what’s the correct way to position/orient multiple geoms with respect to each other and the body’s reference point, in the same body? Specifically, I want a box with 4 spheres, 1 at each of the “bottom” corners of the box. I’ve been doing that like this:

body = new Body(world);
Geom g;

g = new GeomBox(WIDTH, HEIGHT, DEPTH);
g.setPosition(0, 0, 0); // I suppose this isn't really necessary
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(-HALFWIDTH, -(RADIUS + HALFHEIGHT), -HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(HALFWIDTH, -(RADIUS + HALFHEIGHT), -HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(-HALFWIDTH, -(RADIUS + HALFHEIGHT), HALFDEPTH);
body.addGeom(g);

g = new GeomSphere(RADIUS);
g.setPosition(HALFWIDTH, -(RADIUS + HALFHEIGHT), HALFDEPTH);
body.addGeom(g);

Is that the correct way to do it? The ODE docs talk about adding the extra geoms under a transform (sort of like a scene-graph maybe?), but there’s no transform object that I can find.

And as long as I’m asking questions, here’s some more:

  1. The ODE docs talk about the ability to have nested spaces to optomize collision detection. That seems like it might be useful, especially when using a large TriMesh for terrain. In a similar fashion, my Java3D terrain scene-graph uses a hierchical structure (with some 1024 Shape3D leafs) to achieve better rendering speed. Does odejava support nested Spaces?

  2. The ODE docs say:

[quote]Triangle meshes can interact with spheres, boxes and rays.
[/quote]
This implies you can’t collide a TriMesh with a TriMesh. Is that really true? That could be a huge problem.

  1. I don’t get the idea of setting my body’s mass to 1. Why can’t I set it to the “real” mass of the body (e.g., 2000 kg). I tried, and bad things happened. Doesn’t this mean all my bodies will have the same mass? Doesn’t this screw up collisions? Mass is directly related to inertia, so how can ODE accurately model the reactions when bodies collide, if all the bodies have the same mass (when they’re not supposed to)?

Those are the questions bugging me right now. Unless my understanding of physics or how ODE works is completely wrong, I’m beginning to think ODE may not be a suitable basis for modeling physics. But I’m willing to be enlightened.

-Tab

#10

TriMesh - TriMesh collision isn’t supported by ODE yet (at least not in the official release). I think I remember some discussions about it (but that may have been another API).

Are you sure you can’t work around this issue? Even if it had that support it may be rather slow. Personally, I am appoximating my vehicles with box geom.

Multi-geom per Body support is only just now being added to Odejava. Some of my recent changes made this more possible - but there are still a few more to be made before it is more usable.

Just to make sure you are up to date: are you using Odejava from CVS (and have run cvs update recently) and does your project compile with no deprecated warnings? Hopefully you can answer yes to both.

Will.

#11

[quote]I believe there are some current issues with collissions between the box geometry and TriMesh.

My generated terrain also has issues (only with boxes - not spheres) and so does the CarTerrainExample by Jani which is a loaded terrain.
[/quote]
I do not have any issues with TriMesh + other objects, they work fine.

But I haven’t updated to latest CVS (Williams changes). I’ll try to snatch some time and check what’s the problem.

#12

I do not believe any of my changes could have affected the collision mechanism - but it’s worth looking at I guess.

I have now made an Issue on this bug so we can track it publicly.

https://odejava.dev.java.net/issues/show_bug.cgi?id=1

Complete with a test case and screen shot.

Will.

#13

I can work around trimesh/trimesh collisions for now, but it could be a big issue later on. It seems that having a method to take a soup of triangles and convert it into a bunch of boxes would be a good thing for this purpose. That might sidestep the problem, but it depends on…

Multi geom per body: are there plans to get this done? I mean, are there some tricky issues, or is it just a matter of having enough time to code it?

It’s good to hear I’m not the only one having box/trimesh problems. I may be able to keep my sanity.

I did some reading on the ODE mailing list archives and discovered that ODE doesn’t handle dynamic friction, which I assumed it did. I found the methods for inducing drag and that may help some of my problems too.

I won’t be able to test anything for a liitle while though. It seems it’s time to reformat my drive and reinstall Windows so I can reliably use my network again. Long, painful story.

BTW, I’m using a version of odejava from CVS about 7 days old now. When my dev box is back up, I’ll update and recompile to make sure I have the latest stuff.

-Tab

#14

please keep your sanity - I know it’s often hard with young API’s as you don’t know where the fault lies :slight_smile: For this problem we really have no clue. I’d appreciate it if you could run my test case (issue #1) though.

I am coding the multi-geom support and it is just a matter of time.

Tell me what do you need for your multi-geom support? Bascially some way of constructing a Geom which is relitive to a second geom is that correct?

Will.

#15

Yes. I basically need the ability to create multiple geoms, each with its own transform to specify its position/orientation with respect to the body’s reference point.

I suppose ideally, if you could create a scene-graph like tree with nested transform groups and geoms, that would great. But I’d understand if that’s beyond the scope of your implementation. And I don’t have have a need for that complexity (at least not yet :slight_smile: ).

My poor dev box is taking a bit more time than expected to come back. When it does, I’ll give your issue test a try.

Oh, as I’m rebuilding my box, I’ve remembered I’ve been running Java 1.4.1_01. I’ll be installing 1.4.2 on the new box. I’m not sure if that makes a difference in any of this, but I’d thought I’d throw it out there.

-Tab

#16

1.4.2 is the minimum requirement for JOGL - this could be why your textures are strange.

Will.

#17

But I don’t use JOGL. I’m been using Java3D for DirectX exclusively. But I’ll probably need JOGL for your test.

-Tab

#18

Will,

I’m back up and running now. I download and installed xith and got your car terrain test working. I don’t see any box/trimesh issues at all, especially the one in your issue. Again, for reference, I’m on Windows XP Pro, SP1+, Java 1.4.2_04, latest odejava source from CVS as of the time of this post (actually about 30 minutes before). I was using Xith3D from the 2004-02-29_cvs snapshot.

As it relates to my project, the car terrain test is amazing. My code behaves nothing like that test, leading me to believe I’m doing something significantly wrong. I’ll have a close look at the test code and see if I can get better behavior.

-Tab

#19

I’m still stuck. Here’s some code you can try:

http://www.bennedum.org/files/ODETest.zip

It includes a simple ant script, a single source file, and a batch file to run the test. Run ant with no arguments to build the test. The build script assumes a “lib” directory at the same level as the entire archive file. It assumes Java3D is installed into the Java SDK.

When you run the test, it will open a 1024x768 frame with a simple scene. The “terrain” is a single triangle (GeomPlane for odejava. The “traveler” (the thing you can control) is a simple box (GeomBox). The controls are:

Escape - quits
Up arrow - forward
Down arrow - reverse
Left arrow - turn left
Right arrow - turn right
V - change view (above and behind, left side, 1st person)

I’d like you to observe the behavior without touching the controls. For me, the box falls to the “ground”, then bounces much more than I’d expect. If you let it run, within a few seconds, the box will out of control, spinning wildly.

What I want is: the box should fall to the ground, bounce a little and settle down.

Any idea what I’m doing wrong here? Is this behavior “normal” and I’m just expecting too much? I can’t seem to tweak things to get decent behavior.

-Tab

#20

[quote]I’m still stuck. Here’s some code you can try:

http://www.bennedum.org/files/ODETest.zip
[/quote]
I download it and try to check it tomorrow (friday evening).