Summary:

During raytracing the hit-shaders need access to all materials in the scene at once, which clashes with the current setup for the Forward+ - Pipeline, where a shader needs only access to a single Material Instance at any given time.
The current solution for Raytracing is somewhat unfinished, in that it assumes that there exists only one material-type, and collects all Material-Instances in a single RayTracingMaterialSrg, and uses one single hit-shader that re-implements almost but not quite the BasePBR - material type.

What is the relevance of this feature?

The new Material-Pipeline and the Material Canvas allows users to easily create their own material types, but that has no influence on the material used during raytracing. This feature would remedy that, and enable user-created material types during raytracing.

Generally, any meaningful raytracing pipeline needs access to the geometry and materials of the entire scene in one shader / renderpass.
Also the current material-shaders place the LightAssignment and the Shadow Sampling inside of the EvaluateLighting - function, which implicitly makes them the responsibility of the material type; in other words, using the BasePBR - Materialtype (or any material-Type derived from it) currently requires a viewspace tile-based light assignment and e.g. cascaded shadow maps for some lights, which doesn't work all that well for a raytracing pipeline that can intersect offscreen objects.

Incidentally, all of this would also make implementing a deferred pipeline easier.

Feature design description:

Each Material-Instance creates an fills a MaterialParameters ByteAddressBuffer that contains the material parameters, texture use flags and bindless texture read indices needed during rendering of the material.
The MeshFeatureProcessor creates and maintains a single SceneMaterialSrg that holds one buffer with the bindless read indices of the MaterialParameters, with one entry for each separate Material Instance (i.e. each sub-mesh), and the texture samplers required by all materials.
Alternatively, if the support of bindless SRGs is not good enough, this SRG can also hold an array of all required material textures (deduplicated) and an array of the MaterialParameters - buffers, with the read-index then referring to the entry in this buffers instead of the Bindless SRG. Also the first value in each MaterialParameters ByteAddressBuffer should be the Material Type Id, so the shader can perform a sanity check and avoid parsing parameters from the wrong material instance.

The Material Type Id should be calculated from the material type and the shader options of the material, since the shader-options can't be in the SceneMaterialSrg that is shared between shaders.

Technical design description and implementation steps:

Rough draft of the required steps:

• Extend the RPI::Material - class to create and fill one MaterialParameters - ByteAddressBuffer for each MaterialInstance that holds the parameter values and the bindless read indices of the material textures.
• Extend the MeshFeatureProcessor to calculate a unique Material Instance Id for each sub-mesh, and a unique Material Type Id for the material type and shader option values of each loaded mesh.
• Move the logic for the material SRG from the RayTracingFeatureProcessor to the MeshFeatureProcessor to create and maintain a SceneMaterialSrg.
  • Alternatively add it to the SceneSrg directly
• Add the Material Instance Id to the MeshInfo struct of the RayTracingSceneSrg.
• Add the Material Instance Id to the ObjectSrg of each Mesh - DrawItems.
• Refactor the existing material shader code and move the LightAssignment - Loop and the Shadow-sampling out of the EvaluateLighting - function
• Modify the existing materials to read the material parameters from a MaterialParameters - struct and texture indices in an array instead of accessing the MaterialSrg directly.
• Create a shader function that provides access to a MaterialParameters - struct based only on the Material Instance Id.
• Consolidate the Light-Type structures (e.g. RayTracingSceneSrg::DirectionalLight and SceneSrg::DirectionalLight) of the RayTracingSceneSrg and the SceneSrg into a single azsli - file
• Support multiple hit-shaders for each RayTracing pass

What are the advantages of the feature?

Actually support user-provided materials during raytracing.

What are the disadvantages of the feature?

Breaking changes with existing (old) materials

Are there any alternatives to this feature?

There are a few options in how and when the Material-Parameters could be stored and updated. But the current solution is an alternative in that it pretends there is only one PBR - material type in the scene, which does cover many use-cases.

How will users learn this feature?

• There will be a breaking change for user-defined materials that should be announced on Discord, but most changes will happen in the ATOM rendered, without direct user interaction.

Are there any open questions?

• To further support deferred pipelines we could move the logic of both, the Scene Geometry (i.e. the MeshInfo - struct) and the Material Parameters, out of the RayTracingFeatureProcessor and have the MeshFeatureProcessor simply place them in the SceneSrg. This would require raytracing-passes to bind both, the SceneSrg and the RayTracingSceneSrg, and some sort of mapping from a RTAS Instance ID to the submesh, but that should not be an issue.
• We could create one MaterialSrg per Material-Type which contains a Structured Buffer with a defined Materialparamater-Struct to avoid using a ByteAddressBuffer, but i'm not sure if multiple hit-shaders can work with different SRGs in one Raytracing-pass.
• The Texture-Samplers in the SceneMaterialSrg limits the materials to the sampler configurations we explicitly provide there, but i don't have a better idea there.
• Should we move the light types from the ViewSrg / RayTracingSceneSrg to the SceneSrg? As far as i can tell the contents of these buffers is the same.