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.
Looks like I came accross one problem.
Spatial’s ‘user data’ does not support arrays.
I intended to store the loaded content in arrays so that it can be easily accessed.
And then the access to different features loaded from the blend file would be like this:
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.
@Kaelthas
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.
I could use ‘loadUnlinkedContent’ option from BlenderKey here.
This option would be set to false by default. In this case nothing would be attached to the result spatial in the user data.
I can use it internally for loading links from another blender file.
The SDK would get only data attached to the scenes and if we were to use the blend file as an asset store, then we can programmatically use the custom Savable then.
How about that ?
On the other hand, adding
public final class SavableList extends ArrayList<Savable> implements Savable {
// ...
}
to the jme core would come in handy not only for the importer
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.
OK guys so what is the conclusion here ?
Will UserData have the support for lists and maps ?
@pspeed
I ment that savable lists and maps would be stored in spatial’s user data and used somewhere else for other purposes.
Maybe I did not make myself clear
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 …
No, you were clear enough… apparently I was not. I will attempt to be clearer: The number of other use cases for such a class is roughly 0 plus or minus 0.