MaterialAssignment::ApplyProperties() still reports warnings but does not update the m_propertyOverrides.
MaterialAssignment::ApplyProperties() will now skip the old name'd overrides if overrides are present for the new names. I'm not sure if this will ever happen, but it did happen while I had some intermediate changes, so I imagine it could happen again.
I had to update the Material::FindPropertyIndex function to expose information about renames when they occur. This should make it easier for other systems to get (somewhat) automatic benefit from the version update feature.
I also found that there was an issue with material inspector where it wouldn't be initialized the the right override values when renames were present. Now it applies the renames to whatever override data it gets from the Material Component.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I added an ApplyPropertyRenames function to MaterialTypeAsset very similar to the one in MaterialTypeSourceData.
Updated the MaterialAssignment class to apply any property renames when it discovers the old name doesn't work. This will be written to disk when the level or prefab is saved.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
No longer need to assign material overrides to set/edit properties in UI or script
Material component will load and use the default material for a slot if no override is assigned
Signed-off-by: Guthrie Adams <guthadam@amazon.com>
* Add material property names to material assets, disable FBX dependency on materialtype files.
Signed-off-by: Robin <rbarrand@amazon.com>
* Add reflection for MaterialAssets. Update member variable comment.
Signed-off-by: Robin <rbarrand@amazon.com>
* Switch cvar to using bus value. Refine comments.
Signed-off-by: Robin <rbarrand@amazon.com>
* Refactor functions and refine comments.
Signed-off-by: Robin <rbarrand@amazon.com>
* Realign property values when material property names are populated.
Signed-off-by: Robin <rbarrand@amazon.com>
* Switch PostLoadInit check to on asset status ready. Add realign property values code to PostLoadInit as well.
Signed-off-by: Robin <rbarrand@amazon.com>
* Stash@{1} code.
Signed-off-by: Robin <rbarrand@amazon.com>
* Refactor realignment code into the right places.
Signed-off-by: Robin <rbarrand@amazon.com>
* Remove pragma optmize off.
Signed-off-by: Robin <rbarrand@amazon.com>
* More refactoring.
Signed-off-by: Robin <rbarrand@amazon.com>
* Refactor comments and remove code no longer needed.
Signed-off-by: Robin <rbarrand@amazon.com>
* Refactor comments and remove unused include.
Signed-off-by: Robin <rbarrand@amazon.com>
* Comment refactor, corrected some code.
Signed-off-by: Robin <rbarrand@amazon.com>
Co-authored-by: Robin <rbarrand@amazon.com>
By default, processing of model files (like FBX) automatically convert the included materials to Atom materials, using StandardPBR. This adds a job dependency on StandardPBR.materialtype, which propagates to any related azsl files as well. Thus any change to azsl code will cause all model files in the project to rebuild.
Some game teams have no interest in using the auto-converted materials; they always use a Material Component to apply material overrides for every mesh. This new setting allows teams to disable material auto-conversion for the entire project, thus removing the job dependency on StandardPBR.materialtype. Instead, every mesh will be assigned the same default material. Any change to azsl code will cause that one default material to rebuild, but this will not trigger any models to rebuild.
Details:
- Added /O3DE/SceneAPI/MaterialConverter registry settings for configuring the scene material converter. It includes an enable flag, and a default material to use when conversion is disabled.
- Added SceneBuilderDependencyRequests::AddFingerprintInfo which allows ScenePI components to modify the scene builder analysis fingerprint. We use this to reprocess scene files when the material converter settings change.
- Updated SceneAPI's material asset builder to skip the StandardPBR dependency when material conversion is disabled.
- Added some code to MaterialComponentController to handle an edge case that may when disabling material conversion on an existing project, and assigned materials disappear.
Testing:
- Changing the registery setting does trigger a rebuild of the fbx files.
- When material conversion is disabled, changing an azsl file does not cause fbx files to rebuild, but the shader still reloads as expected.
- Made a test level using multiple models with multiple meshes, made various adjustments to the material slots for each mesh, and tried switcihng the material conversion registry setting from true to false. (Details below)
- TODO: Will merge this change to a customer's fork and test on their existing content.
Details about my test level:
- Made a new test level AtomTest project
- Added two entities, both using multi-mat_mesh-groups_1m_cubes.fbx
- Added a material component to both entities
- Entity 1 material assignments
- Blue_Zaxis: left as-is
- Green_Yaxis: exported the material
- Red_Xaxis: exported the material, and changed the material instance color to pink
- StingrayPBS1: exported the material, scaled the UVs in the exported material source, and changed the material instance color to green.
- With_Texture: selected an existing brick material, changed the material instance color to red.
- Entity 2 material assignments
- Default Material: set to an existing brick material
- Blue_Zaxis: manually assigned built-in material that was converted from fbx
- Green_Yaxis: manually assigned built-in material that was converted from fbx, and changed the material instance color to orange
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Here we inttroduce a new struct ModelMaterialSlot which formalizes the concept of material slot, with an ID, display name, and default material assignment. The ID still comes from the MaterialUid like before. The display name is built-in, rather than being parsed out from the asset file name. And the default material assignment can be any material asset, it doesn't have to come from the FBX (or other scene file).
This commit is just the preliminary set of changes. Cursory testing shows that it works pretty well but more testing is needed (and likely some fixes) before merging.
Here is what's left to do...
Add serialization version converters to preserve prior prefab data.
See if we can get rid of GetLabelByAssetId function only rely on the display name inside ModelMaterialSlot.
I'm not sure if the condition for enabling the "Edit Material Instance..." context menu item is correct.
Test actors
Lots more testing in general
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>
The bug was reported that copy and paste did not work with the material component.
Copy and paste to take the worked fine.
All of the material assignments/overrides get mapped using the LOD and asset ID of materials provided with the model.
The asset IDs of materials exported by atom builders, using the scene API, are the combination of the same UUID as the model asset ID and the unique sub ID that is now hashed from the material name provided by the DCC tool.
If we map material assignments using the entire asset ID that was generated in the model builder then the mapping will only work with that specific model.
This change updates the material assignment ID equality operators and hash function to only use the sub ID portion of the asset ID.
As long as the sub IDs are generated consistently the material assignment mappings will be portable to models with the same material names.
Also moved material assignment structures to atom common features static library so this was to be moved to cpp files
santorac
Guthrie Adams
Artur K
Esteban Papp
hershey5045
Chris Santora
Steve Pham
amzn-mike
cgalvan
AMZN-stankowi
alexpete