It strikes me that most engines seem to use different model formats for different purposes; one format for static objects like buildings, and another one for animated objects like characters. As I can see it the reason for this is that there's no point in storing, for example, joint data in a rock-model.
This makes me ask if letting the jme format be all-defining is the way to go?
Well my opinion is, yes it should.
Everything should be optional though.
This will keep the format very flexable and you can just load use stuff if it exist.
This is just my opinion.
Yeah, from the other point of view there is a point in this – after all all models loaded in jME have a lot in common; being built-up by meshes and should adopt to the scenegraph…
well, technically, you don't store unneeded data in .jme. If the model has no joint information, no jointmesh tags are used. So, the rock model would only contain entries for vertices, normals and textures. Almost all the tags are optional in the xml spec (which needs to be documented 
).
I kind of guessed this was how it was… what makes me suspicious is why other engines doesn't take this approach? Or do they? I don't base my assumption on that a great number of cases…
but If things are given there own format different models can access an instance of one or couple .phy or anim file I say this because .jme can be a bit "heavy" depending on what you export. I personally use the same skeleton for three different
models because its alot of animation and the characters have similar fight styles.
That's it! Or at least a very good point – in a game with tons of characters having a lot of animations in common, you want to share such things in a clever way.
as a side note consider that the md5 stuff is part of an model animation system that was intended to suppliment or replace the the existing one, has I believe ported ms3d and there's an mdx loader in there as well. just a heads-up if didn't already know
md5 is a really interesting format, and today is supported by a lot of packages, like *.x(still more widely supported)
But I suppose md2 or md3 would be better for performance in very low machines, am I wrong?
Anyway, it'd rock to have md5 or x available.
(this all thinking in the compatibility with 3d packages, I don't see it important if internally the format get converted or not to jme format)
I'm a noobie here, but I thought I'd throw my opinion out if anyone cares to hear it.
What if the .jme format were to be all inclusive but when you are loading for a model you could load from multiple .jme files or just a single one. This would give the capability to separate out common skeletal structures, textures, etc. but in other cases you could have an all inclusive .jme file that could have all in one?
Maybe it's silly but I just try to think of it from a Java perspective. I mean, in Java you can have one class that has everything in it or you can have several classes to provide abstraction but it's up to the developer not imposed on you.
Thanks,
darkfrog
darkfrog said:
I'm a noobie here, but I thought I'd throw my opinion out if anyone cares to hear it.
What if the .jme format were to be all inclusive but when you are loading for a model you could load from multiple .jme files or just a single one. This would give the capability to separate out common skeletal structures, textures, etc. but in other cases you could have an all inclusive .jme file that could have all in one?
Maybe it's silly but I just try to think of it from a Java perspective. I mean, in Java you can have one class that has everything in it or you can have several classes to provide abstraction but it's up to the developer not imposed on you.
Thanks,
darkfrog
well darkfrog for clarity I'm better artist than programmer so for example taking a file with animation only, subseting and manipulating it to use many meshes, sounds alot less daunting than doing "surgery" on large .jme files to extract animation data, added to that .jme was designed to 1 to 1 with the xml so depending on what you export the size difference isn't all that significant.
The way I propose you would be able to do it either way…if you want to have it separated for clarity into multiple files that's fine. The major difference is that the .jme would be able to handle any types you gave it…you can have all of them in one XML file or everything in individual XML files. The only headache is a large .jme file specification instead of several smaller ones.
Thanks,
darkfrog
I think darkfrogs is right here. If someone has the time the .jme-format-stuff could be a little bit polished to allow library/application specific extensions (edit: and the proposed file composion of course) …
This way phyiscs-, ragdoll- and other stuff could be stored in jme-files without putting such stuff in the jME core.
amen brother!