I just wanted to make a suggestion on coding style for the JME3 and what could be implemented so that it’s extendable to all. It seems one feature that JME2 lacks is a solid content pipeline, hence the numerous and different importers that are implemented in so many different ways. Looking at XNA, which is like JME, but in C# and uses DirectX, I like how they use generics to give what kind of resource they’re loading. Whether Model, Texture, Font, or Sound. Idk what I’m really saying, but I thought it might be nice to take a look at an approach such as http://msdn.microsoft.com/en-us/library/bb197848.aspx.
I personally have a love-hate relationship with the content manager in XNA. For stuff like shader effects, textures, sounds, its nice because it manages instances of loaded content. E.g. it's easy to share instances.
But this can be problematic for model information. Their own model format I find is very inflexible, and it's not terribly easy to clone. And if you build, say a jme-like scenegraph ontop of XNA and your models are more of a collection of nodes and meshes, it can be very annoying importing that sort of thing since you only ever load one instance of those spatials.
Also, for the content processors, you pretty much define properties of how content should be imported before compilation within the IDE - this makes things a bit problematic if you want to dynamically import models at runtime (although its certainly possible), and the Content.Load<T> doesn't really allow to pass parameters to the processors either. Very different from what jme does, although the binary format is very similar to how jme's binary format is done. Honestly, in my own work, I'm thinking of bypassing the content management system for XNA on some things and just going with plan old serialization (much like the jme system), at least for the loading aspect. Having to write content readers for everything can be a bit annoying.
So, yeah a more unified content loading for jme would be interesting, but the XNA one was designed with some different goals in mind it would seem.
What you're talking about has been in jME3 for a long time already. See com.g3d.asset.AssetManager class.
Generics cannot be used since that information is stripped at compile time. Instead the type of resource is determined based on the file extension.
There are a few other features of the asset management system worthy of mentioning:
- Multi-threaded loading
- J3P format, or JME3Package. Used to efficiently store resources (like a zip file). It uses one of the most powerful and efficent compression formats, LZMA.
- Unused resources are automatically garbage collected if memory is low.