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
Chris Santora
Steve Pham
guthadam
alexpete