CreateMeshShape from node with geometries with rotations problems

1

Hi,

Kinda tested this thoroughly.

CreateMeshShape from a node works fine… unless a geometry in the node has a rotation, at which point:

  • the physics debug will display as if all was fine
  • vehicles (tested with the TestFancyCar vehicle too) will behave erratically inside such geometries (but fine inside non-rotated geometries). Even just one rotated geometry and no others will bring up this problem

I don’t know if non-vehicles would suffer the same fate.

I’ve made sure none of my code would influence the results. No code of mine is executed as part from a couple lines to put the geometries and make them physical.

Any ideas?
Is there a way to apply transforms?
Or is there a bug, either on the jme or bullet side?

2

Use a Node for the rotated Geometry and apply your rotation in that Node.
Worked for most of my similar problems.

3

Thx Ogli :).

Err, how do I apply those rotations? Kinda looked all over the place for that already :D.

4

Should go somewhat like that:

your old code:
Node node = new Node();
Geometry geometry = new Geometry();
geometry.setLocalRotation(rotation);
node.attachChild(geometry);

your new code:
Node node = new Node();
Node node2 = new Node();
Geometry geometry = new Geometry();
node2.setLocalRotation(rotation);
node.attachChild(node2);
node2.attachChild(geometry);

:chimpanzee_smile:

1 Like
5

Tested your solution… sadly, didn’t work :sob:

6

Well, I know that I had lots of these issues when making the pacific monkey game (the physics part is finished, the game not). Don’t remember how I fixed all of them. Especially the Sphere shape was a problem because it “lays sideways” with Z being the main axis of the sphere. Also scaling was a nightmare because bullet uses a strange scaling factor which is 0.5*(sqrt(2)) - I could not believe it - and tried several “magic values” in the blind until it worked - the code wasn’t documented on the jME side and pointed to native bullet code which I could not read from the Netbeans based jME SDK. Another problem were bounding volumes. But physics is the worst, I can tell you.

7

Haha, well, physics has been kinder to me and I had no problems linked to scaling for example. There’s really just this little glitch. I’m probably doing simpler stuff than you though.

Dang, it’s been a week of very successful coding… but this is raining on my parade haha.
I’m completely unable to debug bullet physics… it’s like runes to me :D.

I guess I could “apply” the rotations myself, directly on the buffers… but that kinda stinks for a lots of reasons, and would limit the power of my editor on top of performances problems. I’m gonna look see if I can find some rounding problems or something.

8

Often useful: Make a simple test case so that others can step into the code and debug it “for you”.
Maybe there really is a bug, there have been unbelievably simple engine bugs lately - I could not believe what I saw in this forum.
It’s not good that there currently is no game physics expert among the jME people. I know some things from a book about that topic, but I’m far from calling myself an expert for game physics, bullet or jME - just had no time to analyze all that software.

1 Like
9

I’m comfortable that there is a bug somewhere because:

  • createMeshShape passing a geometry works
  • createMeshShape passing a node containing one geometry works
  • createMeshShape passing a node with a rotation of the geom or the node brings up trouble

And that with my vehicle or the testFancyCar one.

I have a test file for it and will email it (or any other way) if someone asks me to look into it.

Additional info:

  • the geom is a simple cylinder made with blender (location/scale/rotation applied before saving and turning into a j3o)
  • no possibilities of bias introduced into the testing
  • I can not yet say if it’s the shape or the physicsVehicle code that brings trouble

Well, I often can’t believe what I see in my own code :smiley:. I had more luck than you because it has been a smooth ride for me as far as bugs go.
I think there are very knowledgeable people about physics around here… just not naming them because it’s a little bit like: "hey a**hole… come resolve my problem otherwise, bwahahaha.

10

Anybody knows a convenient way of comparing all fields (included private) of 2 objects in java? I mean something like:
blabla.compare(objectA, objectB) and getting a list of different values? Also, it needs to not require adding comparator methods to the classes of the objects.

Probably asking for the moon, but was just in case someone had an idea because manually comparing values is hell with physics objects and I don’t see another way of finding what causes that glitch.

11

The debug display is from a mesh that bullet created itself, not created from the actual geometry, so that should look like what it is. Maybe the problem is something else. E.g. the vehicle can react funny if you have the wheels too far inside or outside of the chassis etc.

Its also not clear what kind of meshs shape you use. A real mesh shape isn’t meant to be used for mobile objects. Maybe you get a cylinder shape with the one geometry - which would work. And a meshs shape with the combined geometry which wouldn’t work (hint: use dynamic mesh shapes, i.e. Hull shapes)

1 Like
12

Thank you for your answer normen!

I use the same vehicle with both. Basically, I have a cylinder.j3o made in blender and I add 2 of them, one made from the geometry directly and one from the node. Geometry one works fine while the one from the node is physically glitchy. Both display fine using the debug display.

The problem also appears when I only add the compound one.

This being said, you brought important clues to me so I’ll be pondering them for a while before coming back :smile:.

13

The factory creates certain combinations of collision shapes based on the input, as said you don’t want MeshCollisionShapes as your chassis. Check if that is so.

14

I use a basic shape for my vehicles.

I’m going to retry applying the rotation because that would require the less changes. I tried debugging but got nowhere :D.

15

Ok, “managed” to apply a geometry’s rotation in jme. And yup, all works fine now \o/.
There’s definitively a small glitch with physics for rotated geometry’s part of a compound. I have not determined if it only shows with a vehicle. Was getting nowhere trying to debug it, so tried to apply the rotation.
Probably only concerns me, so probably no biggie.

In case applying a rotation is useful to someone:

    Geometry geom = findGeom(node, "Cylinder");

    Mesh mesh = new Mesh();
    FloatBuffer fb = geom.getMesh().getFloatBuffer(VertexBuffer.Type.Position);
    int limit = fb.limit();
    float[] tempArray = new float[limit];
    Vector3f tempVec = new Vector3f();
                
    for(int i=0; i < limit; i+=3){
        tempVec.set(fb.get(i), fb.get(i+1), fb.get(i+2));
        rotation.multLocal(tempVec);
        tempArray[i] = tempVec.x;
        tempArray[i+1] = tempVec.y;
        tempArray[i+2] = tempVec.z;
    }
    mesh.setBuffer(VertexBuffer.Type.Position, 3, BufferUtils.createFloatBuffer(tempArray));
    
    if(geom.getMesh().getFloatBuffer(VertexBuffer.Type.TexCoord) != null){
        mesh.setBuffer(VertexBuffer.Type.TexCoord, 2, geom.getMesh().getFloatBuffer(VertexBuffer.Type.TexCoord));
    }
    mesh.setBuffer(VertexBuffer.Type.Index, 1, geom.getMesh().getShortBuffer(VertexBuffer.Type.Index));

    mesh.setStatic();
    
    Geometry geom2 = new Geometry(geom.getName(), mesh);
    geom2.setMaterial(geom.getMaterial());