GltfImport confusing?

[andypoly]

hi working on runtime import with customisation I found this class a little bit confusing (but that might just be me) - it is an import class, but also a kind of model-data class - 1 per model required - if I understand correctly.
So GltfImport imports a model, but then you need to keep it around as it has meshes and textures or something in it that are destroyed if the Dispose call is made, so you can not instantiate a GameObject and then dispose it?
And maybe you keep it to instantiate the model multiple times in future anyway (though is that preferable to making and hiding a GameObject in the scene to instantiate further from?)

If above is right then you might need GltfImport as a model data class, something to cache per model loaded to then create GameObject instances from when you need them in scene.
Is the 'Import' name confusing?

(I initially thought it was a single-instance type thing that you would use again and again to import models, but it is for one model)
sorry for spamming my thoughts - this is not a rant, just checking I understand things correctly and if there was any particular reasons for names!!

Kind of links to #402
This class is not just an importer and holds references to things. You must call Dispose when done with GameObject/Model

[atteneder]

So GltfImport imports a model, but then you need to keep it around as it has meshes and textures or something in it that are destroyed if the Dispose call is made, so you can not instantiate a GameObject and then dispose it?

Correct

And maybe you keep it to instantiate the model multiple times in future anyway (though is that preferable to making and hiding a GameObject in the scene to instantiate further from?)

If you tried to ask: Isn't making a deep clone of a first instance's GameObjects better than making another instance? Honestly, never tried/compared. I assume it comes with different problems (like unwanted copying of states; e.g. animation). Feel free to do so, but I see no reason to change the multi-instance API in place.

If you're saying pooling instances (instead of destroying and re-instantiating) is a good idea, then I agree.

If above is right then you might need GltfImport as a model data class, something to cache per model loaded to then create GameObject instances from when you need them in scene.

Yes, GameObject OR Entities instances.

Is the 'Import' name confusing?

Apparently it is for you and I kind of see why. What would you name it? (Disclaimer: I'm not seriously consider renaming it, since that would break the API. But docs could be added/improved, so I'm curious about the input/discussion).

Admitted, this class has grown over time, is far from being well structured and overdue for a refactor.

(I initially thought it was a single-instance type thing that you would use again and again to import models, but it is for one model) sorry for spamming my thoughts - this is not a rant, just checking I understand things correctly and if there was any particular reasons for names!!

I cannot follow. Why would the suffix Import imply (or not imply) that this is about a single-instance?

Would it make more sense if the Import would create another object, let's call it Factory that allows you to make instances?

So you have trouble to comprehend that GltfImport has multiple functions/purposes, right?

I still don't know what to make out of this :) It would be great if you could formulate concise statements about observations and solutions you have.

[andypoly]

Thanks for answering - I was thinking out loud, though I do now understand it all and am using this great library!
I guess import can mean 'import something' (verb) or 'an import' noun, so at the beginning I thought, oh maybe you go model = GltfImport.Load("model1"); model2 = GltfImport.Load("model2"), but this is effectively a class with both those meanings - it does the import and it holds the import!!
OK you can delete this thread now! :)