Get always UnsupportedOperationException in ListSort with PlaneCollisionShape

erwin82 · September 29, 2020, 2:15pm

Hello. I wanted to have a PlaneCollisionShape for a terrain so that objects don’t fall into nothingness. I used the code below. But with bulletAppState.setDebugEnabled(true); I always get the error “Make sure you do not modify the scene from another thread and that the comparisons are not based on NaN” if I use the PlaneCollisionShape. With debug=false I don’t get it. Looking in the debugger, the com.jme3.bullet.control.RigidBodyControl@4aab7195 (Geometry) worldBound is “BoundingBox [Center: (NaN, NaN, NaN) xExtent: NaN yExtent: NaN zExtent: NaN]”, I think that is the geometry of the debug wireframe.

Is something wrong with my code or is there a bug in debug mode and PlaneCollisionShape?

Testing it with debug=off and dropping objects it seems to work fine. The PlaneCollisionShape is preventing the objects to fall.

public SheetNode setup() {
    node.setUserData("z", terrain.z);
    var sheet = new Quad(width, height);
    sheet.setBound(new BoundingBox());
    sheet.updateBound();
    var shape = new PlaneCollisionShape(new Plane(new Vector3f(0, 0, 1), 0));
    var g = new Geometry("geo", sheet);
    var mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
    g.setCullHint(CullHint.Always);
    g.setMaterial(mat);
    node.attachChild(g);
    control = new RigidBodyControl(shape, 0);
    node.addControl(control);
    control.setPhysicsLocation(new Vector3f(-width / 2f + 1.0f, -1, height / 2f + 1.0f));
    control.setPhysicsRotation(new Quaternion().fromAngleAxis(-DEG_TO_RAD * 90f, Vector3f.UNIT_X));
    return this;
}

oxplay2 · September 29, 2020, 2:27pm

sheet.setBound(new BoundingBox());
sheet.updateBound();

why you execute this lines?

Please note you set empty BoundingBox without values assigned to it.

for custom Mesh, you need execute geom.updateModelBound(); each time you update geom mesh.

But here it should be all fine, but i really dont know why you need sheet.setBound() and sheet.updateBound()

Also if you want physics for terrain, just use:

    CollisionShape terrainShape = CollisionShapeFactory.createMeshShape((Node) terrain);
    terrainShape.setMargin(0.01f);
    rigidBodyControl = new RigidBodyControl(terrainShape, 0);
    rigidBodyControl.setPhysicsSpace(PhysicsSpace.getPhysicsSpace());
    rigidBodyControl.setFriction(0.95f); //tarcie od 0 do 1
    rigidBodyControl.setRestitution(0f); //bounciness
    terrain.addControl(rigidBodyControl);
    app.bulletAppState.getPhysicsSpace().add(terrain);

you can use CollisionShapeFactory aslo for planes(quads) you create. But if you use TerrainQuad from JME, just use code like above.

If you look how this factory create CS for terrain see:

github.com

