Create test from world/JSON export

[GoogleCodeExporter]

See http://code.google.com/p/box2d/issues/detail?id=207 and 
http://code.google.com/p/box2d/issues/detail?id=166

We should follow Box2d on this, and enable either exporting of a world directly 
to testbed code or (better?) to a JSON format (ideally whichever one gets 
integrated into the C++ version).

Original issue reported on code.google.com by ewjor...@gmail.com on 9 Jul 2011 at 10:49

[GoogleCodeExporter]

Original comment by ewjor...@gmail.com on 10 Jul 2011 at 4:49

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I started the jbox2d-serialization project for xml serialization (someone had 
posted an entire paper about it), but I never got around to it.  I'm thinking 
we should use protocol buffers (from Google!) which are super small, super 
fast, multilingual (generates Java, C++, and python), and have their own 
extendable markup so it would be easy to expand upon.  See info here: 
http://code.google.com/apis/protocolbuffers/docs/overview.html.  This also is 
awesome for network communications as well :D

In terms of json, it wouldn't be too difficult to throw in a parser/decoder,  
but it doesn't look like that project has a solid spec yet...

Original comment by dmu...@google.com on 13 Jul 2011 at 3:39

[GoogleCodeExporter]

i'm making an abstraction for all serialization, i'll commit this tonight 
probably

Original comment by toucansa...@gmail.com on 19 Jul 2011 at 11:27

[GoogleCodeExporter]

Excellent - if we get something going we can always just take the lead on this 
and contribute the spec upstream.  I definitely think that having some way to 
pass around physics between all the ports would be useful.

Are you including a lot of deep world-state serialization, too, like warm 
starting and contact states?  The one thing that we may have to be careful 
about is callbacks, there's no good way that I know of to wrap those up, 
sadly... I think the prototype implementation in C++ just noted that there were 
callbacks, and issued a warning.

If we do get a protocol buffer implementation, then it looks like 3rd party 
tools exist for AS3 and Javascript, too, so that could definitely be a good 
solution if people on those Box2d ports are willing to hook things up.  I 
suppose we could always do it for them if it came down to it, too...I'm sure 
the WCK port would get it working pretty quick, in any case, and that seems to 
be the most used one anyways.

Original comment by ewjor...@gmail.com on 20 Jul 2011 at 6:58

[GoogleCodeExporter]

World state serialization:
The way I have it right now it's more of a shallow implementation where the 
bodies/joints/etc will be created by the corresponding create___ methods from 
definitions.  My thinking was that serialization shouldn't be polluting the 
main library at all, so i don't have any of the warm starting/contacts saved.  
What do you think about that?  Should we try to serialize everything?  We could 
probably use the Visitor pattern in that case.

Callbacks/listeners:
In the current implementation, I kinda leave that up to the engine user.  I 
have the "object signer" and "object listener" to sign data and process 
results, and they can figure out the userData and add callback listeners there. 
 I guess this could be a string (or even byte array) instead of an int to 
encode more data... What do you think about this?

Yeah I'm kinda rooting for the protocol buffer route, the only caveat is file 
readability, which I think is the lowest priority.  

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 3:39

[GoogleCodeExporter]

Hmm, on second reading the JSON demo in Box2d (for C++ - see 
http://box2d.org/forum/viewtopic.php?f=3&t=7087) doesn't actually do the 
warm-starting or any of that, it looks like a shallow copy of the world state, 
too.  That's just fine, actually: we probably don't need this to be a 
byte-for-byte reproduction of the state, as the simulation isn't going to be 
100% deterministic unless people mod the engine to use strictfp mode anyways.  
Serializing all that stuff could be eventually useful, but it's definitely not 
top priority, especially since a lot of changes would have to be made 
internally to make it work right, and it would be pretty fragile.  I'd say we 
put that off as a later feature request.

Currently are you also storing velocity (linear and angular) information?  That 
would probably be good to have, at least.

Re: callbacks, I think your approach is fine - I'd say we should be more 
concerned about copying over the geometry and various settings, and leave 
external code as something that's left to the user.

I'm loving the protocol buffer idea, file readability be damned.  The one thing 
I'm a tiny bit nervous about is complicating the JBox2d dependencies - this is 
probably a non-issue if we're assuming people go through Maven as the One True 
Way to use JBox2d, but is that something we want to commit to? (I'm personally 
fine with it, I have much less trouble with Maven than with almost any other 
build/dependency/do-everything tool I've seen)

Original comment by ewjor...@gmail.com on 21 Jul 2011 at 5:57

[GoogleCodeExporter]

That is true about dependencies, but it is separate from the main library...  I 
guess if we want to we could have sub-modules in our serialization module for 
each serialization implementation, so you're not forced to include protobuffers 
if you don't want to....  we can probably worry about that later though.  I'm 
fine with Maven, I have a decent amount of experience with it and for the most 
part it does the job.

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 6:03

[GoogleCodeExporter]

Issue 15 has been merged into this issue.

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 6:18

[GoogleCodeExporter]

Actually, it looks like the generated protobuffer file doesn't have any 
dependencies!  All the encoding/decoding is built in! Cool! 

So the only time you'll need the protoc dependency is when you're compiling.

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 8:29

[GoogleCodeExporter]

Whoops, scratch that, it needs the dependency :/

Original comment by toucansa...@gmail.com on 27 Jul 2011 at 5:26

• Changed state: Started

[GoogleCodeExporter]

Check out the latest build, you can save/load tests.

Original comment by toucansa...@gmail.com on 27 Jul 2011 at 5:29

• Changed state: Done