Strange physics in my world


I have a problem with jme-physics. I have 2 boxes (loaded from 3ds model because I wanted to test this feature) and a terrain. I want to get the boxes behaviour physically correct (collision detection and staying on the terrain). Sadly the boxes don’t do what I want them to. They behave very strange as they go whereever they want and fall into the deep (never really landing on the terrain).

I uploaded my files here. I hope somebody can look at it and find what I did wrong.

Best Regards, daryl

err, your code does not even run over here (e.g. because you did not put the .3ds in there, but I circumvented that). Try to make a very short test for what you are trying to achieve (terrain + a loaded 3ds with physics). When you don't get that running post here again.

Some flaws I noticed:

  • you seem to compute the mass before collision geometries are attached
  • you call generateCollisionGeometries after you have specified collision geometries manually (remove those calls where you don't need them)
  • you use world bounding before the first call to updateGeometricState which results in a NullPointerException

  • consider using SimplePhysicsGame as long as you are experimenting with physics (extending BaseGame is somewhat for advanced stuff)

I created a less complex example. I really don't know what it is doing - could the expert help (looking at you irrisor (or any other

I found a whole lot of problems in your 'simple' :-o class - you really should start with smaller steps!

here are the things I corrected to get it work:

  • first I replaced the camera handler by a FirstPersonHandler (like in SimpleGame) to allow me viewing the scene - you can't debug what you can't really see
  • I added a ZBufferState (like in SimpleGame) to avoid having the terrain paint over the box!
  • I change the order to 1. update physics 2. update input / app defined 3. update geometric state (like in SimplePhysicsGame) to get the reset action to work (and corrected coordinates)
  • moved updateGeometricState to end of init (like in SimpleGame) to fix first invocation of reset

    (you may have noticed that you wouldn't have run into all those problems above if you would have used SimplePhysicsGame)
  • the center of the box is you center of gavity (while not translated) -> made the center (0,0,0)
  • to move a physical entity translate the physics node not the collision geometry!
  • The line "new FlagRushHandler(mybox, properties.getRenderer());" moves your collision geometry out of the center of the physics node -> really bad. You can do "new FlagRushHandler(carNode, properties.getRenderer());" instead, which is better but still problematic, as you can move through the terrain this way. Apply forces instead.
  • (as written above) don't generate collision geometries if you already created them manually

  • finally there was a problem with PhysicsMesh.copyFrom(TriMesh) which did not copy transforms - fixed in CVS (please update).

    If you regard all this this you end up with a working version of your test.

    Consider doing things step by step and not everything at once

I really would try to advance slowly but tutorials are missing, that's my problem so I looked at your examples but as you saw I didn't understand much. But I will try harder !!!

daryl said:

I really would try to advance slowly but tutorials are missing

Yeah :( - not enough time for those yet :|

I really wonder about one thing: Sometimes the cube simply falls through the terrain as if there wouldn't be any, sometimes it works perfectly and sometimes the cube stays after a few bounces into the air as if the terrain was some units higher.

Could you look at the code again and compile it - then you will see what I mean.

Here the code again for quick copy & paste & compile:

import java.util.HashMap;

import jmetest.flagrushtut.lesson5.FlagRushHandler;


import com.jme.bounding.BoundingBox;

import com.jme.input.InputHandler;

import com.jme.input.KeyBindingManager;

import com.jme.input.KeyInput;

import com.jme.input.FirstPersonHandler;

import com.jme.input.action.InputAction;

import com.jme.input.action.InputActionEvent;

import com.jme.input.thirdperson.ThirdPersonMouseLook;

import com.jme.light.DirectionalLight;

import com.jme.math.FastMath;

import com.jme.math.Vector3f;

import com.jme.renderer.Camera;

import com.jme.renderer.ColorRGBA;

import com.jme.scene.Node;

import com.jme.scene.shape.Box;

import com.jme.scene.state.LightState;

import com.jme.scene.state.ZBufferState;

import com.jme.system.DisplaySystem;

import com.jme.system.JmeException;

import com.jme.util.Timer;

import com.jmex.physics.DynamicPhysicsNode;

import com.jmex.physics.PhysicsCollisionGeometry;

import com.jmex.physics.PhysicsDebugger;

import com.jmex.physics.PhysicsSpace;

import com.jmex.physics.StaticPhysicsNode;

import com.jmex.physics.geometry.PhysicsMesh;

import com.jmex.terrain.TerrainBlock;

import com.jmex.terrain.util.MidPointHeightMap;

public class IrrisorSimple extends BaseGame {

What did you change? Did my version run fine?

This is your version.

hmm, then I cannot reproduce that, sorry :expressionless:

I uploaded 2 screenshots to show what I mean:

In both cases the cube isn’t moving, so normally it would have to lay on the terrain in these situations.

did you really perform a CVS update?

I don't use CVS because I don't know how it works. Coudl you say which file I have to download where from?

oh, ok then simply add a

terrainmesh.getLocalTranslation().set( terrain.getLocalTranslation )

after invocation of copyFrom in you code. (the file changed in CVS was OdePhysicsMesh)

Thank you, now it works.