So maybe ther third option I pointed out would be best in this case ?
I can do something like this:
Move the functionality of BlenderModelLoader to BlenderLoader (the second name is simply better in my opinion)
Deprecate BlenderModelLoader and make the class only extend BlenderLoader (so that it does the same).
The BlenderLoader the loads the whole scene and all objects are attached to the result Spatial (which would be the root of the scene).
Add option to the BlenderKey: boolean loadUnlinkedContent; which would be false by default (or true if you find it useful to use blender file as asset store).
If the loadUnlinkedContent is set to true - then we could add a map to the result’s user data. Its keys would be like: “objects”, “materials”, “textures” and so on and the values would be lists of all those features.
Get rid of LoadingResults class - which might not be needed anymore (or deprecate it in case enyone was using it).
I can of course put the references of every loaded data there so that someone might use it as a reference of all blend assets stored in the file. Or we can make another option in BlenderKey that will allow to decide if we should store all data there or not.
Of course the objects that are in the scene are attached as children to the ‘loadedSpatial’ so simply attaching it to the rootNode of the jme scene will be enough to see the loaded data. But some data (espatially linked features) cannot exist without objects so that is why I would need array support.
It would not need to be List. Simple java array will suffice.
Or if anyone have better solution just pleas tell me.
Yep, thats a generic requirement for model/asset importers @pspeed…
One could say that this isn’t exactly a use case where this would have to be obeyed though but @Kaelthas already found a solution that can do both so I think its fine. In the end the loader isn’t supposed to load anything foreign to jME anyway.
Since you need to have jme3-blender in the classpath to load .blend files, that means the application performing the loading will have access to your custom Savable class. All you gotta do then, is disallow exporting that Savable implementation - in the exception thrown, you can ask the user to clear the unlinked objects UserData prior to saving the model.
Since the importer/exporters can already deal with Lists as I recall, I’m not sure we’d need a whole implementation just to wrap stuff. Perhaps the same stuff that internally deals with primitives in UserData can accept lists/maps and then they get dealt with on the save/load side.
…seems wasteful to have a whole SavableList class just because of an instanceof check.
A more general solution for what problem? The only problem is putting lists and maps into user data. There is no more general solution to that than to support lists and maps in user data. SavableList and SavableMap is I’d say less general.
Its not “will it support it”, someone has to actually add support for it, and I guess in this case it is you
Can you add additional types in the UserData class to support lists, maps and arrays? Should be fairly straightforward …