i also have some doubts about the usefullness of a “human-readable format” when a human is not supposed to edit it anyway. If there is a real gain to balance the fact that the file will be heavier it’s ok. But if it will end like the .obj format, something that is only a huge list of things without any meaning, i think that it’s a bad idea.
You should maybe consider the option “one zip with animations and models/textures in it, one xml/whatever file to describe the relation between elements”.
Btw, i can see how you’ll embed models, but i don’t see how you’ll embed textures (with your current format). In the end, you’ll still have dependencies problems.
Same thing for shaders. And this is a very big (common) problem, as a lot of people just model things in blender then export them and are confused because their models look differents after import.
(English is not my native tongue, i know i do a lot of mistakes, don’t blame me, i try to be readable )
Hm as for the human readable, I still would prefer obj over binary formats,
even if it is only barely human readable, you get rid of almost all low level problems, (like java and unsigned data types) Also it allows for a better debugging of the importer, cause very simplemodels can be made (like a box or so) to test specific features directly.
In the end you are not supposed to use any non j3o format in productive with jme anyway.
Having a zip with all nessesary information for one model sounds good in theory, but in practice i have for example a city building pack, wich every model uses the same 10 textures. This would result in having the same texture multiple times stored.
@Eric-Lengyel said:
The OpenGEX format supports multiple independent animation clips per file. In the art pipeline where I work, however, we usually just export a separate file for each animation because our engine let's us import animations separately for each model, and this makes it easier to modify individual animations.
If you're storing multiple animation clips on the same object, how can you identify them in the engine? You need to have some sort of "name" field on the animation. The spec seems to be missing this.
Also, it seems that you support providing a 4x4 matrix in all cases where a transform is expected. This makes it difficult for us since jME stores all transforms as a translation / rotation / scale tuple, and extracting that information from a 4x4 matrix is non-trivial, especially for non-uniform scales. On the other hand, deriving a 4x4 matrix from translation / rotation / scale is much easier, if the engine prefers that format. Wouldn’t it make more sense to require all transforms to be stored in the separated translation / rotation / scale format then?
@Momoko_Fan said:
Also, it seems that you support providing a 4x4 matrix in all cases where a transform is expected. This makes it difficult for us since jME stores all transforms as a translation / rotation / scale tuple, and extracting that information from a 4x4 matrix is non-trivial, especially for non-uniform scales. On the other hand, deriving a 4x4 matrix from translation / rotation / scale is much easier, if the engine prefers that format. Wouldn't it make more sense to require all transforms to be stored in the separated translation / rotation / scale format then?
Self-answering this one…
When a 4x4 matrix represents rotation, scaling, and translation (even non-uniform scaling)… as long as the axes are orthogonal then the rotation, scaling, and translation can always be extracted rather trivially.
However, for non-orthogonal axes, the 4x4 matrix is the only way to represent them… and JME cannot support these kind of matrices anyway (and I’d suspect they are rare in the case this format would cover).
What is this feature’s state of progress? I’ve looked at @pspeed’s jogex and libopenddl. Where can I find an example demonstrating jogex with JMonkeyEngine? The OpenGEX plugin of Blender has been updated last month, I have to give it a try, it will be very useful for me if it can export all frames of the (keyframe) animations instead of only the very first one (unlike the Collada build-in export script).
I’ve kind of lost motivation on this one for a bit given that the open format isn’t really open by our standards. “Open” in this case only means “you can see the source” but there is no publicly facing source control, no publicly facing bug tracker, etc… so reporting issues found or keeping up with changes is less fun.
I really just wanted a reliable way to get models+animations from Blender into JME… and it looks like there may be viable alternatives for that really soon. (Work being done on a PEX(sp?) format as well is improvements to the FBX importer.)
)