I’ve downloaded and decompressed that model. I’ll look at it after dinner.
Have you considered using a heightmaps? They generate HeightMapCollisionShape, which might be more efficient than MeshCollisionShape.
I tried to reproduce the crashes by loading your model and generating mesh collision shapes for it.
No crash occurred with v3.2.1 jme3-bullet on my x64 Windows7 desktop with 8GB of RAM.
But with v3.2.1 jme3-jbullet I got the following crash:
Nov 22, 2018 8:30:06 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.AssertionError
at com.bulletphysics.collision.shapes.OptimizedBvh$QuantizedNodeTriangleCallback.internalProcessTriangleIndex(OptimizedBvh.java:240)
at com.bulletphysics.collision.shapes.StridingMeshInterface.internalProcessAllTriangles(StridingMeshInterface.java:52)
at com.bulletphysics.collision.shapes.OptimizedBvh.build(OptimizedBvh.java:291)
at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.<init>(BvhTriangleMeshShape.java:80)
at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.<init>(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.<init>(MeshCollisionShape.java:77)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.<init>(MeshCollisionShape.java:67)
at com.jme3.bullet.util.CollisionShapeFactory.createSingleMeshShape(CollisionShapeFactory.java:217)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:117)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:95)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:95)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:95)
at com.jme3.bullet.util.CollisionShapeFactory.createCompoundShape(CollisionShapeFactory.java:137)
at com.jme3.bullet.util.CollisionShapeFactory.createMeshCompoundShape(CollisionShapeFactory.java:146)
at com.jme3.bullet.util.CollisionShapeFactory.createMeshShape(CollisionShapeFactory.java:176)
at jme3test.bullet.TestCity.simpleInitApp(TestCity.java:33)
at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:220)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:130)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:211)
at java.lang.Thread.run(Thread.java:748)
I can see that the 2 crashes occurred in different places. Without source code for jBullet, I can’t say much about the root cause.
I’d like you to try running my code on your system, using jme3-bullet (and setting the asset locator path appropriately):
package jme3test.bullet;
import com.jme3.app.SimpleApplication;
import com.jme3.asset.plugins.FileLocator;
import com.jme3.bullet.util.CollisionShapeFactory;
import com.jme3.material.MaterialList;
import com.jme3.scene.Node;
import com.jme3.scene.plugins.ogre.MaterialLoader;
import com.jme3.scene.plugins.ogre.OgreMeshKey;
import java.util.logging.Level;
import java.util.logging.Logger;
public class TestCity extends SimpleApplication {
public static void main(String[] args) {
TestCity app = new TestCity();
app.start();
}
@Override
public void simpleInitApp() {
assetManager.registerLocator("C:/Users/Stephen/Downloads/crash model",
FileLocator.class);
Logger materialLoaderLogger
= Logger.getLogger(MaterialLoader.class.getName());
materialLoaderLogger.setLevel(Level.SEVERE);
MaterialList mats = (MaterialList) assetManager.loadAsset(
"blender2ogre-export.material");
OgreMeshKey key = new OgreMeshKey("blender2ogre-export.scene", mats);
Node model = (Node) assetManager.loadAsset(key);
int numTriangles = model.getTriangleCount();
System.out.printf("%d-triangle model was loaded%n", numTriangles);
CollisionShapeFactory.createMeshShape(model);
System.out.printf("Created mesh shape!%n");
stop();
}
}
Ok. First of all this encouraging. So it seems that there is no general problem with my mesh. And when I look on the number of faces you used and I use, there is even more potential.
I tried that and also did not have a problem with that. So the calls in that example aren’t the problem.
Although I tried the hole weekend to fix this error - I keep failing. In my mind the situation is as follows:
- I can’t use the pre-compiled bullet library because somehow, my OpenDS implementation seems to call a method of bullet that let the lib crash (I will attach the crash dump below)
- If I try to integrate the JME source code, I can’t get OpenDS run, because the asset manager doesn’t find the assets. And somehow it isnt enought just to add the JME classes as projects to eclipse and link the OpenDS project with it.
- The only thing that ist sure: I don’t use any jbullet. I only use bullet from source.
So either, my (DFKI’s) implementation let’s the Bullet library crash (with no compilation error before), or there is a bug in the native compiled bullet library.
For me - the first is the most likely.
But I think clearing that would be in our all interest…
First: the crashdump of the JME inlcuded pre-compiled Bullet: ## A fatal error has been detected by the Java Runtime Environment:## EXC - Pastebin.com
[quote=“jayfella, post:20, topic:41097”]
If it is separate from the other geometries find the geometry name and use that as the input for the mesh collision shape creator.[/quote]
I’m sorry but I need one more hint for that. The point where it is crashing is:
collisionShape = CollisionShapeFactory.createMeshShape(node);
Regarding Class CollisionShapeFactory there aren’t many other options. createBoxShape e.g. sounds like the is calculated a bounding box. So that wouldn’t help when driving through one big bounding box.
So that were my steps trying to integrate the JME framework.
- I added OpenDS as a Project in Ecplipse
- I remove every occurence of jbullet in the project settings
- I added jme3-desktop, jme3-core and jme3-bullet as projects beside OpenDS and linked the projects to each other so that OpenDS hat no errors any more.
In the following I had various problems. For example the Default.fnt isn’t found by the assets manager. I copied the Default.fnt to every important folder (even tried to use the absolute path). No idea where the asset manager is searching.
Very frustrating. At the moment it is a mystery what the problem is.
Do you have some more actual version of the bullet? Mine is 3.2.1
Or - this would be very nice - somebody could try to link OpenDS against the actual JME.
That would help me immense. Bceause I’m not familiar neither with eclipse nor with java I don’t see that I get that myself.
Any further help (with the overwhelming 
eclipse would be appreciated… My skype name is: live:cpi_114
Christoph
Unless it’s been configured otherwise, the asset manager looks on the classpath. If something is screwing up classloaders then that could also mess things up.
What is OpenDS? Maybe it’s doing something strange?
I’ve added the Fonts Folder in the User Entries and tried just to load “Default.fnt” (because it lies in “Fonts”). But no success. The question is: do I have to add it to the classpath of the executing project? Or the one the class which searches for the file lies in?
OpenDS is a driving simulator based on JME3. It can be downloaded an be imported to eclipse as an project. You can just Debug out of the box (unless you try stunts like include the JME sources 
)
Based on those locations it looks like you should be loading “Interface/Fonts/Default.fnt”
Even JME’s own code loads it that way:
…although it’s getting the font directly from its own jme3-core jar.
Could it be that the jme3-core.jar doesn’t exist, because I included the source code for it?
Isn’t found in “Interface/Fonts/Default.fnt”…
Depends on what “included the source code for it” means. Since the default.fnt is included in the source folders. Maybe you didn’t include all the source? Maybe eclipse doesn’t like class resources being in source folders?
Probably like a 100 things it could be down this wildly divergent path.
Edit: in the end there is no magic… the classloader is used. So the resulting jars/classpaths/etc. is what you’d need to check. Unless OpenDS is wiping all of that out somewhere.
Christoph:
I hope you paid attention when @jayfella advised dividing the world up into zones/chunks/sections. Just because your monster mesh is loadable in a test context doesn’t make it wise to load it all at once in a simulation/game context.
It’s possible that other parts of the driving simulator are consuming (or corrupting) some resource, causing collision-shape generation to crash. If it’s a resource consumption issue, dividing up the world is likely to help.
Note that both jme3-bullet and jme3-jbullet are precompiled libraries. They offer very similar APIs, but the underlying implementations are different:
jme3-bulletuses Java Native Interface to interface with the official Bullet Physics Library, which is written in C++, open-source, and actively maintained.jme3-jbulletusesjbullet.jar, a Java translation of the Bullet Physics Library from circa 2009, the source code to which is not easily found.
It seems to me that CollisionShapeFactory.createBoxShape() generates a box shape for each geometry in the model. In the case of the “crash model” you uploaded, that would mean 341 boxes, not one. But unless the model was designed with box shapes in mind, that’s unlikely to work well.
It’s also possible to create custom collision shapes (without going through CollisionShapeFactory) by invoking the various shape constructors (BoxCollisionShape(), MeshCollisionShape(), HeightfieldCollisionShape() and so on) directly. But CollisionShapeFactory.createMeshShape() provides a nice, simple solution for static objects like a chunk of a city.
jme3-bullet is part of the jMonkey Engine, for which v3.2.1 is the latest release. Many users build jMonkey Engine from the master branch in JME’s public repository, which includes a few bug fixes that haven’t made it into an official release yet. Possibly worth a try, if you’re desperate.
And even the master branch of JME doesn’t use the latest native Bullet libraries. (Like JME v3.2.1, JME’s master branch still uses the Bullet v2.86.1 release, which is now 21 months old.) If you’re interested, I can help you substitute a library more recent than v2.86.1 . (I’m currently using one that’s only 11 days old.) This is relatively easy and is (in my opinion) more likely to provide a fix for your immediate issue.
As it happens, I’m currently working on a fork of jme3-bullet called Minie that includes some bug fixes that seem difficult to integrate into JME. It’s not 100% compatible with jme3-bullet however, so I worry it might be incompatible with OpenDS.
-Stephen