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