All material (Lit, Unlit) now derive from a base class:
RenderPipelineMaterial
previously namespace was use to material name, now it is a regular class
It allow to add more easily new material or replace current one
HDRenderPipeline with introspection will execute all material method
from found RenderPipelineMaterial
The unique deferred material that we suppose is still a special case as
several code depends on it
This forces client to handle Cmd Buffer management and execution. This is necessary due to the impossibility to use nested Command Buffers currently (so any API called from user land cannot create and execute a CB of its own).
* HDRP: Add support of light layering for forward (first draft)
TODO:
- Test instancing
- Check perf
- add an option to disable light layer support + in frameSettings
- add deferred rendering support (mean add an optional extra GBuffer)
* Add LightLinking support (version 1 - compile)
This PR add support of LightLayers feature.
To use it, setup mask renderingLayers on renderers and LightLayers on a lights. If a logical and of both give a non 0 value, the light is apply, otherwise it isn't.
This mean that by default LightLayers is 1 and RenderingLayers is 1. Then user can say LightLayers is only 2 and it will only affect renderingLayers with 2 or 3 mask value.
LightLayers require an extra GBuffer in deferred, mean it have extra bandwidth and memory cost.
LightLayers once enabled in HDRPAsset with SupportLightLayers can be control by FrameSettings. Mean a camera can enable extra RT only for an in game cinematic.
This PR refactor...
Sebastien Lagarde
Julien Ignace
Tim Cooper
sebastienlagarde
GitHub
Paul Melamed