Hi!
I’m using a customized version of JME3, OpenDS which uses (perhaps) not the newest version of JME3. But at the moment asking here seems to be easier that trying to migrate to the newest JME3.
I’m loading a large OGRE model, which originally came from CityEngine and then was converted to OGRE with Blender. Somehow, the NPE only occurs if the model is that large. On smaller Models there isn’t that problem (could be the problem less lies in the fact that it is larger than the fact there are more (= other) shapes.
The Stack Trace:
Executing Startup Properties
Nov 18, 2018 11:41:34 AM com.jme3.app.Application handleError
SCHWERWIEGEND: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NullPointerException
at com.bulletphysics.collision.shapes.TriangleIndexVertexArray.getLockedVertexIndexBase(TriangleIndexVertexArray.java:78)
at com.bulletphysics.collision.shapes.TriangleIndexVertexArray.getLockedReadOnlyVertexIndexBase(TriangleIndexVertexArray.java:97)
at com.bulletphysics.collision.shapes.BvhTriangleMeshShape$MyNodeOverlapCallback.processNode(BvhTriangleMeshShape.java:261)
at com.bulletphysics.collision.shapes.OptimizedBvh.walkStacklessQuantizedTree(OptimizedBvh.java:955)
at com.bulletphysics.collision.shapes.OptimizedBvh.reportAabbOverlappingNodex(OptimizedBvh.java:703)
at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.processAllTriangles(BvhTriangleMeshShape.java:163)
at com.bulletphysics.collision.shapes.TriangleMeshShape.localGetSupportingVertex(TriangleMeshShape.java:71)
at com.bulletphysics.collision.shapes.TriangleMeshShape.recalcLocalAabb(TriangleMeshShape.java:88)
at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.(BvhTriangleMeshShape.java:84)
at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.(BvhTriangleMeshShape.java:63)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.createShape(MeshCollisionShape.java:134)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.createCollisionMesh(MeshCollisionShape.java:89)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.(MeshCollisionShape.java:77)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.(MeshCollisionShape.java:67)
at com.jme3.bullet.util.CollisionShapeFactory.createSingleMeshShape(CollisionShapeFactory.java:214)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:114)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:94)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:94)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:94)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:94)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:134)
at com.jme3.bullet.util.CollisionShapeFactory.createMeshCompoundShape(CollisionShapeFactory.java:143)
at com.jme3.bullet.util.CollisionShapeFactory.createMeshShape(CollisionShapeFactory.java:173)
at eu.opends.basics.InternalMapProcessing.addMapObjectsToScene(InternalMapProcessing.java:171)
at eu.opends.basics.InternalMapProcessing.(InternalMapProcessing.java:58)
at eu.opends.main.Simulator.simpleInitDrivingTask(Simulator.java:354)
at eu.opends.niftyGui.DrivingTaskSelectionGUIController.onEndScreen(DrivingTaskSelectionGUIController.java:98)
at de.lessvoid.nifty.screen.Screen.onEndScreenHasEnded(Screen.java:752)
at de.lessvoid.nifty.screen.EndOfScreenAction.perform(EndOfScreenAction.java:9)
at de.lessvoid.nifty.elements.EndOfFrameElementAction.perform(EndOfFrameElementAction.java:20)
at de.lessvoid.nifty.Nifty.executeEndOfFrameElementActions(Nifty.java:439)
at de.lessvoid.nifty.Nifty.handleDynamicElements(Nifty.java:358)
at de.lessvoid.nifty.Nifty.update(Nifty.java:293)
at com.jme3.niftygui.InputSystemJme.endInput(InputSystemJme.java:113)
at com.jme3.input.InputManager.processQueue(InputManager.java:844)
at com.jme3.input.InputManager.update(InputManager.java:908)
at com.jme3.app.Application.update(Application.java:690)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:234)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:152)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:192)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:233)
at java.lang.Thread.run(Thread.java:748)
I’ve read some other Threads about the Bullet library and NPEs. But I’m not sure its the same Problem…
Any help would be highly appreciated! On aksing I’m glad to offer more infos (perhaps with the help how to offer, I’m not the Java / Eclipse Pro
No. The only thing I can see, that my version of jbullet is “jme3-jbullet-3.1.0-alpha1”. I tried to replace the jar with the one out of the actual JME3 Version “jme3-jbullet-3.2.1-stable”. But this did’t change anything. This and the the fact, that smaller models work tend me to think, that my model is the problem…
Is there any way to check the OGRE model for errors?
When I replace createMeshShape(node);
with createBoxShape(node);
there is no NPE, but my car doesn’t hit the houses, but drives through it.
Or is there any limitation in the implementation of “createMeshShape” so that it only accepts a limited number of objects? My model consists of c.a. 870.000 Houses (mostly simple cubes)
I’ve (LINK REMOVED-jayfella) my OpenDS implementation (PW: ‘jmonkey123!abc’) . Perhaps you can try it?
At the moment I’m stuck…
Did you write that right? 870,000 (eight hundred and seventy thousand) houses? In one model? If that’s true you really need to slice it into sections and load/unload as you move around. You can’t just throw an entire city like that at the game. It just won’t work.
Link removed. To be clear, the user did not upload anything malicious, the filehost was the problem. Please be careful with which sites you use. Google Drive, Mega, etc are the safest solutions.
I have access to source code for native Bullet, but not for JBullet.
If you test with native Bullet libraries (jme3-bullet plus jme3-bullet-native) in place of the JBullet library (jme3-jbullet) that might provide us with a more useful stack trace. Or it might fail in a different way, or not at all.
I’m very sorry for that. Normally I use that hoster without any problems. I re-uploaded it with Dropbox. So should be save now… I won’t be using that site any more.
Explanation for OpenDS: you have to select “Driving Tasks” and then “Aachen3” and “Aachen3.xml”. Then “Start”
Yes. But to be clear: most of them are only one simple Box. I don’t think that should be very expensive.
We’re building a driving simulator where you can drive-through a hole (small) city.
I would love to do that. Is that possible with JME3? Or do I have to implement that (I think some engines do that natively. Not sure about JME3)
Ok. Tried that.
I removed manually everything with jbullet and dropped the “jme3-bullet” & “jme3-bullet-native” into the project and added the libraries under project → properties → java build path → libraries → add
Now, I get:
Executing Startup Properties
Nov 18, 2018 11:52:18 PM com.jme3.bullet.BulletAppState startPhysicsOnExecutor
SCHWERWIEGEND: null
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: com/bulletphysics/collision/dispatch/CollisionConfiguration
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at com.jme3.bullet.BulletAppState.startPhysicsOnExecutor(BulletAppState.java:121)
at com.jme3.bullet.BulletAppState.startPhysics(BulletAppState.java:162)
at com.jme3.bullet.BulletAppState.stateAttached(BulletAppState.java:211)
at com.jme3.app.state.AppStateManager.attach(AppStateManager.java:133)
at eu.opends.basics.SimulationBasics.simpleInitApp(SimulationBasics.java:275)
at eu.opends.main.Simulator.simpleInitDrivingTask(Simulator.java:338)
at eu.opends.niftyGui.DrivingTaskSelectionGUIController.onEndScreen(DrivingTaskSelectionGUIController.java:98)
at de.lessvoid.nifty.screen.Screen.onEndScreenHasEnded(Screen.java:752)
at de.lessvoid.nifty.screen.EndOfScreenAction.perform(EndOfScreenAction.java:9)
at de.lessvoid.nifty.elements.EndOfFrameElementAction.perform(EndOfFrameElementAction.java:20)
at de.lessvoid.nifty.Nifty.executeEndOfFrameElementActions(Nifty.java:439)
at de.lessvoid.nifty.Nifty.handleDynamicElements(Nifty.java:358)
at de.lessvoid.nifty.Nifty.update(Nifty.java:293)
at com.jme3.niftygui.InputSystemJme.endInput(InputSystemJme.java:113)
at com.jme3.input.InputManager.processQueue(InputManager.java:844)
at com.jme3.input.InputManager.update(InputManager.java:908)
at com.jme3.app.Application.update(Application.java:690)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:234)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:152)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:192)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:233)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError: com/bulletphysics/collision/dispatch/CollisionConfiguration
at com.jme3.bullet.BulletAppState$1.call(BulletAppState.java:115)
at com.jme3.bullet.BulletAppState$1.call(BulletAppState.java:112)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
… 1 more
Caused by: java.lang.ClassNotFoundException: com.bulletphysics.collision.dispatch.CollisionConfiguration
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
… 8 more
Seems that the replacement doesn’t fit to the rest…
Ok. I have seen there is an new OpenDS Version (5) that uses a newer JME3 Version. Although, I have removed everything regarding jbullet and added the native bullet.
A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb5d221ada, pid=8420, tid=0x0000000000003100
JRE version: Java™ SE Runtime Environment (8.0_152-b16) (build 1.8.0_152-b16)
Java VM: Java HotSpot™ 64-Bit Server VM (25.152-b16 mixed mode windows-amd64 compressed oops)
Problematic frame:
C 0x00007ffb5d221ada
Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
An error report file with more information is saved as:
D:\OpenDS Free\hs_err_pid8420.log
If you would like to submit a bug report, please visit: Crash Report
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
AL lib: (EE) alc_cleanup: 1 device not closed
So. Because smaller models work, it seems that either the size of the model is the problem (memory error - but that should show as those) or the model is corrupted. I habe imported wavefront OBJ in Blender an exportet it with the BLENDER2OGRE exporter.
Can I test my ogre meshes for errors independently?
Based on the opends.dfki.de website, it appears OpenDS Version 5 uses JME 3.2 . Both JME 3.2.0 and 3.2.1 use bullet3-2.86.1 for native Bullet.
There’s a known issue in JME 3.2 (issue 367/740/884) that causes EXCEPTION_ACCESS_VIOLATIONs. The issue typically shows up in animated/articulated models, not rigid models.
Based on the pc value, I suspect this is not an example of 367/740/884, but I’d like to look at a JVM error log (such as hs_err_pid8420.log) in case it contains more clues.
It’s not possible automatically. I think you may be confusing it with scene-graph culling, whereby it won’t render it it it’s not in view. But since your model is one huge model, it will always be in view as far as the camera can calculate.
I would cut up the floor into squares of a length that’s a power of 2 (8, 16, 32, 64, 128, etc) because it makes it a lot easier to determine which part to display when you write a pager.
If your models go over a grid border, just put it in whichever one it overlaps the most. The important part here is that even if you load all of the map at once - because they are now separate objects they can be culled if they are not in view. Object count matters, too. So choose a size that fits the middle ground.
Regarding collision-shape, because your collision-shape will now be significantly smaller (just the size of the grid size you chose) it will perform a lot better, too. You could determine which quarter of the grid you are in to put a collision shape on the grid position you will next go into, and thus have a constant of two small collision-shapes at all times.
I guess we are talking quadtree design here, which is a well travelled road if you want to google it.
The application was in the process of adding a model to the scene. It started to create a physics collision shape for a model with 5+ layers of node hierarchy. It had just created a static mesh shape and was setting the shape’s scale when native Bullet tried to read from memory at address -1.
Could the model be so big that Bullet ran out of memory? I need to think about this some more.
I’m a little surprised that the error report doesn’t list bulletjme.dll among the dynamic libraries. Hm.
Unfortunately, I lack the tools for this sort of work. Netbeans doesn’t even recognize bullet3 as a project. Lacking a proper memory map or symbol table, I studied the native stack trace, trying to infer where in bulletjme.dll the program might be. I got this far…
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x00007ffb75cf1ada
C 0x00007ffb75d1484b
C 0x00007ffb75d15b75
C 0x00007ffb75cf0801
C 0x00007ffb75ba98db
C 0x00007ffb75ba99db
C 0x00007ffb75ba9e1b ? btOptimizedBvh::build()
C 0x00007ffb75cf0940 ? btBvhTriangleMeshShape::buildOptimizedBvh()
C 0x00007ffb75c3b8bb ? btBvhTriangleMeshShape::setLocalScaling()
C 0x0000000002b9100c ? Java_com_jme3_bullet_collision_shapes_CollisionShape_setLocalScaling()
but unsure whether m_useQuantization would be TRUE in btOptimizedBvh::build(), I gave up.
I have no idea what limit you’re hitting, if any. I won’t even speculate. If you think it’s a plausible explanation, perhaps we should experiment with models of different sizes and learn what works and what doesn’t.
I can offer a lower bound, however. The main.meshxml model used in the TestQ3 application is 26 MB and contains 63 meshes and about 87,000 triangles. jme3-bullet seems to create its collision shape without any issues.
Using a simple test app, I successfully built a jme3-bullet rigid body from a single random mesh containing 10,000,000 triangles. I tested both with memory-optimized BVH and quantized BVH.
Hmm. I’ve checked the polygon count in Blender and it states c.a. 2.700.000 polygons. I’ve just zipped and uploaded (to dropbox ) the crashing model. Would you mind to try that on your JME3 instance? If it works for you, there may be another problem than the complexity of the model.
I know - in the future I have to implement a dynamic loading. But for the moment: is there a way to only have the ground map included in the bullet calculations? So that I can drive my car but the rest of the scene is irrelevant for this problem?
