New BatchRendererGroup API for 2022.1

[mgear]

URP, 10 million default cubes, is this expected results? (using that sample script)

[JussiKnuuttila]

@mgear

URP, 10 million default cubes, is this expected results? (using that sample script)

The sample script does not use Burst to keep the sample simple. If you improve it and use Burst jobs to fill the large arrays (I think in the sample it’s just the visible instance indices), you should see much better performance.

Alternatively, if you just want to test best case performance, you can make a cached copy of the array and use UnsafeUtility.MemCpy to copy it into place. This is not what a real game would do, since it would assume static visibility, but for a simple test like this it could be OK.

[hippocoder]

@Tim-C

We have a branch here where we have been experimenting with allowing static objects to render via BRG. This is super super experimental but can serve as a bigger example of how to put a lot more things into the BRG. This is also using some engine API’s that have not made it into a release yet so it will likely not just work or just compile for you but the entry point is the monobehaviour here.

It’s likely a pretty okay starting point if you want to make your own ‘fast brg for my static objects’. Note we also do some stuff for objects that are moving, but rigid so they can also work through BRG. This just leaves some things like skinned meshes and effects going through the gameobject path. Note: Don’t look into the deferred material stuff, that’s even more experimental and builds on top of the BRG gameobject rendering and is even less stable than the super experimental static objects in BRG.

Oh now you have done it! This is just the ticket and I think will help a major ton of devs! Thank you, and I hope URP would get some kind of new static path like this for classic projects. So many would get a free boost from it. Until then I am going to poke around with gratitude!

Thank you!

[tatoforever]

@joelv

[…]
Previously you could do this with Graphics.DrawMeshInstanced of course, but it would require you to upload a lot of matrices every frame as well as having to write custom shaders for any per instance data you would like to override. With the new BRG it is possible to write shaders that support both this and regular game objects and we support URP/Lit and HDRP/Lit (among others) out of the box. Also take these measurements with a grain of salt, but they do show that it’s possible to render much more efficiently with the new API.

Just to be 100% sure I got it right. When we upload data (or register it) using the API, does it remains on the GPU untill we unload it?

[CodeRoadOne_1]

The new code seems to solve some issues and I think it will work correctly with multiple lights.

@mgear I also tried to do your test using GPU culling, but my GPU (GeForce 1050GTX TI) cannot handle so much data unfortunately.
I did a test with around 2 mil cubes (127x127x127) here are my results:

CPU time to emit the visibility is 0.034ms and to emit the draw calls is 0.017ms
Total time on CPU with updating of the GPU data is 0.11ms
I’m sure as soon as I fix the GPU occlusion culling it will run even faster.

Of course my version doesn’t handle correctly all lights and uv lightmaps per instance. So getting speed improvements inside Unity it will always be better. I’m waiting for the release of Dots so I can fully use this new features.

Thank you for sharing!

[Grimreaper358]

Will there be default BRG optimizations enabled? I don’t know much about graphics programming so just checking if we will only have an API to use or if this will also have a default implementation in the engine.

I could just add my assets to the scene as usual and maybe follow certain rules and have it work.

[YuriyPopov]

@CodeRoadOne_1

The new code seems to solve some issues and I think it will work correctly with multiple lights.

@mgear I also tried to do your test using GPU culling, but my GPU (GeForce 1050GTX TI) cannot handle so much data unfortunately.
I did a test with around 2 mil cubes (127x127x127) here are my results:

CPU time to emit the visibility is 0.034ms and to emit the draw calls is 0.017ms
Total time on CPU with updating of the GPU data is 0.11ms
I’m sure as soon as I fix the GPU occlusion culling it will run even faster.

Of course my version doesn’t handle correctly all lights and uv lightmaps per instance. So getting speed improvements inside Unity it will always be better. I’m waiting for the release of Dots so I can fully use this new features.

Thank you for sharing!

I just have to ask. What method did you use to implement gpu occlusion culling and how?

[joelv]

@tatoforever

Just to be 100% sure I got it right. When we upload data (or register it) using the API, does it remains on the GPU untill we unload it?

For GraphicsBuffers you create and upload data to (matrices, overridden properties and so on) it is persistent and up to you to update and manage.

Meshes and Materials are a bit more complicated. Once you register them they will be recognized by the system but if some code deletes them the BRG will tag them as deleted and will just stop drawing any draw commands referencing the deleted mesh/material.

The data you provide in the culling callback is transient. It’s only used for one frame and then freed.

[joelv]

@Grimreaper358

Will there be default BRG optimizations enabled? I don’t know much about graphics programming so just checking if we will only have an API to use or if this will also have a default implementation in the engine.

I could just add my assets to the scene as usual and maybe follow certain rules and have it work.

We are not replacing any unity part with this as it is now. It’s the foundation for the Hybrid Renderer to be able to render entities, and it is usable if you want to write a custom renderer. The scripts linked in this threads are just examples of what is possible, and we may use something like this in the future so speed up general rendering.

