Ogre importer: Fix for material sharing

[riccardobl]

Fix for the issue reported here: https://hub.jmonkeyengine.org/t/ogre-importer-materials-are-not-shared/35663

Short description of the problem:
We have an Ogre's .scene with two spatials that share the same material.
When this scene is imported in the engine, the two spatials no longer share the material but, instead, they own a new instanced of it.
This happens because the SceneLoader loads the objects through the assetManager as if they were unrelated, the assetManager calls clone(true) on the cached models before returning them, this cause the issue.

This patch loads the models directly with an instance of MeshLoader opportunely extended to have an internal cache that is preserved until the scene is fully loaded.

[empirephoenix]

Looks fine to me, merging

[normen]

Whats the purpose of sharing the material? It doesn't accelerate rendering, the size of the material data is negligible because all referenced data like textures and material definitions are shared anyway and this change will cause all instances of the material to be changed when you change one (e.g. you want to tint one model blue and the other red)?

[riccardobl]

Whats the purpose of sharing the material?

Batching, instancing, everything that need shared materials to work.

and this change will cause all instances of the material to be changed when you change one (e.g. you want to tint one model blue and the other red)?

This is the expected behaviour for shared materials, if you don't want it, just clone your material like you would do in any other software.

[empirephoenix]

I think you two have a misunderstanding.
I can on the ogre side explicitly share a material, but the current jme loader ignores it, and does not share it then. This is useful for stuff like a city with different weather based flower/tree ect textures. This basically only adds the missing feature to jme, it does not share all materials if possible, only if requested on orgre side.

[normen]

Batching and instancing look for the actual parameters, so even if the material is not the same object - if the parameters are the same they will be batched.

[pspeed42]

Yes, but the point is that if the imported file specifically has shared materials then the user probably did that for a reason and we shouldn't undo it. Anyway, MPOs sort of get rid of the last reason to leave them shared.

[riccardobl]

Batching and instancing look for the actual parameters

This is not the impression i have from the code....

https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/scene/instancing/InstancedNode.java#L88

https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/tools/java/jme3tools/optimize/GeometryBatchFactory.java#L314

[pspeed42]

In the second case, normen's comment is true... see:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/tools/java/jme3tools/optimize/GeometryBatchFactory.java#L323

But yeah, InstancedNode is not as nice this way.

[empirephoenix]

There are way more reasons than just batching.

For example a scene of a house, with 3 different textures(atlas) that can be changed by simply switching the diffuse in the material.
If it is shared this is way easier done for complex scenes than with separate ones.
For example something like this https://www.assetstore.unity3d.com/en/#!/content/19469 would be such a case. eg. apocalypse game with before and after doomsday parts.