Inconsistant Comparison Function with primitive meshes

Troubleshooting graphics
1

I have a decent number of primitive meshes (Cubes and Lines) as placeholders/helpers in my scene. I bumped the number from around 15 to close to 40, and now I’m suddenly getting constant crashes. At first I thought it was caused by the use of Unshaded materials, so I tried using a regular Lighting.j3md material and the results were the same. I read that it could be caused by bad multithreading, so I disabled all controls and everything else that uses app.enqueue() and any other multithreading processes. I also tried removing the FilterPostProcessor, thinking maybe it was a filter problem, but the problem persisted. Here’s the code I’m using to attach the geometries:


    public Geometry testModel(final int matId) {
        return new Geometry("Test", new Box(5, 5, 5)) {
            {
                if (matId >= 0) {
                    setMaterial(Utils.getApp().getAssetManager().loadMaterial("Materials/Unshaded" + matId + ".j3m"));
                } else {
                    setMaterial(Utils.getApp().getAssetManager().loadMaterial("Materials/JmeShaded.j3m"));
                }
            }
        };
    }

The problem is consistent regardless of what kind of material I use. The test models are attached to the parent Node like so:


                cityNode.attachChild(testModel(-1).move(
                        point.x,
                        terrain.getHeight(new Vector2f(point.x + cityCenter.x, point.y + cityCenter.z)) - cityCenter.y,
                        point.y));

And at another place:


        for (Edge e : edges) {
            Vector3f start = new Vector3f(
                    e.a.point.x,
                    terrain.getHeight(e.a.point.add(new Vector2f(cityCenter.x, cityCenter.z))) - cityCenter.y,
                    e.a.point.y);
            Vector3f end = new Vector3f(
                    e.b.point.x,
                    terrain.getHeight(e.b.point.add(new Vector2f(cityCenter.x, cityCenter.z))) - cityCenter.y,
                    e.b.point.y);
            Line l = new Line(start, end);
            Geometry g = new Geometry("Line", l);
            g.setMaterial(Utils.getApp().getAssetManager().loadMaterial("Materials/Unshaded.j3m"));
            cityNode.attachChild(g);
        }

Here’s the Unshaded material I’m using, as well as the Shaded (Just in case it is something with the Materials):


Material My Material : Common/MatDefs/Misc/Unshaded.j3md {
     MaterialParameters {
        Color : 0.4 0.4 0.4 1.0
     }
    AdditionalRenderState {
    }
}


Material My Material : Common/MatDefs/Light/Lighting.j3md {
     MaterialParameters {
        UseMaterialColors : true
        Diffuse : 0.4 0.2 0.0 1.0
        Specular : 1.0 1.0 1.0 1.0
        Ambient : 0.4 0.4 0.4 1.0
     }
    AdditionalRenderState {
    }
}

I’m certain it’s problems with this Node, and by extension something to do with the meshes, because if I detach the parent Node of those objects it works fine, and it doesn’t seem to matter what Material I use. Here’s the exception output:


Jan 08, 2015 5:47:22 PM com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.UnsupportedOperationException: Inconsistant comparison function
	at com.jme3.util.ListSort.mergeLow(ListSort.java:702)
	at com.jme3.util.ListSort.mergeRuns(ListSort.java:474)
	at com.jme3.util.ListSort.mergeForceCollapse(ListSort.java:423)
	at com.jme3.util.ListSort.sort(ListSort.java:241)
	at com.jme3.renderer.queue.GeometryList.sort(GeometryList.java:145)
	at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:318)
	at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:374)
	at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:781)
	at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:737)
	at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1001)
	at com.jme3.renderer.RenderManager.render(RenderManager.java:1047)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
	at java.lang.Thread.run(Thread.java:744)

EDIT: I also read, in another post about this error, that @nehon had set it back to the old function as the new one “caused more issues than it fixed.” However, I can’t seem to get any nightly updates since September of last year.

EDIT 2: If I remove the Line-mesh Geometries but keep the Cube ones, the problem disappears. Works vice-versa as well. Seems to be a problem when there are two different types of Meshes on the same Geometry. I also just tried making each name unique by appending an increasing integer to the end of the name - problem persists.

EDIT 3: The problem appears to disappear completely if I remove every single other Spatial except the Node containing those Geometries. It even seems to work with just the Terrain removed and everything else left attached. Could be the terrain and the Meshes conflicting, maybe something to do with the Terrain LOD.

2

It crashes when you sort the scene so if you remove things in your scene so that there only 1 of few geoms, the problem may not appear.

I disabled it, but it has been reintroduced because it has been established that it was just revealing a multithreading issue in the user’s code, and was not actually an issue with the sorting itself.

The previous sort was not crashing in that case, but the problems were probably more insidious.

geometries are sorted by comparing their material and their position from the camera. If you change ANYTHING outside of the rendering thread in the material (even a setParameter), if you assign a new material and so on… you’ll have this kind of issue.
Always use app.enqueue when you are using several threads. That’s the only way to make sure changes to the scene graph are correctly tailored to the rendering thread.

I may add that this issue doesn’t depend on the kind of material.

3

@nehon I’m a little confused, then. This program is a short test, there’s no multithreading whatsoever. It’s all being done on the render thread. This is all I’m doing (entirely in simpleInitApp):

Load a j3o terrain file
Add a directional and a point light
Pick a spot on the terrain and use a city generator I’m making (the test here) to put a city there

The CityGenerator is planned to be on a separate thread when it’s all said and done, but at this point it’s pointless to do that as the calculations there take a split second at most. All done on the same thread (the generate methods are directly called from simpleInitApp):

Generate some points with a seeded random, generate a voronoi diagram, attach boxes for the vertices and lines for the edges, as well as larger boxes for the cell centers.

There are no other threads being used anywhere, unless there’s anything involving other threads in the Terrain LOD classes. Strangely enough, though, I can’t seem to recreate the error today - even with all of the exact same code running on the exact same system.