Edit: Another problem with the bones format/java serialization is that it removes the ability to obfuscate your code/bones lib (assuming you want to).

it's interesting that you call that a problem but not a restriction.

anyway, it's not a real restriction, you can exclude Bones' classes from obfuscation so serialized format wont cause a problem.

I used the wrong word. A more fitting word would be limitation or shortcoming. Yes, you can remove the classes from obfuscation, but that will just make the process of reverse engineering/deobfuscation that much easier.

The MaxScript part I can handle. Isn't the point of serialization performance? What if we bypass the bones format altogether and create a JSON-serialized format of our own (and we could--and, indeed, SHOULD--add support for importing other formats, such as the IQM)? We could export to a custom format we could call, say, bonesx (that way we could make our own exporters for Max and Blender spit out the serialized and final file). Regarding JSON, I quote the following article: "The results show that Java serialization is slow for a small number of objects, but good for a large number of objects. Conversely, XML and JSON can outperform Java serialization for a small number of objects, but Java serialization is faster for a large number of objects."

I like the idea of json or at least a text based format. Mainly because it makes it easy to check for errors/debug the problems that library users are experiencing.

On the topic of the speed issue, I have not done any benchmarks since around jdk1.6/java6.

I was of the understanding that java serialization/ObjectOutputStream was slower than a binary format. I have only previously compared it with xstream/kryo/gson. I thought that in general gson's serialization was pretty fast. However, it is worth noting that my previous tests were storing integer/string data rather than complex objects.

Oh, I know. I'm getting as far as a MaxScript that exports skin and bone data. I'm currently creating an intermediate JSON-serialized format. But I do hope to do the Java Serialization from inside 3ds max.

Should we coordinate our efforts?

I would be open to collaborating on it. I am not familiar with maxscript though.

The avenue I took was adding support for the IQM/IQE animation format to some code that was derived from bones. Format information: http://sauerbraten.org/iqm/

The reason I chose to work with IQM/IQE was because it is a really common format with a lot of importers/exporter script for 3dsmax/maya/blender.

Additionally, the assets from the mmorpg Ryzom, were released with a CC-by-NA license. As a result, I wanted to get those working/take advantage of that.

Done. I've also posted a job on Freelance.com for anyone who wants to attempt a MaxScript that takes any biped or bones model from Max and directly exports a .bones file. We'll see how that goes, but that would go a very long way towards making Bones more useful.

I havn't really looked too hard into bones, but I forked the code last night and am implementing an actual protocol rather than the object serialization (not too bad so far, the relevant code is commented out in places).