Hah! A likely story. I live in the present, and right now, we’ve already got a file format that works after just a couple evenings’ work!
Loads more stuff checked in last night, awaiting comment.
Cas 
Technically, yes.
However, it’s a practical issue; fire up an XML editor for a file with 100 identical tags (different contents) e.g. 100 bones. Then try a file that organizes all the bones into a “bones” tag and see the difference ;D.
If XML editors were a LOT better and implemented intelligent heuristic-based folding (i.e. implying a “bones” tag where none existed) this wouldn’t be necessary. But they’re still a long way off.
blah^3 is right, it’ll be a pain to open the files in an editor if I don’t put some tags around the groups.
Cas
Assuming I can recover my HD data, and assuming I’m still sane, I can probably whip up a Milkshape->XML file converter without a problem when I get some free time.
Cheers, but I’d worry about recovering your final year project first if I were you… :’(
Cas
Have you got any example XML files yet? I can’t see them in CVS, but may be looking in the wrong place…
The loader and model format look fine to me, but the actual data in the XML file is what drives everything. That’s the bit that I like to see!
Is this is going to eventually reside in a supplementary lwjgl_util.jar, not in the main distro?
[quote]Is this is going to eventually reside in a supplementary lwjgl_util.jar, not in the main distro?
[/quote]
afaik, it will go in a lwjgl_util.jar package, but will in the main binary distribution.
Just a thought - how about a “static” model type, in addition to “bones” (“boned”?) and “meshed”? No animation section, just:
<model material="arbitrary_name" type="static">
<vertices>
<vertex x="0.0f" y="0.0f" z="0.0f" u="1.0f" v="1.0f" nx="0.0f" ny="0.0f" nz="1.0f"/>
...
</vertices>
<triangles>
<triangle a="0" b="1" c="2" />
...
</triangles>
</model>
Seems silly to require either a single frame with noop bones or a one-frame mesh, just to get a model that doesn’t have any animation - animated models are the exception rather than the norm, aren’t they?
If this is worth considering, maybe it’s time to bite the bullet and turn this into three separate documents - model-static, model-boned and model-meshed. You can then use tightly-defined DTDs, as the document structure won’t depend on the value of a CDATA field.
If you like the single-root approach, maybe model could support a single child element, either meshed, boned or static, which then contains the relevant data?
A second thought - face normals as an alternative to vertex normals. Cuts down on duplicated elements, if your normals are constant on each face. Not valid for meshed models, of course!
A third thought - maybe we should run with what we’ve got for now and see where it goes, then worry about a “2.0” after stimulating some interest and getting more than a handful of people’s requirements? ;D
[quote]You can then use tightly-defined DTDs, as the document structure won’t depend on the value of a CDATA field.
[/quote]
Cas quoted a DTD too. Is there any reason why it can’t use schemas, which are so much easier to understand :P?
[quote]Cas quoted a DTD too.
[/quote]
Yes, but the “tightly defined” bit is the important one. There’s no way in a DTD to specify that models with a type of “meshed” don’t define vertex elements inside a vertices element, but inside frame elements, for instance.
[quote]Is there any reason why it can’t use schemas, which are so much easier to understand :P?
[/quote]
DTDs are pretty damn easy to understand! But a little inflexible…
Not played with Schemas much myself. Aren’t they a little overengineered for this kind of thing? Great for ensuring that character data is in the correct format, but that’s what NumberFormatExceptions are for, hey? ;D