This is needed to support deeply nested material property groups, it just makes the serialization code a lot simpler than trying to support nested groups in the .material file. It also makes the file more readable and easier to search all files for particular properties.
I also updated MaterialSourceData to hide the property values behind a clean API.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Fixed the MaterialBuilder to report source dependencies on imported JSON files, so the material type will rebuild when you edit an imported file that contains shared property data.
Fixed a spot in LuaMaterialFunctorSourceData where it was only applying the old "prefix" feature and not the new name context.
Updated a couple built-in material functors to take advantage of the name context (they were using RuntimeContext::GetShaderResourceGroupLayout instead of the RuntimeContext::FindShaderInputConstantIndex wrapper utility function).
Fixed an issue with EnumeratePropertyGroups where it wasn't passing the right name context, so Material Editor wasn't able to load some material types.
Reordered the parameters in the MaterialTypeSourceData enumerate callback functions, I felt this order was more natural.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I also noticed that JsonFileLoadContext was no longer used (see https://github.com/o3de/o3de/pull/7010) so I was able to remove all that code.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
There were lots of material system conflicts that had to be resolved. I expect the build is broken at this commit, and I'll fix it in followup commits.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I found a mistake where MaterialAssetCreator needs to clear the raw data when configured to finalize the material asset.
Since MaterialSourceData no longer relies on the material type source file at all, I was able to change MaterialSourceDataTest to avoid saving the source data to disk.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I made MaterialAsset::Finalize private so I could add some parameters specifically for MaterialAssetCreator to use. Now MaterialAssetCreator::Begin has an option to finalize the material or not.
Moved MaterialAssetCreatorCommon::ValidateDataType to MaterialPropertyDescriptor as "ValidateMaterialPropertyDataType" so that MaterialAsset::Finalize could use it too
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Before, the material builder was loading the MaterialTypeAsset and doing some processing with it, but was avoiding declaring job dependencies that would cause reprocessing lots of assets when a shader or .materialtype file changes. Reading the asset data isn't safe when not declaring a job dependency (or when declaring a weak job dependency like OrderOnce which is the case here). This caused to several known bugs.
The main change here is it no longer loads the MaterialTypeAsset at all; all other changes flow from there.
The biggest changes (when deferred material processing is enabled) are ...
1) MaterialSourceData no longer loads MaterialTypeAsset. All it really needs is to determine whether a string is an image file reference or an enum value, which is easy to do by just looking for the "." for the extension.
2) MaterialAssetCreator no longer produces a finalized material asset. It no longer uses MaterialAssetCreatorCommon because that only produces a non-finalized MaterialAsset, which has very different needs for the SetPropertyValue function. (We could consider merging MaterialAssetCreatorCommon into MaterialTypeAssetCreator since that's the only subclass at this point). And it doesn't do any validation against the properties layout since that can be done at runtime.
3) Moved processing of enum property values from MaterialSourceData to MaterialAsset::Finalize (this was the only thing being done in the builder that actually needed to read the material type asset data).
Also...
- Updated the MaterialAsset class mostly to clarify and formalize the two different modes it can be in: whether it is finalized or not.
- Merged the separate "IncludeMaterialPropertyNames" registry settings from MaterialConverterSystemComponent and MaterialBuilder into one "FinalizeMaterialAssets" setting used for both.
- Removed MaterialSourceData::ApplyVersionUpdates. Now the flow of data is the same regardless of whether the materials are finalized by the AP or at runtime. Version updates are always applied on the MaterialAsset.
- Added a validation check to MaterialTypeAssetCreator ensuring that once a property is renamed, the old name can never be used again for a new property. This assumption was already made previously, but not formalized, in that Material::FindPropertyIndex does not expect every caller to provide a version number for the material property name, also the material asset's list of raw property names was never versioned. The only way for this to be a safe assumption is to prevent reuse of old names.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I actually tried this approach before and it didn't seem to work the way we needed, but I realized that's because PropertyAssetCtrl wasn't handling missing assets properly. I fixed a few issues there including showing the error button when the asset can't be found, and fixing a broken reference to the error icon file.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Material Editor also warns the user when saving a material that is populated with fallback image references.
Factored out the path strings for the default images to ImateSystemInterface.h.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Here we formalize the concept of a Property Set, which replaces property "groups", containing the group name and description, properties, and functors all in one place.
The Property Set structure will allow arbitrarily deep nesting, whereas before you only had one level of grouping. This nesting is not fully supported yet throughout the system, particularly in the Material Editor. It was easier to go ahead and put in some of the nesting mechanims, parituclar in the implementation of MaterialTypeSourceData.
This change is backward compatible, which is proved with unit tests, and by the fact that only MinimalPBR.materialtype has been updated to the new format. StandardPBR, EnhancedPBR, and others are still using the old format. (In a subsequent commit I'll update these as well, to prove that the new format works correctly).
Other changes and improvements...
- A new constructor for MaterialPropertyId
- Improved API for MaterialTypeSourceData that hides a good deal more of it's data as private, with clear and convenient APIs. Especially AddProperty, AddPropertySet, FindProperty, FindPropertySet, EnumerateProperties, EnumeratePropertySets.
- Added lots of new unit tests
- Updated MinimalPBR.materialtype to the new format.
Testing:
- Updated unit tests.
- Reprocessed Atom material assets.
- Ran AtomSampleViewer material screenshot test.
- Opened, edited, saved material in the Material Editor.
- Opened a level, edited material property overrides, saved and reloaded.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
This required the use of custom serializers, because the JSON serialization system does not have any means of supporting field name aliases through SerializeContext.
Testing: RPI unit test pass and AtomSampleViewer material screenshot test script passes.
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>
santorac
srikappa-amzn
srikappa-amzn
chcurran
Steve Pham
alexpete