[hippocoder]

@joelv

we may use something like this in the future so speed up general rendering

Awesome, hope this happens!

[CodeRoadOne_1]

@YuriyPopov

I just have to ask. What method did you use to implement gpu occlusion culling and how?

Hi @YuriyPopov ,
The occlusion culling is following the standard approach from Nanite. Use the previous frame to do the culling for the current frame.
Render all visible instances, next using the new depth do another visibility pass and render the rest of objects.
Right now I have an issue with the algorithm and it is not working as expected I need to debug.
But the current implementation is using frustum culling, size culling and lod switching, everything from the GPU. Still one draw call per material, but doesn’t care if you have different meshes.
If I can have more than one light it will be usable, so that’s why I’m waiting for improvements in Dots
I hope I answered your question.

[YuriyPopov]

@CodeRoadOne_1

Hi @YuriyPopov ,
The occlusion culling is following the standard approach from Nanite. Use the previous frame to do the culling for the current frame.
Render all visible instances, next using the new depth do another visibility pass and render the rest of objects.
Right now I have an issue with the algorithm and it is not working as expected I need to debug.
But the current implementation is using frustum culling, size culling and lod switching, everything from the GPU. Still one draw call per material, but doesn’t care if you have different meshes.
If I can have more than one light it will be usable, so that’s why I’m waiting for improvements in Dots
I hope I answered your question.

I dont get how you do GPU culling with the this api at all. Do you first gather data, feed a compute shader, then read the buffer back on the cpu and omit the draw commands ?

[CodeRoadOne_1]

@YuriyPopov

I dont get how you do GPU culling with the this api at all. Do you first gather data, feed a compute shader, then read the buffer back on the cpu and omit the draw commands ?

Just for clarifications, the code that I did it is not using this API (only URP), but I think it can be adjusted. The basic idea is to store all the data in a persistent buffer on the GPU. Execute a compute shader that will generate a list of instances that needs to be rendered. Using a draw indirect emitted from the CPU for all different materials and the let the compute to generate the actual data for the draw call.
I’ve sent you a private message with more info about this if you would like to know more (I don’t want to pollute this thread more that I already did).

[JesOb]

@JesOb

• Unity have DrawProcedural that is equivalent of glDrawElementsIndirect
  when/do unity will expose MultiDrawProcedural that will be equivalent of glMultiDrawElementsIndirect?

@joelv

I am not aware of any plans for exposing that API. However it might happen in context of the BatchRendererGroup at some point.

I have found that Unity already Expose new Api for this Graphics.RenderMeshIndirect and it will support multi-draw paradigm in future.

Please
make BRG interface like this api so it can easily enable usage of low level multi-draw api in future.
May be expose few different ways to store draw commands, like in new Graphics.RenderX method family, so we can provide draw commands from GraphicBuffer and others

Goals is to efficiently draw many different mesh instances with same material, like:

• draw all different props on level in one go
• draw all chunks of VoxelWorld in one go
• draw one district of level (one constructor) in one go
• perform culling and LOD selection on GPU side write commands and render fast batches from GraphicBuffer
• …

[joelv]

@JesOb

I have found that Unity already Expose new Api for this Graphics.RenderMeshIndirect and it will support multi-draw paradigm in future.

Please
make BRG interface like this api so it can easily enable usage of low level multi-draw api in future.
May be expose few different ways to store draw commands, like in new Graphics.RenderX method family, so we can provide draw commands from GraphicBuffer and others

Goals is to efficiently draw many different mesh instances with same material, like:

• draw all different props on level in one go
• draw all chunks of VoxelWorld in one go
• draw one district of level (one constructor) in one go
• perform culling and LOD selection on GPU side write commands and render fast batches from GraphicBuffer
• …

We have an experimental implementation for almost all of that (regular mesh draw, direct procedural, indirect procedural) in a branch. On DX11 multiple indirect draws is emulated as a loop on CPU side and of course there is no way to provide a late command count as a buffer so all commands in the range will always be executed.

How and when this actually will land is still not decided. We want to get the interface right and ensure it actually covers everything. We’ll get back to you once it hits some future unity version beta, but it won’t happen during the unity 22.X stream.

[linfuqing]

Will this api be used for Hybrid Renderer in ecs 0.5?
And will support the Point Light next version?

[JussiKnuuttila]

This API is not used by the version in 0.5, and is used by the next version.

Point light support depends on URP, the Hybrid Renderer requires a screen space technique for local lights, such as deferred or forward+.

[DDKH]

Will this API support GLES 3.1 in ECS 1.0 ?

[JussiKnuuttila]

@DDKH

Will this API support GLES 3.1 in ECS 1.0 ?

We are aiming for this, and are currently working on it.

However, it is possible that due to technical reasons, the GLES3.1 version might work slightly differently and have different performance characteristics.

[Thermos]

Hybrid Renderer in ECS 0.17 is already pretty fast…Can we expect a better performance by adopting this API when ECS reachs 1.0？