Implemented model material/texture import and reuse on model/scene load

[Gopmyc]

Description

This PR implements automatic material/texture import and reuse for models, both when adding a model to the scene and when loading a .ovscene.

Main changes:

• Added model material import pipeline in editor actions (Assimp-based).
• Generated assets are stored in per-model folders:
  • Assets/Materials/<ModelName>/
  • Assets/Textures/<ModelName>/
• Reuse existing generated materials/textures instead of regenerating when already present.
• Applied the same generation/reuse logic when loading a scene from disk (.ovscene).
• Refreshed Asset Browser automatically when new assets are generated.
• Synced regenerated materials across all scene actors using the same model (avoids stale pink/error materials).
• Fixed picking pass skinning detection to use drawable skinning descriptors (compatible with IMesh usage).

Related Issue(s)

Fixes #303

Review Guidance

• Drag and drop a model (.fbx, etc.) into the scene:
  • Actor should be created with generated/assigned materials.
  • Materials/textures should be generated under model-specific subfolders.
• Re-import the same model:
  • Existing generated assets should be reused.
• Delete generated materials, then re-add/reload the model:
  • Materials should be regenerated and reassigned.
  • Other actors already using the same model should update as well.
• Load a .ovscene containing models:
  • Missing materials/textures should be generated/reused and assigned automatically.
• Verify picking still works correctly on skinned meshes after the picking-pass adjustment.

Screenshots/GIFs

Checklist

• My code follows the project's code style guidelines
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes don't generate new warnings or errors

[adriengivry]

Thanks for submitting this PR!

I can see a few major issues with this work:

1. Assimp is being used directly in OvEditor. Implementation details related to model loading should remain hidden from the application behind the IModelParser interface. Additional model data (i.e., material and texture information) should be fully handled by the AssimpParser.

2. Project file pollution. This PR assumes that the user wants to place automatically generated materials and textures in Materials/{model_name}/ and Models/{model_name}/, respectively.

3. Imported materials and models collision. In some cases, if the user has multiple models with the same name in different folders, only the first imported model will properly generate materials and textures.

Ultimately, my vision for this feature is to offer something similar to what Unity does. I see models (FBX, OBJ, etc.) as “folders” that can be expanded to reveal all their embedded assets, including materials and potentially textures, if any.

These embedded assets would be non-modifiable, as they would be generated when the model is loaded. They could then be dragged and dropped anywhere a material or texture is required. Paths for embedded assets could look like:

path/to/model.fbx:embedded_material.ovmat
path/to/model.fbx:embedded_texture.jpeg

In the model asset properties, we could add a toggle (above the model parsing flags) to determine whether embedded materials and textures should be generated.

This would also require updating the PropagateFileRename implementation to properly handle embedded assets.

Once this is fully implemented, I believe the “Generate materials” option in the model contextual menu could be safely removed.

The final step would be to add support for externally linked textures. Some models reference textures using relative paths, and it would be beneficial to support these as well. Generated materials should be able to reference linked textures correctly.

Given the scope of this work, I understand if it’s not manageable for you at the moment. We’ve postponed this effort for many years because it’s fairly complex and has a lot of dependencies.

[Gopmyc]

Challenge accepted

[Gopmyc]

Thanks for submitting this PR!

I can see a few major issues with this work:

1. Assimp is being used directly in OvEditor. Implementation details related to model loading should remain hidden from the application behind the IModelParser interface. Additional model data (i.e., material and texture information) should be fully handled by the AssimpParser.
2. Project file pollution. This PR assumes that the user wants to place automatically generated materials and textures in Materials/{model_name}/ and Models/{model_name}/, respectively.
3. Imported materials and models collision. In some cases, if the user has multiple models with the same name in different folders, only the first imported model will properly generate materials and textures.

Ultimately, my vision for this feature is to offer something similar to what Unity does. I see models (FBX, OBJ, etc.) as “folders” that can be expanded to reveal all their embedded assets, including materials and potentially textures, if any.

These embedded assets would be non-modifiable, as they would be generated when the model is loaded. They could then be dragged and dropped anywhere a `material` or `texture` is required. Paths for embedded assets could look like:

path/to/model.fbx:embedded_material.ovmat
path/to/model.fbx:embedded_texture.jpeg

In the model asset properties, we could add a toggle (above the model parsing flags) to determine whether embedded materials and textures should be generated.

This would also require updating the PropagateFileRename implementation to properly handle embedded assets.

Once this is fully implemented, I believe the “Generate materials” option in the model contextual menu could be safely removed.

The final step would be to add support for externally linked textures. Some models reference textures using relative paths, and it would be beneficial to support these as well. Generated materials should be able to reference linked textures correctly.

Given the scope of this work, I understand if it’s not manageable for you at the moment. We’ve postponed this effort for many years because it’s fairly complex and has a lot of dependencies.

I understand the direction and I agree with the overall idea, especially the Unity-like approach with embedded assets and keeping things clean through the parser.

That said, I don’t think it makes sense to include material generation and the embedded asset view in this PR. The scope gets pretty large and touches a lot of different parts of the engine (asset system, file handling, UI, parser responsibilities, etc.). To keep things clear and easier to review, I think it’s better to split this into multiple smaller PRs.

For now, I’ll focus on loading materials virtually through the parser and assigning them to the models at runtime. This should already improve rendering quality and material support, without polluting the project’s asset folders or introducing persistence/UI concerns too early.

Once that part is solid, we can move forward with separate PRs for embedded asset handling, optional generation, rename propagation, and support for external textures.

I’m going to reopen this PR and continue working on it with this scope.

[adriengivry]

@Gopmyc

Yep, this is a pretty massive change. Totally agree about breaking it down.
Could you explain more in detail what you mean by:

For now, I’ll focus on loading materials virtually through the parser and assigning them to the models at runtime.

[Gopmyc]

@Gopmyc

Yep, this is a pretty massive change. Totally agree about breaking it down. Could you explain more in detail what you mean by:

For now, I’ll focus on loading materials virtually through the parser and assigning them to the models at runtime.

Great question.

By “loading materials virtually through the parser”, I mean:

• no .ovmat / texture files are generated on disk in Assets/;
• AssimpParser extracts embedded material/texture data and stores it in the Model resource in memory;
• these are exposed through virtual paths like model.fbx:embedded_material_0.ovmat and model.fbx:embedded_texture_0.png.

Then, “assigning them at runtime” means MaterialManager / TextureManager resolve those virtual paths on demand, and renderer components assign them automatically when a model is loaded (or scene deserialized), especially for empty/default slots.