Serialized meshes dont work across platforms..

[RapchikProgrammer]

Hello, i have noticed that meshes serialized using bullet dont work across platforms.. i had a little difference in size, when i generated the mesh on windows and the other on symbian (it uses non-windows systems defines).. upon further investigation, i noticed the btQuantizedBVH was taking 20bytes more in windows than on symbian.. maybe enforcing a fixed offset per serialized buffer to allow the mesh to be used across different platforms..

[Erwin Coumans]

This is the old btOptimizedBvh::deSerializeInPlace right? Perhaps you can create a larger buffer yourself, and shift it based on the platform?

The new Bullet serialization (btSerializer) should take care of this, but we don't support btOptimizedBvh yet. We'll look into it.
Thanks,
Erwin

[Erwin Coumans]

I had a quick look, and it was easy to add BVH serialization support for the new Bullet 2.76 btSerializer (and btBulletFile/btBulletWorldImporter).
The latest trunk will automatically serialize the btOptimizedBvh, when using the btSerializer (revision: 2023 ) to serialize the world.
It is also possible to (de)serialize only the btOptimizedBvh using this new btSerializer.

Although this is not in-place serialization, it is very efficient and more compatible (cross-platform, 32/64bit, big/little endian, float/double precision conversions etc).

Would you be interested to test this?
Thanks,
Erwin

[RapchikProgrammer]

I have solved the problem for myself, by undefining win32 under windows as my game is just for mobile phones, i can remove any optimizations for windows without a worry but i was pointing out the problem for others.. and i have tried using the trunk code (rev:2034), i didnt try it on symbian but the first thing i noticed is that the file created using serializer is of 2.02mb and the one created using the previous serializing is just 91.3 kb.. even if i used non quantized meshes it took just 350 kb with that.. and its taking 2.02mb with the current serializer.. i didnt try using the import function but wouldnt it be better if we used a callback based method to import data.. the programmer could specify his read function first and then call importer to import the world data..

[Erwin Coumans]

I have solved the problem for myself,

That sounds good.

the first thing i noticed is that the file created using serializer is of 2.02mb and the one created using the previous serializing is just 91.3 kb.

This is not a fair comparison, because the new serializer saves the entire world (all rigid bodies, collision shapes, bvh etc), whereas the old in-place method only stores a single btOptimizedBvh acceleration structure. We can look into saving individual parts with the new serializer.

Thanks,
Erwin

[Erwin Coumans]

I just made it a bit easier to switch to the new Bullet btSerializer (and btBulletWorldImporter). Please update to Bullet 2.76 final release revision 2038. (the in-place method might become deprecated in a future release)

Code: Select all

        int maxSerializeBufferSize = 1024*1024*5;
        btDefaultSerializer*    serializer = new btDefaultSerializer(maxSerializeBufferSize);
        serializer->startSerialization();
        trimeshShape->serializeSingleBvh(serializer);        
        serializer->finishSerialization();
        FILE* f2 = fopen("myBvh.bullet","wb");
        fwrite(serializer->getBufferPointer(),serializer->getCurrentBufferSize(),1,f2);
        fclose(f2);

To load the BVH, use the btBulletWorldImporter:

Code: Select all

 btBulletWorldImporter import(0);//don't store info into the world
        if (import.loadFile("myBvh.bullet"))
        {
                int numBvh = import.getNumBvhs();
                if (numBvh)
                {
                        btOptimizedBvh* bvh = import.getBvhByIndex(0);
                }
         }        

Right now, the overhead for a .bullet file is less than 6kb. We can reduce this further to less than a few hundred bytes in the future (if required).
Thanks for the feedback,
Erwin