Get always UnsupportedOperationException in ListSort with PlaneCollisionShape

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 [email protected] (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;
}
1 Like
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:

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

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.

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

1 Like

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?

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

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?)

1 Like

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”.

1 Like

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)
1 Like

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.

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.

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).

1 Like

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.

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.

1 Like

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

1 Like

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.

1 Like

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

1 Like

hehe ok :slight_smile: 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.

4 Likes