One format to rule them all.
I was thinking, I really don’t like the current scheme of model loading we have in jME. What I was thinking is we only support a single model format (probably a custom format in XML or something). jME only loads this format and loads it well. We have too many “kinda works” loading going on now. So, this model is loaded perfectly and tested heavily. So, we would then have a supported model type (monkey format or something), that we guarantee will work.
THEN, all we write are exporters. Programs that convert existing formats into our format. Maybe in the future writing plug-ins for individual model applications.
This is related to a javagaming thread I saw and a couple comments to that effect.
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=share;action=display;num=1078652098
That sounds like a good idea and could have several benefits. I wouldn’t mind steering that effort since I don’t have an assigned niche yet.
Couple questions:
- What’s the time frame we are looking at?
- Is there a base model type we all like that we should model ours after (feature wise)
- XML or not to XML?
- No huge rush, but definately before 1.0, and hopefully and early running version by 0.7. However, nothing hard and fast about it, as long as it’s done right, I can wait.
- Maybe we should simply list the features (requirements?) of the model format, because, to tell you the truth, I’m only familiar with a few model types.
- I’m leaning towards XML, because we could then have a defined schema and quickly check if the file is valid or not. I’m by no means an expert in this area though, so if someone disagrees, please say so.
Ok…
Features (just getting them out, we can then discuss and flesh out each one).
-needs to basically represent our same Node structure that is used in jme. So allow a parent/child relationship between parts of the model.
-needs to at least suppport: vertices, colors, normals, textures, indices. These should be organized the same way TriMesh is, i.e. vertex’s color is color, normal is normal, etc.
-should allow for support of things such as multi-texturing, environmental mapping (after implemented), etc.
-Animation, skeletal animation with skinning is needed (similar to milkshape?), I’d also like to support regular keyframe animation (MD2). How do we cleaning do this?
-Materials and texture. Allow the texture state and material state to be loaded from the format.
-Bounding volumes. Should these be in the model itself? Just an idea, one I’m not sure I like.
-What else???
Hmm, thinking more on this, what do you think about this posting in the thread you mentioned: (reply#5)
Exporters increase the number of formats that a given importer can use. However, they do nothing intrinsically to let you use any of the esoteric features of different exporters, unless you have an intermediate format (i.e. your XML *Schema* [...death to DTD's!]) which has *all* the features of *all* formats, and...if you can load it!. If you can write it, great, but it seems pretty tough going AND you're in serious danger of merely shifting the difficult part from "reading arbitrary formats" to "interpreting an incredibly complex format that includes *everything*".
Right, I saw that and I agree with it. That’s why I think we need to be careful about creating a format WE want to use. That is, lets make sure our format is right for us, rather than our format can do everything. The exporters will then have to just throw out those features that we don’t support.
For example, Maya and 3DS support lights in the model format. I don’t particulary see a need for that. So, our format won’t have lights… etc.
I am doing some "tekken 4" quality stuff for my idea. I had liked .ase, 3ds simply because I have max and could export my work exactly the way I want them to look i.e
loading my models with "stunning" detail or close to it as possible without killing jme.
at this point in time am I more interested in the look
how might a custom format affect what I want to do in terms of the LOD it will support.
p.s md2 is ugly!!! and have played quake2 enough times to know… UGGLY!!!
Great, we can always add to our format as the need arrises.
Does speed in loading the format matter more than the flexability of XML?
I am doing some "tekken 4" quality stuff for my idea. I had liked .ase, 3ds simply because I have max and could export my work exactly the way I want them to look i.e
"stunning" detail or close to it as possible without killing jme.
at this point in time am I more interested in the look
how might a custom format affect what I want to do.
This is where the exporters would come in, there would be a tool that would convert your ASE models in the custom model format. But perhaps not all the data defined, that's where you need to let us know what model features you require.
But, out of curiosity, since we are talking about needed features, what do you need? What type of animation do you use, etc?
Does speed in loading the format matter more than the flexability of XML?
This is a good question, what is the speed difference? Will it cause a problem later?
There will be some overhead related to XML parsing, but I suppose unless you plan on loading many models a second, it should be negligable.
Then I’d say XML is the way to go for now. Simply because we then have a lot of tools at our disposal.
I was thinking about the saving a scene as our custom format (i.e. the scene is just another model). This would require that the model format support all of jME’s Render States. Is that a good way to look at the model? It has to support all states within the renderer?
Wonder if we should then add a method to our states and other scene related classes that can return itself saved as xml? I do that in my financial apps with good success. Alternatively, we could try to use introspection to examine an object and save it to xml. Or write a util that knows how to save certain object types.
That’s a pretty good idea… perhaps load via an xml string as well?
I was also thinking about bounding volumes. Do we define these in the model or build them after loading?
right, ability to save themselves to an XML String/Stringbuffer and the ability to load themselves from an XML String / Stream, or the like.
As for BoundingVolumes, I’m undecided… If the application uses specific bounding types then we’d need to save them for completeness. If we have a default type that can’t be changed, then they could be reinstantiated on model load without needing to read them in.
Howdy,
I’ll through my 2 cents worth in. 
Last year I developed a prototype modeler in Java. I used an XML Schema to define the data structure and Castor http://www.exolab.org to generate the Java code from the schema.
I liked doing it that way but I don’t know if the Castor license is compatible with ours. It wasn’t particularly fast but it was very easy to change the data structure and re-gen the code. It might be something to check in to.
I designed my data structure (XML Schema) to accomodate persisting an entire scene graph or just parts of it.
Although I never got beyond persisting models it should be possible to design a schema that can be used to persist entire scenes (game levels), including models, lights, animation, materials, etc.
Or it can be used to persist parts of a scene, i.e. a single model, a material, an animation, skeletal info, the list goes on.
I plan to develop a modeler and ultimately a level builder on top of jME and it would be cool if I could persist an entire scene graph or just the parts I want.
Gregg
Thanks, Gregg. Make sure you give your 2 cents every chance you get. Since you are wanting to write a modeler you will be directly affected by this. With luck, saving your models could be as simple as calling root.save("filename");
(I’m beginning to think this whole “work for a living” thing isn’t so bad, especially if I can have a discussion like this during the afternoon! :P)
I think this is definitely a step in the right direction. A universal jME model format based on XML sounds like a great idea.
A few thougts:
- We should certainly support mutiple animation types. Skeletal animation, keyframe animation, etc. are all useful in different circumstances. I could see distinguishing between them being as simple as using a tag like <animation type="skeletal" .../>.
- Offer an option to ignore render states when saving model data. Same thing for bounding volumes. A simple flag to regenerate them if they're missing when the model is loaded seems simple enough.
- I could potentially see complex model/scene files becoming extremely large. Should we consider some form of optional compression?
[/list:u]
I am modelling my humans nude and anatomically correct much like the japanese do it and then the costumes/clothes as seperate meshes since my idea depends on changes in look in different levels. what worries me is how the loader interprets this one file will have multiple meshes and textures to handle. aesthetics is my thing especially when it comes to my female models, I like greggs idea "plenty".
note that I am speaking from a graphics designers perspective
am still learning java and jme
p.s. both keyframe and skeletal animation support would be good
The loader will be able to handle multiple meshes in a single file. Each entry in the file with a mesh tag will be a seperate TriMesh. We should probably allow for meshes to be both siblings to the main model, and children meshes of parent meshes. But definately, multiple meshes should and will be supported in a single file.
Just thought Id drop in a line and say my 2 pence.
I have written an XML "model" loading in XML for java2D. Although it is only 2D it does allow for animation and key framing.
Although its a simple "remove this frame, and draw in the next in the same place" I think it would be useful.
I forsee one problem with this. We need a person who knows MaxScript, whatever Maya uses too. Perhaps we could all learn it?
Il post the XML file when I go home in around four hours.
Perhaps allow for the use of effects in the loader as well? Fire eyes?
I forsee one problem with this. We need a person who knows MaxScript, whatever Maya uses too. Perhaps we could all learn it?
Why? It's just another format for someone to write the exporter.