I was wondering if there was any why that I can help develop jme. Is there any task needed that no developer is working on?
If Cep21 dose not return I would be willing to take over developing the .jme format. I think I can significantly shrink the format.
Its great that the models are becoming more finished. XML or .jme im not fussed ( really im not :D)
One thing that might be nice is if one of the textures in a model could be altered at runtime, eg run3d quake man may not have shaved for a while and his hair gets a little ruffled.
I wanted to shrink the file format size by using numbers instead of commonly used strings. There are a bunch of strings that are repeated in the format. Words like
Cep was here as guest not to long ago discussing and fixing some problems.
Hevee seems also interested in extending the format on the skeletal front and i remember darkfrog also discussing this a while ago.
Maybe some of You guys can gather up and build a .jme format taskforce 
a taskforce…that sounds exciting…can we get matching uniforms and everything? :-p
darkfrog
darkfrog said::D
a taskforce....that sounds exciting....can we get matching uniforms and everything? :-p
Sounds like a good idea, even if we don't get any jME labeled uniforms, which would certainly be cool.
I have recently made some amendments (is that word actually used this way?) to the XML loading code (to be committed around this week's end), which is very closely related to the binary loading mechanism, and had some ideas.
I was thinking of asking Cep what he thinks of trying to change the complete xml/binary architecture to something more like the Serializable interface, where Objects bring their own methods of (de)serialization. In a quite limited way (no child nodes*), XMLWritable already provides that, so a first attempt could be making the changes needed to make XMLWritable support child nodes.
The huge advantage of this method would be that any new class would have it's own read/write methods, so if somebody would like to have their custom classes stored in a .jme file, that would be possible with no changes to the existing jME code at all, PLUS changes to existing classes or new classes added to jME would have the code that needs to change to reflect the updates right at hand.
At a first glance, it doesn't look to hard to do, but probably there are some obstacles to overcome on that path I haven't yet thought of.
--
* "nodes" as in the DOM, not jME-Nodes
Good plan, static ints
Well feel free to write a test of course 
If people would want a smaller size for their model they could just compress it (eg. load it from inside a jar). Normal ZIP compression will do similar things to what you suggest, and then some more. Your suggestions might add a little bit of extra compression though… and who knows, maybe they'll speed up loading too?
If you're gonna evaluate different techniques, maybe you could also take a look at xml compressors (there are a few available written in Java). Those provide good compression and faster loading too.
In my opinion XML is a really bad choice for model loading at all: DOM eats too much memory and is slow (regardless on implementation) - don't ever use it for large amounts of data! SAX is still very slow - don't use it for models! Own parser - no comment…
The only advantages XML really has are: human readability (to some extent), somewhat evolution resistant
The first advantage falls if you somehow compress that XML into binary files.
My conclusion: think about using Externalizaion (see Externalizable interface) probably with named attributes (can be that ints from a table).
Dom from memory loads up the whole file into memory first to validate teh format, not sure if implemenations have changed ( IBM once had one that didnt ), sax just seeks over the surface of it
Irrisor, I have to disagree: IMHO, the major benefit of XML in almost all reasonable applications is interoperability, and that's a very good thing to have as an import format. Human readability seconds this very closely. Personally, I don't think of the xml format as the format you would use when deploying your game, that's what the binary format is for, which is
- a) binary->faster loading, and smaller file size, and
- b) one-to-one related to the xml format, which means that you can easily gain back human readability if you have to (for debugging, for instance) by just converting it back.
My conclusions:
- XML is needed, and important, when importing from third party software. Which almost any jME-based game will have to do. Having XML for data exchange between different applications is exactly what XML is designed for, and it does a very good job at that.
- The binary format is equally important, it loads faster, and produces smaller files. Having it closely related to the xml format greatly reduces debugging effort for not only both formats while re- designing their loaders and writers, but also makes it really easy and failure-safe to convert between them.
If we want a 1-to-1 relationship of xml and binary formats, however, that makes using the Externalizable interface, if I understood it's workings correctly, hard to use in our case. Anyway, being an Interface, it does not provide any loading/saving mechanisms by itself at all, but merely defines two methods you can use to call your own, self written loading/saving code.
That is currently provided by the XMLloadable Interface, and nothing is to be be gained by changing just the Interface that defines the method names. In fact, the XMLloadable Interface could in future versions be adjusted to better support hierarchically organized data structures (like scenegraphs), which we can't do with Externalizable.
As for the DOM drawbacks:
kidneybean, you are absolutely right about DOM loading the file into memory, and even worse, as Strings, that is. And SAX does so, too, one String after another, using the same amount of memory (minus some DOM Node overhead), until GC is invoked (at least I assume that for most implementations, please tell me I'm wrong if I am).
However, if used "correctly" (IMHO), the XML format's priority is not time/memory efficiency, but ease of use.
No XML loading/processing implementation, DOM or otherwise, can ever be as fast as the current binary loading mechanism. So, user's won't want to use XML as their deployment storage format, anyway.
So, if the XML format's priority is ease of use, not time/memory usage, there is much to be gained from switching to DOM (I won't go on on that, my posts are always far too long anyway. If anybody wants to know what I mean, please ask!)
hevee said:
XML is needed, and important, when importing from third party software.
XML can help with exchanging data between applications, yes. But that's not what I was talking about. I think, we are talking about the binary format here. And my suggestion was not to derive it from the XML format. The benefits I listed were targeted at a deployment model format.
In fact, the XMLloadable Interface could in future versions be adjusted to better support hierarchically organized data structures (like scenegraphs), which we can't do with Externalizable.
Besides the visual representation there is no advantage regarding hierarchies in XML. You can support hierarchies with Externalizable, too. (Of course you are right, Externalizable is only an interface - an idea - not an implementation)
So my actual point was: To get fast loadable - thus small - files one should not take XML as basis for anything.
This definately has to be weight up with ease of use and maintainability aspects.
irrisor said:
In my opinion XML is a really bad choice for model loading at all: DOM eats too much memory and is slow (regardless on implementation) - don't ever use it for large amounts of data! SAX is still very slow - don't use it for models!
You got me wrong, I think: I was not trying to suggest using any kind of XML processing on the binary data when loading it. Are you familiar with the current xml/binary relationship in Cep's code? The binary loading/saving classes do exactly what an Externalizable implementation would do: they write out all relevant data for a class in binary form. In fact, in a typical Externalizable implementation, you would have to call exactly the same methods, resulting in a very similar file, but with hierarchy information to be restored from some custom data structure. I actually think that this "Fast Infoset-like" way of doing things, with hierarchy information implicit in the file's structure, is a very small amount faster, and more storage efficient, than having to write/restore hierarchy yourself.
Please, could you elaborate more on the impact an implicit hierarchically ordering of data structures would have on loading time/storage efficiency, and what causes it?
There is no need for any extra info on hierarchy, Hevee - what do you mean? For loading/storing performance hierarchy does not matter at all - it's storing references one way or the other, that's it.
And yes, I am familiar with the current binary load and store mechanism and it's not exactly like the usual way one would do it with Externalizable (e.g. Serializable). Of course there are similarities. I think there's a lot of improvement potential for Badmi, if he chooses to tackle that
I wont bang on about it much again.
The obvious ( and undisputed ) drawback of loading with xml is that its a second conversion which is pure overhead - the first conversion is putting all the data into the node/spatial which has to be done anyway. It would be nice if the option of and/or is a working solution.
But - something that works is better than something that doesnt work. Im pleased you are making progress with cep.
kidneybean said:
Im pleased you are making progress with cep. :D
Well, don't get too excited about it. Today, it's ten days since his last sign of life, which was promising that he would commit some bugfixes last sunday... Maybe I scared him off by asking too many questions after that.
EDIT: Just to let you know, Cep has not vanished or something, there is some communication going on currently.