Native BVH Os Incompability

[empirephoenix]

Native Bullet:

Generate a Meshcollisionshape on 64bit Windows 7.
Write it out with the native bvh tree.

Load on same Windows works flawless.
Load on linux creates native crashes as apparently the native structure between different OS is not guranteed to be stable.

Proposed Solution:

Upon writing the MeshCollisionShape save the os.name and os.architecture properties into the j3o. When loading check if the architecture matches, if not emit warning to Logger and call createShape(true);
If the j3o is an older one with no saved os.name default to emit a warning and rebuilding always the shape.

Expected Result:
If the j3o does not contain the right native data, the application can continue to work, at an increased loading time for the j3o

Additional Notes:
Removing the native bvh save is in my opinon no options, as it can increase loading time by a factor of roughly 10x while reducing the memory print. This is especially noticeable for large geometries like whole levels. The bullet documentation specifically says to consider saving this native structure.

@normen
Any objection to this approach? If not i will create a pull request.

[shadowislord]

What is bullet's stance on this? How can they recommend persisting the data structure if it is not portable across platforms?

[empirephoenix]

From docu: "Concave Triangle Meshes
For static world environment, a very efficient way to represent static triangle meshes is to use a
btBvhTriangleMeshShape. This collision shape builds an internal acceleration structure from a
btTriangleMesh or btStridingMeshInterface. Instead of building the tree at run-time, it is
also possible to serialize the binary tree to disc. See examples/ConcaveDemo how to save and load
this btOptimizedBvh tree acceleration structure. When you have several instances of the same
triangle mesh, but with different scaling, you can instance a btBvhTriangleMeshShape multiple
times using the btScaledBvhTriangleMeshShape. The btBvhTriangleMeshShape can store
multiple mesh parts. It keeps a triangle index and part index in a 32bit structure, reserving 10 bits for
the part Id and the remaining 22 bits for triangle index. If you need more than 2 million triangles,
either split the the triangle mesh into multiple sub meshes, or change the default in #define
MAX_NUM_PARTS_IN_BITS in the file
src\BulletCollision\BroadphaseCollision\btQuantizedBvh.h"

I made a thread in their forum
http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=10547

[empirephoenix]

Just saying, I'm still on this.
With the answer form the bullet forums, I think I might be able to fix this so it actually works reliable.

Writing that way should work according to https://code.google.com/p/bullet/source/browse/trunk/Extras/Serialize/makesdna/makesdna.cpp#153
and if my C++ knowledge is not to far off, it seems that is also actually used in
https://code.google.com/p/bullet/source/browse/trunk/Extras/Serialize/BulletWorldImporter/btWorldImporter.cpp?r=2602
and not rebuild from scratch.

[empirephoenix]

Ok, after some more time with this, I say lets axe this for the time being.
Better to have one less feature but better stability.
I guess just disabling the calls javaside but keeping the interface to the native side will allow others to later play around with this easier.

[shadowislord]

@empirephoenix
Have you looked at the section "Saving a single object, shape or acceleration structure"?
http://bulletphysics.org/mediawiki-1.5.8/index.php/Bullet_binary_serialization

[empirephoenix]

Yes I did, but I failed to get it to work. Actually the writing part seems to work fine with that approach.

However the reading part, I did not manage to get btBulletWorldImporter. This might be due to a combination of my missing c++ knowledge combined with gradle based compiling. I did not manage to get that part to work. The importer lies in the extras subproject. It appears this extra part is not at all compiled at the moment, and also not included into the include path.

[stephengold]

Since native Bullet was removed from the Engine on 26 February 2021, this issue is now moot.