Bones joint rotate but mesh doesn`t update

[Marchioly]

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.

The problem with that is that the bones format uses 'ObjectInputStream' from the java.io package. You would need to reimplement the whole object serialization protocol (http://docs.oracle.com/javase/6/docs/platform/serialization/spec/protocol.html)

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).

I agree that the conversion process to bones is annoying.

[AGP]

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?

[Marchioly]

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.

Link: https://bitbucket.org/ccxvii/ryzom-assets/overview


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).

Edit:Edit: It is worth noting that I have NOT finished implementing the IQE/IQM format in its entirety. I just have the IQE portion done and only the loading of bone information/skeletal animation.

The reason is because my sights are currently set on retargeting the animations from ryzom to my current model skeleton/scale.

[raft]

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.

[AGP]

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."

http://java-persistence-performance.blogspot.com.br/2013/08/optimizing-java-serialization-java-vs.html

[Marchioly]

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."

http://java-persistence-performance.blogspot.com.br/2013/08/optimizing-java-serialization-java-vs.html

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.

[AGP]

How do we proceed? Would you like to see the MaxScript as it stands right now? PM me your email address.

[Marchioly]

I pmed you earlier today.