AZ::RPI::MaterialFunctor Class Reference

#include <MaterialFunctor.h>

Inherits AZStd::intrusive_base.

Inherited by AZ::RPI::LuaMaterialFunctor, AZ::Render::ConvertEmissiveUnitFunctor, AZ::Render::SubsurfaceTransmissionParameterFunctor, AZ::Render::Transform2DFunctor, and AZ::Render::UseTextureFunctor.

Public Member Functions
	AZ_RTTI (AZ::RPI::MaterialFunctor, "{4F2EDF30-71C0-4E00-9CB0-9EA97587712E}")
	AZ_CLASS_ALLOCATOR (MaterialFunctor, SystemAllocator)
bool	NeedsProcess (const MaterialPropertyFlags &propertyDirtyFlags)
	Check if dependent properties are dirty.
const MaterialPropertyFlags &	GetMaterialPropertyDependencies () const
	Get all dependent properties of this functor.
virtual void	Process (MaterialFunctorAPI::RuntimeContext &context)
virtual void	Process (MaterialFunctorAPI::EditorContext &context)
	Process(EditorContext) is called in tools to configure UI, such as property visibility.
virtual void	Process (MaterialFunctorAPI::PipelineRuntimeContext &context)

Static Public Member Functions
static void	Reflect (ReflectContext *context)

Friends
class	MaterialFunctorSourceData

Detailed Description

MaterialFunctor objects provide custom logic and calculations to configure shaders, render states, editor metadata, and more. Atom also provides a LuaMaterialFunctor subclass that uses a script to define the custom logic for a convenient workflow. Developers may also provide their own custom hard-coded implementations as an optimization rather than taking the scripted approach. Any custom subclasses of MaterialFunctor will also need a corresponding MaterialFunctorSourceData subclass to create the functor at build-time. Depending on the builder context, clients can choose to create a runtime specific functor, an editor functor or one functor used in both circumstances (see usage examples and MaterialFunctor::Process blow). Usage example: (MainRuntime) Modify the material's main ShaderCollection; (This allows a material type to include custom logic that dynamically enables or disables particular shaders, or set shader options) (MainRuntime) Perform client-specified calculations on material property values to produce shader input values; (For example, there may be a "RotationDegrees" material property but the underlying shader requires a rotation matrix, so a MaterialFunctor converts the data.) (MainRuntime) Set internal material property values that are passed to a material pipeline script for further processing; (For example, if a an "opacityValue" property is less than 1.0, set a "isTransparent" flag. Another material pipeline functor can use this to enable the transparent pass shader.) (Editor) Modify metadata of a property when other related properties have changed their value. (For example, if a flag property use texture is checked, the texture property will show up, otherwise, it should hide.) (PipelineRuntime) Enable or disable material pipeline shaders. (The material pipeline has an "isTransparent" flag. Some other part of the material type sets this value as needed based on material property values from the user. If this value is true, the functor disables the depth pass and forward pass, and instead enables the transparent pass shader.) Note: Although it is reasonable to have a MaterialFunctor subclass that implements both Process(RuntimeContext) and Process(EditorContext) (Atom has several functors that work like this), there is no reason for a functor to combine either of these with Process(PipelineRuntimeContext). The role of regular material functors vs pipeline material functors are so different it could actually be more proper to have separate MaterialFunctor and MaterialPipelineFunctor classes. However, we avoid making that split because in practice it would create unnecessary clutter, as it would lead to splitting Material[Pipeline]SourceData, JsonMaterial[Pipeline]FunctorSourceDataSerializer, LuaMaterial[Pipeline]Functor, LuaMaterial[Pipeline]FunctorSourceData, and all their relevant unit tests. These are so similar functionally that it ends up being easier to just keep them all together, and solely rely on the different execution context objections to keep the APIs separated.

Member Function Documentation

Process() [1/3]

virtual void AZ::RPI::MaterialFunctor::Process ( MaterialFunctorAPI::EditorContext &  context )

inlinevirtual

Process(EditorContext) is called in tools to configure UI, such as property visibility.

Reimplemented in AZ::RPI::LuaMaterialFunctor, AZ::Render::ConvertEmissiveUnitFunctor, and AZ::Render::UseTextureFunctor.

Process() [2/3]

virtual void AZ::RPI::MaterialFunctor::Process ( MaterialFunctorAPI::PipelineRuntimeContext &  context )

inlinevirtual

Process(PipelineRuntimeContext) is called at runtime to configure a pipeline-specific ShaderCollection based on some internal material property values.

Reimplemented in AZ::RPI::LuaMaterialFunctor.

Process() [3/3]

virtual void AZ::RPI::MaterialFunctor::Process ( MaterialFunctorAPI::RuntimeContext &  context )

inlinevirtual

Process(RuntimeContext) is called at runtime to configure the pipeline-agnostic ShaderCollection and material ShaderResourceGroup based on material property values.

Reimplemented in AZ::RPI::LuaMaterialFunctor, AZ::Render::ConvertEmissiveUnitFunctor, AZ::Render::SubsurfaceTransmissionParameterFunctor, AZ::Render::Transform2DFunctor, and AZ::Render::UseTextureFunctor.

---

The documentation for this class was generated from the following file:

• Gems/Atom/RPI/Code/Include/Atom/RPI.Reflect/Material/MaterialFunctor.h