Closed GoogleCodeExporter closed 9 years ago
Original comment by ewjor...@gmail.com
on 10 Jul 2011 at 4:49
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
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
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
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
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
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
Issue 15 has been merged into this issue.
Original comment by toucansa...@gmail.com
on 21 Jul 2011 at 6:18
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
Whoops, scratch that, it needs the dependency :/
Original comment by toucansa...@gmail.com
on 27 Jul 2011 at 5:26
Check out the latest build, you can save/load tests.
Original comment by toucansa...@gmail.com
on 27 Jul 2011 at 5:29
Original issue reported on code.google.com by
ewjor...@gmail.com
on 9 Jul 2011 at 10:49