Virtual file system - simplifying loading meshes and texture/pictures

I would like to suggest that you created a virtual file system for jME, for loading meshes and textures/images.


  1. Simplifying loading, and adding of new meshes.
  2. Optimizing ram or cpu usage for specific purpose.
  3. Not touching the core code.
  4. Should have the possibility to get a copy of a mesh.
  5. Expendable by loading from other zip files, and possibly other self encoded files.
  6. Independent of the OS.

    The main class should have some sort of tree, a bit like Nodes where you can attach another node, which can have another node etc.

    The meshes should have possibility of having information about texture, states, names, bounding model, etc, in a external file or some sort of.

    I would like to see a architecture a bit like this one.

public class VirtualSystem extends Node {
    // Gets a mesh or a mesh that holds other meshes.
    public VirtualSystem getMesh(String name) { .. }

    // Same as <code>getMesh</code> except that it creates a shared mesh.
    public VirtualSystem getSharedMesh(String name) { .. }

    // Loads a file system, zip, or some other file into this VirtualSystem.
    public void load(String path, boolean loadnow) { .. }  // If loadnow is on, it loads all classes in the ram, else it will wait and save the files it have loaded.

ram cpu

this way it would be lot easier to program big code. Example
Load a player, copy it five times because there are other players which have the same mesh - Texture is automatic loaded so you wont have to worry about that.

// Creates a file system.
VirtualSystem filesys = new VirtualSystem();
// Load all possibly files from the same directory.
filesys.load(".", true);

for (int i = 0;i < 5;i++) {
  Node player = filesys.getMesh("models").getSharedMesh("malecharacter");
  // also think of this approach - Node player = filesys.getSharedMesh("models/malecharacter");
  switch (i) {
         case 0:
         case 1:
         case 2:
         case 3:
         case 4:
            player.setName("Teaster"); // this idiot gonna lose :P
  // add it to a normal node.

this is very pseudo code, I hope this piece of code explains how much time on coding you could use otherwise if this was possibly.
And I am not saying that it has to include all features like zip files, and other binary files, a normal file system would be good to have, but it would also be nice if it could be extended so that you could use zip files, rar files, and other files which is encoded in some way.

The way the architecture is created is very pseudo, if you wanna take this challenge you properly want to change a bit in the architecture and that is all fine by me, as long as it will be expendable by other file formats or file systems.

I hope this is a wanted feature not only by me but also others, since this will simplify anything about the loading system.

Please response with idea's on how to create this virtual system.

A hoping Teaster 

Great ideas! A virtual filesystem could be a central place to store all the resources and have well defined contracts to search for them. Also it's a straightforward and intuitive concept.