I run into this error a while ago with no obvious cause for it.
It does not appear on a regular basis but it does “randomly” appears.
I am trying to isolate the piece of code that produce it, but I wonder if anyone had this before?
I am using the last nightly build available trough SDK.
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.mergeCollapse(ListSort.java:407)
at com.jme3.util.ListSort.sort(ListSort.java:233)
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)
Ok, we had several reported issues on the new sort algorithm, and for now I reverted back to the old one as it seems it cause more issues that it solves.
Next nightly should be ok.
@fbucur said:
I enqueue the tasks for the main thread, that's what I meant by "yes"...
Sorry, I understood "do you use multiple threads?" ...
Do you call any getters on scene graph objects or otherwise share them in any way across threads?
Or the ONLY way you touch these objects through the enqueue method?
…see, I have my doubts since the only real way to get the error purported is for the objects to have changed on another thread while the sort is being performed.
Note: getters are not safe either. People think they are but they never are. Unsynchronized/unprotected access from other threads in any Java case is never good. But especially so in this case.
If you do access things from another thread then nehon has hidden this error for you now so you can wait for it to crop up in some other less obvious random way.
@pspeed I will double check, but I am pretty sure no spatial is modified in other thread except the main thread. I will check for getters that might produce a change in the scene, but all the other threads I use are related either to AI or audio.
@fbucur said:
@pspeed I will double check, but I am pretty sure no spatial is modified in other thread except the main thread. I will check for getters that might produce a change in the scene, but all the other threads I use are related either to AI or audio.
Do not call any Spatial.getXXX methods from any other thread unless that spatial was never attached to the scene graph. Not “just the safe ones”. In Java’s memory model there are no safe ones anyway… just bugs waiting to confound you later.
Based on the line number in the trace the issue occurred with sorting opaque bucket.
This means you changed the texture on a material, camera location / direction, or spatial translation, which would cause the compare function to return inconsistent result.
Anyway, most likely this is a legitimate error. I reverted @nehon’s revertion of his own change, and added a test that demonstrates the issue.
I have this error in case of use imported OGRE model as scene, containing more than one node
Sometimes error …mergeLow, sometimes …mergeHigh, depends of model geometry
@vtls said:
I have this error in case of use imported OGRE model as scene, containing more than one node
Sometimes error ...mergeLow, sometimes ...mergeHigh, depends of model geometry
add:
in case with one node scene (one mesh), error still exists, but raises very, very rare :S
Does it occur with the models included with jME3 or only with your model?
Also, are you using multiple viewports like @fbucur does?
@fbucur said:
I can confirm the error is not multi-threading related... I reverted to a earlier commit and the sort exception is not caught anymore.
Le: in my case appeared when usin multiple viewports only.
Well, the error could be happening and just not being reported. That’s kind of the whole point of this thread. The newer version of the code catches an error that the old version silently ignored (and produced bad sorts).
re: “multiple viewports only” so you have absolutely no other threads in your app? Just the main update thread?
@pspeed said:
Well, the error could be happening and just not being reported. That's kind of the whole point of this thread. The newer version of the code catches an error that the old version silently ignored (and produced bad sorts).
re: “multiple viewports only” so you have absolutely no other threads in your app? Just the main update thread?
@pspeed I understand the point, that’s why I continued the thread after I found a workaround you guys give us so much, at least that we can do back!
Back on topic: I deactivated every other thread, even the queued tasks in the main thread, only controls and app states remaining, the exception still appears and more often when are more objects in the scene - if and only if I enable another viewport. Otherwise with or without other threads, the exception is never thrown.
@pspeed said:
So that's interesting. How are you managing your other viewports and what do you have in them? For example, do you have nodes shared across viewports?
separate nodes, second one is built from clones of geometries from the first node, its a 3D map of the scene, scaled down without textures, simple materials.
about managing, i just enable the second viewport, build the node and update it in the main thread, then disable it to turn back to the main viewport. i tried disabling the main viewport also but nothing changed.
@fbucur said:
separate nodes, second one is built from clones of geometries from the first node, its a 3D map of the scene, scaled down without textures, simple materials.
about managing, i just enable the second viewport, build the node and update it in the main thread, then disable it to turn back to the main viewport. i tried disabling the main viewport also but nothing changed.
Well, as you probably already know, the viewport needs to have its root updated once a frame… so I was curious where you were doing that, if you split the updateLogicalState() from the updateGeometricState() and so on.
@pspeed said:
Well, as you probably already know, the viewport needs to have its root updated once a frame... so I was curious where you were doing that, if you split the updateLogicalState() from the updateGeometricState() and so on.
at the end of the update of the state that manages the viewport (enable-disable)…
… and didnt split them…
LE i did tried also to put the 2 nodes in the rootNode alternately since the rootNode is updated anyway in the render, same result.