DeSerializer

Started by raft, March 05, 2010, 06:20:51 AM

Previous topic - Next topic

raft

how does DeSerializer work exactly ? plain java serialization or other format ? i've found java serialization is god damn slow on this thing :-\

EgonOlsen

No, it's some other format. Basically, it's all about writing int[]s and float[]s (converted into ints) directly into the stream. The basic idea was to have something that:


  • Android/Dalvik can load fast
  • doesn't consume much memory
  • doesn't require any parsing
  • stores normal, so that build() doesn't have to calculate them

It's not a full blown Object3D serializer. It serializes mesh data, vertices, texture ids and names and is able to reassign them even if the ids have changed at load time, normals...some Object3D attributes, but not even close to all.

raft

i see. sounds good :D i guess it also stores compilation information, right ?

is it possible to add a method pair to serialize/deserialize only the mesh ? it can help saving/loading mesh animations. in this thing loading via regular serialization takes ages. i've sent a test app to my friend to load 130 keyframes of 810 poly's (and almost half of them are shared) and G1 timeouted while loading them ::)

raft

i'm assuming Mesh and sequence data can be extracted from Animation and it can be reconstructed later on. looking at docs, it seems possible..

EgonOlsen

I wanted to add (de-)serialization of Animation (if attached to an object) anyway. Wouldn't that be sufficient?

Apart from that, 810 keyframes sounds a bit hefty for the device regardless of the loading method...

raft

810 is polygon count per mesh. there are 130 (it's 106 indeed, rechecked) keyframes and almost half of them is shared, ie: references to other key frames.

i guess the problem here for dalvik is, during deseriliazation, it needs to keep track of every object in stream to maintain references. and that is
~106/2 x 810 x 3 = 128.790 vectors

there is no object when serializing animation, so it's not a perfect match for me. but i can still live with it. i can create a temporary object to save animation with. adding a method to de/serialize animation itself may also be possible. it's your call, all is good for me. but at the end, to save animation, you will end up implementing de/serialization all three (object, animation, mesh). exposing all three may give max flexibility, again it's your call

i would just suggest to watch for references in keyframes. it heavily reduces both memory usage and file storage

is compilation information is serialized with object ?

EgonOlsen

No, compilation always happens at runtime, because the results depend on a few more things like hardware's capabilities and such.

raft

Quote from: raft on March 05, 2010, 06:30:52 PM
i guess the problem here for dalvik is, during deseriliazation, it needs to keep track of every object in stream to maintain references. and that is
~106/2 x 810 x 3 = 128.790 vectors
oops, there is no data in form of SimpleVector in mesh. all is float or int arrays. so i end up dalvik just sucks at deserialization or maybe at reflection as serialization uses reflection

EgonOlsen

Dalvik sucks in almost everything...