Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

BatchRendererGroup lighting

Discussion in 'High Definition Render Pipeline' started by snacktime, May 17, 2020.

  1. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    What is needed to get proper lighting for rendering with BatchRendererGroup? No information on this that I can find. Indirect seems to be specifically what doesn't just work although I'm not sure that's the whole story.
     
  2. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    So this is very disappointing.
    https://issuetracker.unity3d.com/is...en-batched-and-drawn-using-batchrenderergroup


    As if hybrid renderer can fill every need. It can't, BatchRendererGroup should be directly supported. Just because Unity can't think of use cases for using it directly doesn't mean they don't exist. We have hit multiple of these already. Hybrid renderer solves for a huge surface area and it provably does a bad job in some of those. Some might get better, but some never will compared to a purpose built rendering system based on BatchRendererGroup directly.

    I could understand if you wanted to support hybrid renderer first and work out issues there. But to take the attitude that nobody needs BatchRendererGroup directly is rather clueless.
     
  3. Tim-C

    Tim-C

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    2,221
    Hi, The batch render group api is a very small and barebones api that you can use to build features on top of. For performance reasons it explicitly does not do things like calculate lighting per instance or per object motion vectors. The intent for this API is for features to be built on top of it in c# that will expose this.

    For example: Right now we are building systems for hyrbid v2 that set per instance lighting data (light indicies) and things like SH probe data. We do this via dots to ensure that the data arrives fast and nice onto the GPU.

    This API is not and will not ever be an API that attempts to do everything. It really needs to be connected to a higher level system like the hybrid renderer v2 to really be used. You are free to write a higher level system like this if you feel like it, looking at the hybrid renderer v2 code is a good place to start.
     
  4. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    I said what I said having used HR V2 extensively already. We already have custom modifications to HR V2. I've given feedback on the design of BatchRendererGroup itself on the thread about it in the DOTS forum. Already found and filed one serious bug with BRG itself (1247413). HR is provably not the best solution in some cases because it has to solve for a large surface area and live within the constraints of ECS. It's culling for example can be an order of magnitude slower then a purpose built implementation using BatchRendererGroup directly. And that is unlikely to ever change, it's just inherent in how it's solved in an ECS context.

    What I'm asking is to treat BRG as if it's a value outside of HR, because it is.. I fully understand the scope of the api. For most cases just saying look at the HR is the right thing to do. But that doesn't cover all cases. Like indirect lighting that isn't in HR yet. I get there are multiple moving parts where BRG is involved, some things might not be BRG specific per say. But still just a basic simple answer would be a huge value. Either a simple pointer to what data is missing. Or just a simple not yet supported in SRP so not possible atm. There are quite a few holes in SRP at this point and the right information can save people a lot of time via being able to make the right choices. Flying blind isn't fun.