#Hooking into the gpu occlusion system

1 messages · Page 1 of 1 (latest)

inland relic
#

My use case is the following. Recently my artists started placing debris in our levels, broken bricks pieces of concrete rocks etc. now they render pretty great with the GRD, but I would like to not have 10k+ gameObjects in the scene so I would like to bake out their positions and render them with a InstancedIndirect call. However I can only do frustum culling with this and the nature of our levels is such that actual occlusion culling would tremendously benefit the rendering of such debris. So my question is if it is possible to somehow hook into the gpu occlusion system and get results from it in order to control what gets rendered from the instanced indirect calls.

weak tinsel
#

Hey! So not answering the question directly because I would be curious to know what is the actual problem with that

but I would like to not have 10k+ gameObjects in the scene
Scene loading time maybe? GRD will do the kind of baking you mention automatically and disable the MeshRenderer components already. So I don't think you would get better runtime perfs at least

inland relic
#

Scene loading is a major part of my problem yes.

weak tinsel
#

Right then that's a bit tricky. I'm not sure there is an easy way to do that currently. Occlusion culling compute shaders only work with instances managed by GRD, and there is no way to inject custom instances to GRD from the outside right now

inland relic
#

GRD batches up to 64 objects in the same draw command right ? Rendering the debris with a instanced indirect call would be faster ?

weak tinsel
#

When using GRD & GPU occlusion culling normally, instances are already rendered with instanced indirect draws. So you shouldn't get faster than this by using custom source data

#

Like I said, runtime perfs should be the same

#

If you really want that, I think you would need to fork the SRP core package and add some public APIs to inject custom data to GRD. There is no built-in support for this yet

inland relic
#

I really hate forking the srp packages. When you say “yet” does this mean that it is planned for the future ?

#

I guess the public api would have to handle expanding the instances array, registering the mesh, writing the metadata etc etc that BRG needs right?

#

Anyways being able to inject custom rendering data into the GRD would be a great feature.

weak tinsel
inland relic
weak tinsel
inland relic
weak tinsel
#

I'm not sure honestly. GRD occlusion culling is not connected with vfx graph at all. And I don't know how customizable the vfx API is in this regard. In theory you would need to customize the vfx indirect draws to take into account the occlusion buffer. But there might not be an easy way to do that right now

#

Regarding Umbra, I think vfx occlusion culling is just not supported

#

Would need a vfx person to confirm those things

inland relic
#

But again feeding the bounding spheres into the gpu occlusion and then getting a readback to disable the whole vfx sounds like it is impossible

weak tinsel
#

Yeah, I think the culling group customization point is before the frame starts to be rendered on the GPU. And GPU occlusion buffer is computed after that

inland relic
#

But do you think there is a problem to bake umbra in the scene to keep using this culling for the vfx while the scene geometry renders and culls with GRD ?

weak tinsel
#

No that should be fine. I don't think Umbra interacts with vfx in any way, but that would need to be verified. Not 100% sure

inland relic
weak tinsel