Add serialization support

[syberant]

I'm currently converting my simulation to using nphysics2d (thanks a lot by the way) but that unfortunately does mean that I can no longer easily Serialize and Deserialize everything with serde. There were some interesting things happening in #184 but it seems to be a bit quiet now. My ultimate goal is to be able to use Serialize and Deserialize with World and BodyHandle but small steps are probably a good idea.

I would like to get my hands dirty and do it or part of it myself but thought I'd ask for some advice here first. I currently have close to no knowledge of the insides of this crate and can not anticipate the challenges ahead so some advice will be much appreciated! One thing I do anticipate however is ncollide also not having serialization support, should I start there first?

[sebcrozet]

Hi! Yes, ncollide would be the starting point. The reason why we did not make much progress is because we could not figure out a proper way to serialize trait-objects (of type Box<Shape> in particular). I would be great if you could find a solution for this !

[Ralith]

Are we sure this is a good idea? Serialization can already be performed by manually traversing the world. Built-in serialization will be a subtle compatibility hazard when users attempt to load incompatible data from previous major versions (or a maintenance hazard in preventing that), while manual serialization ensures that downstream developers are directly responsible for, and therefore aware of, any changes in their file formats.

[syberant]

Right now I can't serialize a RigidBody so I'd have to extract all fields necessary for recreating (position, velocity, etc. though some like handle are impossible), put them into another struct to keep things organised and then serialize that struct. Every single person wanting to serialize a RigidBody would have to do reimplement this, I feel like this is something nphysics should implement rather than requiring everybody else to do it. If I'm missing something important here then please correct me and show me a better technique. I'm new to using nphysics and I'd imagine you have way more experience with it.

The compatibility hazard is something to look out for but I think it's not too hard to find out about incompatible files, when using your own format you would have to look out for that as well. A Version struct (containing, well, the version) could also be added for extra information on any version mismatch.

@sebcrozet, trait-objects are indeed a bit of a problem when serializing, I'll start puzzling with them.

EDIT: Sorry, I was thinking about the compatibility hazard for crates using nphysics, not the compatibility hazard for nphysics itself. That is indeed a risk I don't know the likelyhood of but personally I would be okay with only being able to serialize and deserialize files written by the exact same version of nphysics.

[Ralith]

put them into another struct to keep things organised and then serialize that struct

That's not necessary (though it may be relatively convenient); you can write serde (de)serialization code by hand.

I feel like this is something nphysics should implement rather than requiring everybody else to do it.

Different users will have different requirements. I expect that the overwhelmingly common case is serializing a more complex simulation (e.g. game) world of which nphysics is only one part, in a forwards-compatible fashion, and it's not clear to me that any built-in serialization support would be useful for that.

[Ralith]

The typetag crate may be of interest for (de)serializing trait objects.