Formalized the concept of an model's material slots
Before, the ModelAsset and MaterialComponent code was conflating the idea of a material slot ID and a default material assignment. The default material asset's sub-ID was being used to uniquely identify the material slot as well. This blocks our ability to use other materials as the default assignment for individual meshes; we are forced to use whatever material that was generated from the source model file (like FBX).
With these changes, we separate the concept of a material AssetId and a material slot ID, and store them separately. There is a new ModelMaterialSlot struct to describe each slot, including a unique "StableId". The ModelAsset stores a map of the slots, and each mesh refers to a slot by its StableId.
This is a precursor to another task that will optionally disable the auto-conversion of materials from source model files.
Also:
- These changes also enable material property overrides without having to make an editable material first, which I don't think was supported before.
- Removed unused Default.materialtype from the RPI Assets folder.
- Encapsulated members in EditorMaterialComponentExporter::ExportItem for better maintainability.
See also https://github.com/o3de/o3de-atom-sampleviewer/pull/175
Testing:
- Took screenshots of several AtomTest levels with material overrides before making any changes. Compared these after the changes. Test levels included ActorTest_SingleActor, ActorTest_MultipleActors, and two custom levels that used shaderball and multi-mat_mesh-groups_1m_cubes.
- Lots of manual fiddling with material component.
- Created a white box component and saw that it rendered correctly.
- Cherry-picked these changes into Apocalypse's code base and verified with one of their levels.
- Ran AtomSampleViewer automated test suite. Some tests failed, but these were failing before my changes.
- RenderDoc is disabled when building the monolithic build
- The installation path is inferred on Windows, but may be overridden on
Windows/Linux via the ATOM_RENDERDOC_PATH environment variable
- Linux support may work, but I have no means to test it
- Android support shouldn't be difficult to add, but requires a
renderdoc_android.cmake file that understands how the RenderDoc
package is distributed as part of the Android toolchain
Signed-off-by: Jeremy Ong <jcong@amazon.com>
* Temporary fix for Linux/Vulkan/XCB where the swap chain is not ready to present until the resize is complete
* Fix invalid GUID from LinuxXcbConnectionManager
Signed-off-by: spham-amzn <spham@amazon.com>
* Fixed the emplace function implementations for stack and queue
Cleaned up several functions in the stack, queue and priority_queue
classes that were non-standard or weren't needed.
Updated the "style" of the code to use more modern concepts: "typedef" ->
"using", empty constructor body -> default keyword.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Replaced the custom implementations of AZStd stack, (proirity)queue
Theses classes now have a template alias to the standard library version
of the classes
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Enabled PhysX system component in asset builders since it's required for cooking collision meshes
Signed-off-by: pereslav <pereslav@amazon.com>
* Added AssetCatalogService to the list of dependent
Signed-off-by: pereslav <pereslav@amazon.com>
Repro steps:
- Create two entities.
- Entity 1
- Add a mesh component and assign a model with multiple sub-meshes
- Add a material component. The material component looks correct.
- Entity 2
- Add a mesh component and assign the same model as the other entity
- Add a material component. The material component shows "<unknown>" for all material slot names
The problem was that ReflectedPropertyEditor creates a new Asset<> reference with the correct ID but does not load it. This asset is passed to EditorMaterialComponent, MaterialComponentController, and MeshFeatureProcessor and none of these tell the Asset to load. The MeshFeatureProcessor was not loading the Asset or connecting to the AssetBus because the instance already existed in the InstanceDatabse so from the FP's perspecive there was no need. But for the FP's GetModelAsset() API to function correctly it needs to have the asset initialized to the available AssetData pointer. So we updated the MeshFeatureProcessor to always connect to the AssetBus so it will find the available AssetData via the OnAssetReady callback.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
AMZN-Olex
santorac
Jeremy Ong
Esteban Papp
Chris Galvan
Guthrie Adams
AMZN-stankowi
puvvadar
lumberyard-employee-dm
rgba16f
Jeremy Ong
Steve Pham
Guthrie Adams
AMZN-koppersr
SergeyAMZN
Ken Pruiksma
carlitosan
Chris Santora