Search Unity

Feedback Feature request. Add render targets to deferred rendering

Discussion in 'General Graphics' started by Chaiker, Jul 18, 2019.

  1. Chaiker

    Chaiker

    Joined:
    Apr 14, 2014
    Posts:
    63
    Hello.

    Adding new render targets in deferred rendering would be great.
    When I tried to do this with command buffer i did not succeed.
    I create command buffer that call SetRenderTarget on BeforeGBuffer camera event. And it setups all targets (built-in unity gbuffer and my custom render textures) as I want. When I call DrawMesh or DrawRenderer (and other commands) it works properly. But after that (when scene objects renders natively) Unity setups built-in gbuffer targets again.
    Could you add one more camera event (after render targets setup) or move built-in set render targets before BeforeGBuffer event?

    Usage may be different, for example I can render decals projection mask with object layer values, for projecting by layers. With one drawcall I will can render object as is and also render object layer into mask. Also I think this feature would be great for people that work with some custom lighting solutions.

    Of course I can render masks from other camera to custom render target, or with command buffer, but sometimes I need render same objects that already rendered on scene and it affects on CPU and GPU performance by doubling draw calls.

    I know about SRP, but current solutions also not extendable (without package source modifying), and I need standard rendering by a little bit extended.

    Would be added?
     
  2. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,352
    Any modification to the current render target(s) or other render state made by command buffers are undone as soon as they finish executing. This is to make sure stuff isn't left in a broken state, but also means you can't modify the built in rendering paths significantly.

    Also, assume no new features are coming to the built in rendering paths, forward or deferred, as all work is currently focused on the SRPs. From this point on it'll only be serious bugs and performance regressions that are likely to be looked at.

    If you want "additional gbuffers" for the current rendering paths, the solution is to use a replacement shader render pass.