Real-Time Physics Simulation Forum

Re: Serializing to and from platform-specific binary files

2009-11-12T03:58:16+00:00

After further investigation, it seems that (some of the) Bullet classes do not support RTTI (eg try and do a typeid(v), or dynamic_cast<...>(v) where v is of type btCollisionObject&). Hence the Boost serialization library groans; you get __non_rtti_object exceptions thrown. It seems that serialization via Boost is a no go. Rethink required.

Statistics: Posted by Chris Simson — Thu Nov 12, 2009 3:58 am

Re: Serializing Bullet Physics

2009-11-10T12:12:26+00:00

Hi Everyone,

RE: BULLET SERIALIZATION

I have seen that there is a Collada converter which allows the persistent storage of the Bullet system, but there are a couple of drawbacks:
- not all Bullet shapes are (yet) supported, eg the btCapsuleShape as used in the Ragdoll Bullet demo is not supported.
- there does not appear to be any way to link the serialized Bullet objects to other code (via a unique identifier system?), eg if you have another external class instance associated with a btRigidBody, how to you re-associate once the Bullet system has been read in from the .dae file?
- slow

An alternative, which I feel would be highly expandable (as the Bullet system evolves) would be to use the Boost serialization library. This would overcome the problems mentioned above. This would require that a serialize() function be written for each Bullet class, but once done, this is a very versatile system; the serialized objects could be sent to any 'media', whether that be file, clipboard, an aligned memory region or whereever.

I must say I have tried to undertake the serialization via this method of the btBoxShape (and its base class hierarchy) but have stumbled - it seems that if you try something like: BOOST_CLASS_EXPORT_GUID(btBoxShape, "btBoxShape") (in order to make this Bullet class 'visible' to the serilaization system) you get compile time errors. These errors are due to the placement new operators defined within BT_DECLARE_ALIGNED_ALLOCATOR. Instead of declaring placement new operators within this macro, an alternative could be to use the new overload declared in , eg
#ifdef BT_USE_PLACEMENT_NEW
//new (&dest) T(m_data);
::new (&dest) T(m_data);//this calls the new placement operator declared in , line 58.
...

I believe this would then allow the Bullet system to be serialized via the well respected Boost library.

What do you think?

Regards,
Chris Simson

Statistics: Posted by Chris Simson — Tue Nov 10, 2009 12:12 pm

Re: Serializing to and from platform-specific binary files

2009-06-24T19:50:22+00:00

I've been playing with the idea of binary serialization, and was thinking of using the chunk-based binary IFF format for this (in Bullet/Extras/iff is a first starting point for binary read/write based on IFF, with some info).

If you have another solution, that you can share with others, please let us know. We could add it in the Bullet/Extras folder.
Thanks,
Erwin

Statistics: Posted by Erwin Coumans — Wed Jun 24, 2009 7:50 pm

Serializing to and from platform-specific binary files

2009-06-23T19:20:27+00:00

Has anyone tried to serialize Bullet objects directly to a platform specific binary data file (through reflection or otherwise)? This avoids COLLADA, etc. but allows for the de-serialization process to be extremely fast as there are little or no allocations required, and needs only a handful of pointer fix-ups to prepare the data for runtime use. It's a pretty daunting task to code up support for all the possible objects so I'd be very interested to hear if anyone else has tried this or if there are some tips regarding something I might have missed in the current source. Thanks!

Statistics: Posted by RulonR — Tue Jun 23, 2009 7:20 pm