jMonkeyEngine/jmonkeyengine/blob/master/jme3-bullet/src/common/java/com/jme3/bullet/util/CollisionShapeFactory.java#L84


            parentNode = null;
        } else {
            shapeTransform.combineWithParent(currentSpatial.getLocalTransform());
            parentNode = currentSpatial.getParent();
            currentSpatial = parentNode;
        }
    }
    return shapeTransform;
}
private static CompoundCollisionShape createCompoundShape(Node realRootNode,
        Node rootNode, CompoundCollisionShape shape, boolean meshAccurate, boolean dynamic) {
    for (Spatial spatial : rootNode.getChildren()) {
        if (spatial instanceof TerrainQuad) {
            Boolean bool = spatial.getUserData(UserData.JME_PHYSICSIGNORE);
            if (bool != null && bool.booleanValue()) {
                continue; // go to the next child in the loop
            }
            TerrainQuad terrain = (TerrainQuad) spatial;
            Transform trans = getTransform(spatial, realRootNode);
            shape.addChildShape(new HeightfieldCollisionShape(terrain.getHeightMap(), trans.getScale()),

generally it use HeightfieldCollisionShape that is more optimal and proper than Quads liek you want do.

github.com

jMonkeyEngine/jmonkeyengine/blob/473a899e95536a8163e2036add4b55df638d9a7c/jme3-bullet/src/main/java/com/jme3/bullet/collision/shapes/HeightfieldCollisionShape.java#L61


* limitations:
* <ul>
* <li>No rotation or translation.</li>
* <li>The collision bounding box must be centered on (0,0,0) with the height
* above and below the X-Z plane being equal on either side. If not, the whole
* collision box is shifted vertically and objects won't collide properly.</li>
* </ul>
*
* @author Brent Owens
*/
public class HeightfieldCollisionShape extends CollisionShape {

   /**
    * number of rows in the heightfield (&gt;1)
    */
   protected int heightStickWidth;
   /**
    * number of columns in the heightfield (&gt;1)
    */
   protected int heightStickLength;
   /**

erwin82 · September 29, 2020, 2:38pm

Thank you, but I’m not using JME’s TerrainQuad.

I want really just a plane that stops objects from falling to infinity. I have my own terrain with holes in it where objects can fall through, but they should not fall to infinity. So, I was thinking I add an invisible plane under my terrain.

This works perfectly now:

public SheetNode setup() {
    node.setUserData("z", terrain.z);
    var sheet = new Quad(width, height);
    // var shape = new PlaneCollisionShape(new Plane(new Vector3f(0, 0, 1), 0));
    var shape = new BoxCollisionShape(new Vector3f(width / 2f, 0.1f, height / 2f));
    var g = new Geometry("geo", sheet);
    g.setLocalRotation(new Quaternion().fromAngleAxis(-DEG_TO_RAD * 90f, Vector3f.UNIT_X));
    g.setLocalTranslation(-width / 2f, 0, height / 2f);
    var mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
    g.setCullHint(CullHint.Always);
    g.setMaterial(mat);
    node.attachChild(g);
    control = new RigidBodyControl(shape, 0);
    node.addControl(control);
    control.setPhysicsLocation(new Vector3f(1, -1, 1));
    return this;
}

But if I use PlaneCollisionShape and debug=true then I get the above mentioned error.

pspeed · September 29, 2020, 2:39pm

It could be that the physics debug doesn’t know how to render an infinite plane.

oxplay2 · September 29, 2020, 2:41pm

well, then might be worth report on Github i assume.

ListSort is just sort, but optimal and specjal for Geometries in JME.

I dont think its physics related, because its issue in ListSort, right?

erwin82 · September 29, 2020, 2:41pm

Here is a screenshot with new BoxCollisionShape(new Vector3f(width / 2f, 0.1f, height / 2f));.

oxplay2 · September 29, 2020, 2:43pm

i think it could be also worth to know what physics you use use? (if it might cause the issue)

jbullet or bullet-native or Minie? (probably native?)

pspeed · September 29, 2020, 2:45pm

Yeah… all things that might have been apparent if the stack trace had been included.

Note: the stack trace is 99% of the useful information of an exception. In the future, please include the stack trace with all reports of “I got an exception”.

erwin82 · September 29, 2020, 3:48pm

Sorry, forget the exception. Maybe because I didn’t found it useful at all.
I’m using JME 3.2.4-stable and jme3-bullet-native.

java.lang.UnsupportedOperationException: Compare function result changed! Make sure you do not modify the scene from another thread and that the comparisons are not based on NaN values.
    at com.jme3.util.ListSort.mergeLow(ListSort.java:703)
    at com.jme3.util.ListSort.mergeRuns(ListSort.java:475)
    at com.jme3.util.ListSort.mergeCollapse(ListSort.java:406)
    at com.jme3.util.ListSort.sort(ListSort.java:234)
    at com.jme3.renderer.queue.GeometryList.sort(GeometryList.java:158)
    at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:262)
    at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:305)
    at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:877)
    at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:779)
    at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1108)
    at com.jme3.renderer.RenderManager.render(RenderManager.java:1158)
    at com.jme3.app.SimpleApplication.update(SimpleApplication.java:253)
    at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:499)
    at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:581)
    at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:423)
    at com.jme3.app.LegacyApplication.start(LegacyApplication.java:463)
    at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
    at com.jme3.app.SimpleApplication.start(SimpleApplication.java:125)
    at com.anrisoftware.dwarfhustle.gamemap.renderer.MapTerrainTest.main(MapTerrainTest.java:75)

pspeed · September 29, 2020, 3:51pm

Yeah, but if you had included JUST that, I’d have already known what most of the problem is.

From just the stack trace, I already know that distance comparison between one mesh and another is returning inconsistent results. Usually because said mesh’s bounding shape has NaNs in it.

The rest of your post puts it in context.

erwin82 · September 29, 2020, 3:53pm

Yeah, sorry I forget. So, the issue is in PlaneCollisionShape and the debug? I can open a bug report. I just wasn’t sure if it’s a bug or I did something wrong.

pspeed · September 29, 2020, 3:55pm

Without knowing more details about the physics debug code (I never really looked much at it), it does seem like the debug shape creation stuff doesn’t like plane collision shapes. I don’t know if it doesn’t like them in general or if there is something specific about yours.

You might try to create a simple single-class test case that exhibits the issue. Maybe it will work and can point to the issue… or maybe it won’t and then it becomes an excellent example for filing a PR (problem report).

sgold · September 30, 2020, 2:50am

In jme3-bullet, a PlaneCollisionShape has no debug shape. I added a debug shape in Minie v1.3. With Minie, you can even apply a texture to the debug shape.

mitm · September 30, 2020, 2:56am

Great. Busted my ass trying to get it to visualize.

On a side note, I couldn’t get it to throw an exception either. Not saying it isn’t happening, I just couldn’t get it to happen. Gave up in the end.

sgold · September 30, 2020, 2:57am

If you switch to Minie, you might experience considerably less ass busting in the future.

mitm · September 30, 2020, 3:01am

Yes but minie isnt what was used here.

Which is what I was using to test case it myself.

I dont use physics in my game but if i did I would give it a shot.

sgold · September 30, 2020, 6:52am

Okay, then: if Erwin switched to Minie, we all might suffer less.

erwin82 · September 30, 2020, 11:53am

hehe ok I really don’t care which lib I’m using.

I will still try to write a single-class test case and post it as bug report in jme3-bullet-native.