Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Official New BatchRendererGroup API for 2022.1

Discussion in 'Graphics for ECS' started by joelv, Jan 26, 2022.

  1. unisip

    unisip

    Joined:
    Sep 15, 2010
    Posts:
    328
    I just upgraded a BRG test project from 2022.1.22f1 to 2022.2.f1.
    In 2022.1, the lightprobe data passed via metadata works fine, but it seems to be broken on the same project in 2022.2.
    I am using URP.
    Has something changed ? Does anyone have lightprobes working with BRG on 2022.2 ?
     
    Last edited: Jan 2, 2023
  2. JussiKnuuttila

    JussiKnuuttila

    Unity Technologies

    Joined:
    Jun 7, 2019
    Posts:
    283
    Lightprobe data has been collected into a single struct between 2022.1 and 2022.2 to cut down on property access overhead, which was found to be unnecessarily high with the old approach. The way to set the data in 2022.2 is to use the unity_SHCoefficients property together with the "SHCoefficients" struct type.
     
  3. mpa7ster

    mpa7ster

    Joined:
    Jul 6, 2020
    Posts:
    4
    If I understand correctly, objects in a subscene will automatically use this API? Is depth sorting happening automatically too or would we need to implement that manually?
     
  4. joelv

    joelv

    Unity Technologies

    Joined:
    Mar 20, 2015
    Posts:
    200
    Objects in subscenes will use the Entities Graphics data path if that package is included in your package manifest. That package uses this API internally.
    However you can use this API without subscenes if you want to provide data to unity rendering in some custom way. With a lot more manual work but with more control
     
    Last edited: Jan 10, 2023
    mpa7ster likes this.
  5. unisip

    unisip

    Joined:
    Sep 15, 2010
    Posts:
    328
    Thanks for the tip. Works like a charm :)
     
    JussiKnuuttila likes this.
  6. IgorBoyko

    IgorBoyko

    Joined:
    Sep 28, 2020
    Posts:
    81
    Hello and thanks for the great new functionality!

    Is there any link to bugtracker to track the issue state? We are currently trying to move to BRG and are experiencing performance degradation on devices like Realme 8, whereas S20 works flawlessly. We're strongly confident we're hitting the exact issue but have no means to track its progress to plan our release schedule.

    Thanks again and have a nice day!
     
  7. Reedmand

    Reedmand

    Joined:
    Sep 29, 2016
    Posts:
    7
    Hello. I want to add some information to the previous commenter's post. On devices like Xiaomi Mi 5 it renders only 1 object from total number when using BRG. Does this problem also related to issue which you described about SSBO data loading path or it is related to another issue? Thanks in advance
     
  8. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,753
    Sorry if i may missed this, will URP and HDRP have a built in BRG integration out of the box? like user doesn't have to create additional renderer? Since it was mention a couple pages back that Unity are working for GPU Driven HDRP with BRG?
     
  9. joelv

    joelv

    Unity Technologies

    Joined:
    Mar 20, 2015
    Posts:
    200
    The BRG is not a renderer in the sense that URP/HDRP is. It's just a way to pass additional data to render. You can see it as an equivalent to Graphics.DrawMeshInstanced but much more performant and powerful (and more complicated to use). Most HDRP and URP shaders are already BRG compatible, or will be made compatible in the future.

    That's all I can say for now. Hopefully there will be more to share on this front soon(ish).
     
  10. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,753
    oh i see, so it's for instancing. . . .
     
  11. joelv

    joelv

    Unity Technologies

    Joined:
    Mar 20, 2015
    Posts:
    200
    Instancing, scriptable culling and a way to keep the instance data persistent on the GPU yes.
     
  12. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    8,571
    would this improve anything on a heavy scene where all meshes are basically unique?

    Either really huge combined meshes with hundreds of millions of polygons
    or that big mesh in smaller pieces? (maybe culling could be used for those then?)
     
  13. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,753
    i assume this only work when used with DOTS ECS?
     
  14. JussiKnuuttila

    JussiKnuuttila

    Unity Technologies

    Joined:
    Jun 7, 2019
    Posts:
    283
    The Entities Graphics package is implemented using BatchRendererGroup, but the API can be used directly as well. You can use the BatchRendererGroup API from your code without using ECS, but then it is up to you to implement the instance data uploading and visibility culling.
     
  15. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,753
    So basically this would perform best for rendering high amount of object with the same meshes, i guess on heavy scene with unique mesh this doesn't improve perfomance then?
    Seems like a good addition to be added into terrain system
     
  16. joelv

    joelv

    Unity Technologies

    Joined:
    Mar 20, 2015
    Posts:
    200
    You can still potentially benefit from using the BRG in the unique mesh case, as you have the ability to keep some data completely on the GPU. This means less data preparation on the CPU and less data transfer to the GPU. It's highly content/device dependent though.
     
    mgear likes this.
  17. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,753
    Hmm interesting, also Sebastian tweet make me even more curious. Did he ever share the project file for the Viking Village? would like to see how it work for that kind of case. Do you guys have a similar sample project that we can peek around for BRG?
     
  18. joelv

    joelv

    Unity Technologies

    Joined:
    Mar 20, 2015
    Posts:
    200
    Sebastians tweet I think is regarding the test project he made during an internal hackweek. Is that correct? If so this is what became RenderBRG.cs which exists here

    https://github.com/Unity-Technologi...es/com.unity.testing.brg/Scripts/RenderBRG.cs

    It's very incomplete though but can be seen as a prototype on how to convert a game object world to render using BRG. But as I said, I do hope to have more to share on this front soon
     
    Reanimate_L likes this.
  19. joshuacwilde

    joshuacwilde

    Joined:
    Feb 4, 2018
    Posts:
    650
    This is because you are working on more rendering improvements currently, with a tentative release date soon? Or you hope to be working on this in the future, but are not currently?
     
  20. IgorBoyko

    IgorBoyko

    Joined:
    Sep 28, 2020
    Posts:
    81
    I am once again bumping this post. Where exactly can we track the issue? It is mentioned that it is currently being investigated, but there are no means to support this statement as of now. We are up for voting for the resolution yet we cannot do that.
     
  21. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,753
    Gotcha, alright i hope we can get official proper example for the BRG, i'll use the current script from git for testing then. Which unity version that is used? at least for the current master branch?

    Edit : @joelv i'm getting this error using script above, i'm on HDRP already
    RenderBRG.cs(751,12): error CS1029: #error: '"You need either HDRP or URP package to use this script"'
     
    Last edited: Apr 19, 2023
  22. Thomas-Mountainborn

    Thomas-Mountainborn

    Joined:
    Jun 11, 2015
    Posts:
    481
    Where are we on the procedural / indirect draw support for BRG currently?
     
  23. joelv

    joelv

    Unity Technologies

    Joined:
    Mar 20, 2015
    Posts:
    200
    Work has started on it again but I can't promise in what version it can land.
     
  24. burningmime

    burningmime

    Joined:
    Jan 25, 2014
    Posts:
    828
    I feel like this feature is being "advertised" wrong by Unity. My impression was that BRG had something to do with entities/ECS. I basically just dismissed it as an ECS-only thing. But I took another look at it today, and it solves some problems I was having.

    What BRG basically seems to be is an equivalent of a feature-limited CommandBuffer you fill up in a Burst job (plus the DOTS instancing and other stuff to support that). Which is HUGE. That's so cool for so many things that have nothing to do with entities, and are scoped to smaller features. My brain is already jumping around between vegetation systems, crowd simulations, shattered glass, scattered debris, and all sorts of other things. This has TONS of implications in a GameObject-based game or asset store product.

    I guess all I really have to say is it's a really neat and well-designed feature.
     
    IgorBoyko, DylanF, NotaNaN and 3 others like this.
  25. kite3h

    kite3h

    Joined:
    Aug 27, 2012
    Posts:
    190
    Originally, culling and sorting operations were performed in the low-level engine stage, not the script stage.
    It is not worthwhile to port the work to the script stage and make it possible to transform it according to the purpose of use.
    However, it is meaningless if the speed is reduced to achieve that purpose.
    So, in order for BRG to be used for its intended purpose and to increase performance, the ECS/DOTS situation is only suitable.

    I think that if only meshlet metadata generation is possible, nanite can also be created with BRG.
    But it doesn't seem to make much sense. BRG manages by attaching all mesh data. There is already a similar aspect in terms of attaching and managing only that each piece is not a meshlet.
    In terms of its flexibility, BRG may be more useful than nanite. However, there seem to be a few obstacles to overcome to use BRG well.
     
  26. YuriyPopov

    YuriyPopov

    Joined:
    Sep 5, 2017
    Posts:
    226
    I don't understand your criticism. My current implementation, unfinished and unoptimised as it is, performs much better than the standard mesh renderer path. If you do your culling in a bursted parallel job with BRG performance is much better