Official New BatchRendererGroup API for 2022.1

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 ?

 

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?

 

Thanks for the tip. Works like a charm

 

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!

 

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

 

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?

 

oh i see, so it's for instancing. . . .

 

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?)

 

i assume this only work when used with DOTS ECS?

 

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

 

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?

 

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?

 

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.

 

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"'

 

Where are we on the procedural / indirect draw support for BRG currently?

 

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.

 

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.

 

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