The main addition here is the MaterialNameContext class which represents the concept of a namespace for properties, shader options, and SRG fields. This concept was already somewhat supported in LuaMaterialFunctor through bespoke "prefix" fields, but I have generalized it be available for all material functors. Note that I have not yet updated the other material functor types to ensure they take advantage of this feature, that will be in another commit.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
* Updated all array_view uses with the C++20 span.
The updates were done in the following order
1. `AZStd::array_view<([^>].+)\* ?>` -> `AZStd::span<\1 const>`
2. `AZStd::array_view<(?:const )(.+)>` -> `AZStd::span<const \1>`
3. `AZStd::array_view` -> `AZStd::span`
Removed the implementation of array_view.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added missing whitespace between `const` and the typename for spans.
Updated the ShaderTest comparison of the ShaderResourceGroupLayout span
to compare the sizes as well
Updated comments on some of the methods that stated that they return "an
array" to mention they return "a span".
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
These changes have the added benefit of simplifying some of the serialization code. MaterialSourceDataSerializer is no longer needed, as its main purpose was to pass the MaterialTypeSourceData down to the MaterialPropertyValueSerializer.
Before, the JSON serialization system gave a lot of data flexibility because it did best-effort conversions, like allowing a float to be loaded as an int for example. But now the material serialization code doesn't know target data type, so it has to assume the data type based on what's in the .material file, and then the MaterialAsset will convert the data to the appropriate type later when Finalize() is called.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
In some cases it may be acceptable to do non-const things in a const function as long as it is only manipulating internal data, and the public facing API returns the same values as before. But in this case, the IsFinalized function is a public facing API that would have a different result after GetPropertyValues was called.
I also updated a couple other minor things from code review feedback.
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>
This RenderStates is used to override the values in the final draw packet, if the values are valid; it's supposed to be initialized to invalid values, but it wasn't. So the depth compare function was getting set to Less instead of GreaterEqual. This wasn't a problem when using serialized assets from disk, because the deserialization uses the default constructor which did initialize m_renderStatesOverlay. No all Item constructors initialize m_renderStatesOverlay.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Signed-off-by: Guthrie Adams <guthadam@amazon.com>
* Shaders changes require two or more change cycles before updating
This fixes the problem described in the title.
Consolidated the responsibility to update the root shader variant
asset into the Shader() class. It was unnecessarily spread across
Shader(), ShaderVariant() and ShaderAsset().
In particular OnAssetReloaded now makes a temporary copy of the root
ShaderVariantAsset and updates the ShaderAsset with such reference
only when OnAssetReloaded() is called on behalf of the ShaderAsset.
Signed-off-by: galibzon <66021303+galibzon@users.noreply.github.com>
* Added some structs for detail materials
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Added some template functions for looking up materials. Added lookups for all the relevant detail material fields in StandardPBR.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Added some structs for detail materials
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Added some template functions for looking up materials. Added lookups for all the relevant detail material fields in StandardPBR.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Added support for generating a detail material texture with IDs populated from surface weights.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Updated TerrainAreaMaterailRequestBus to have separate calls for region vs materials instead of the awkward out parameter
Update MaterialPropertyDescriptor so that you can retrieve enum names by ID
Several bug fixes / updates to the terrain feature processor dealing with detail materials.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Updating detail material texture based on offsets. Not quite working yet but close. Added visualization for detail material in shader (currently on, will be turned off before final commit)
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Small bugfixes
* Fix compile error in non-unity builds
* Fixed backwards x/y loops causing the wrong pixels to update
* Fixed selection of surface type with multiple surface weights
Signed-off-by: Mike Balfour <82224783+mbalfour-amzn@users.noreply.github.com>
* Adding seam to detail texture debug display. Offseting edges by a half-pixel to avoid bleed. Disabling debugging detail textures by default.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Missing file from last commit for detail material change.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Cleanups
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* bug fix
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Bug fix in the terrain fp for TerrainAreaMaterialRequestBus returning incomplete materials on GetSurfaceMaterialMappings
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Some PR updates. Exposing detail material id debugging through a cvar.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Various updates from review.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* PR updates dealing with debug texture boundary line.
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Hiding some fields from the terrain material
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
* Fixing type in generic lambda for linux / android
Signed-off-by: Ken Pruiksma <pruiksma@amazon.com>
Co-authored-by: Mike Balfour <82224783+mbalfour-amzn@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>
Also improved the MaterialAssetTests UpgradeMaterialAsset() to focus on testing the inputs and outputs of the class rather than the private internal data.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Also rearranged some logic to simplify the code that loops over rename actions, avoiding making unnecessary additional maps.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
* adding Windows/release to PR-validation builds
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* changing trace back to expand to nothing for release
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* typo
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* more fixes
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* fixing some more unused variable cases
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* renaming file in ScriptCanvas that causes a msbuild warning
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* reverting a previous change
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
A "property name" is the name of the just the property without regard to the group that it's in. A "group name" is the name of the group. And a "property ID" is the full unique name of a property in the form "groupName.propertyName". This is important preparation for upcoming changes where property sets can contain other property sets, and property IDs can be arbitrarily long like "layer1.baseColor.factor" for example.
The naming changes include variables, some code comments, and the .materialtype file format. I was able to make these changes in a backward compatible way so a property or group "id" field has been replaced with a "name" field, but "id" is still supported for compatibility. StandardPBR, EnhancedPBR, StandardMultilayerPBR, and Skin have all been updated. Note that MinimalPBR has not been updated, proving that backward compatibility works. (We can update this one too at some point though).
Testing:
Opened up materials in the material editor.
Ran AtomSampleViewer in dx12 and vulkan with no new failures.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Merge pull request #4102 from aws-lumberyard-dev/Atom/santorac/WarnOnMaterialPsoChanges
These changes make material system report warnings when gameplay scripts attempt to change PSO-impacting material properties at runtime. So far the material system has always allowed any properties to be changed at runtime, including those that affect Pipeline State Objects (PSOs), as this is supported on several platforms. But some platforms require that Pipeline State Objects be pre-compiled and shipped with the game. At some point we will need to add new restrictions that limit what material properties can be changed at runtime. In the meantime, these warnings should alert users to avoid this, as the functionality likely won't be supported in the future.
- Made the Material and LuaMaterialFunctor classes configurable to report errors or warnings when material properties modify Pipeline State Objects. This is controlled by a new "MaterialPropertyPsoHandling" enum.
- Made the EditorMaterialComponent override PSO handling as Enabled, to prevent warnings when the user is editing material instance property overrides. This requried a new MaterialComponentNotificationBus bus message "OnMaterialInstanceCreated".
- Added a new ScopedValue utility class that simply sets a value when it goes out of scope.
- Removed unnecessary GetMaterialPropertyDependencies member from material functor context classes, as this is already available as part of the functor itself.
- Made Material::SetPropertyValue return early when the property value hadn't actually changed. Besides being more efficientn, this prevents unnecessary spamming of the new warning.
- Made a couple imporvements to material_find_overrides_demo.lua:
- Made the target material slot name configurable through an exposed component property.
- Fixed a timing issue where the assignmentId was invalid if FindMaterialAssignmentId is called too early.
santorac
lumberyard-employee-dm
Esteban Papp
puvvadar
Guthrie Adams
Chris Burel
galibzon
Ken Pruiksma
hershey5045
Robin
Artur K