Intel is developing a software rasterizer for occlusion culling purposes. These beauties are capable of culling any kind of scene in screen space, without baking anything… and fast! Unlike Unity’s approach, it works in dynamic scenes and setting it up might just as well be a matter of adding a script. These rasterizer based culling engines are also much more accurate to the point of returning an almost exact set of visible objects… though as I noticed, if you’re CPU limited, you can decrease the resolution, which considerably cuts down culling times and still yields good results.
So what’s the catch? It’s just an algorithm designed to work with a specific engine. The goal is to port it to Unity using the native plugin interface. Unless I missed something, it has a VERY permissive license. Someone could simply sell it on the asset store once it’s done.
Consider it a challenge for anyone interested. You’d definitely have a buyer here
This would be pretty tricky to integrate within Unity without access to the low level rendering pipeline, I would think…pretty sweet algorithm, though!
I don’t think so… OnPreCull: Gather gameObjects → send them in to generate occlusion map → send their bounding boxes in → disable Renderer if not visible. But I see what you did there
That could be possible… as long as Mono supports SSE and isn’t marginally slower than C++ code. There’s some low-level stuff going on there.
Hm, taking a closer look, this actually could be possible - would ideally need to be done after a frustum cull has been performed though.
One of the biggest issues there is sending all of the game objects efficiently. Within the engine, Unity would already have a list of all objects that have not been frustum culled, and could send that to the occlusion culling system - however, we don’t have access to that, and would have to create that list ourselves…which means frustum culling would have to be done again, the list would have to be assembled again, and then sent off for occlusion culling.
If Unity provided a version of OnWillRenderObject() with a Camera parameter though, that would work perfectly and give a nice entry point.
As for C# vs native code…it may be possible if extra care is taken to make the code as fast as possible. But I’m willing to guess it wouldn’t be worth it on any platform without SSE (Mono.SIMD, PC/Mac standalone only) and even then, would be pretty nontrivial to make it speedy enough.
There are some Mono compatible libraries that will take care of fallbacks for CPU’s not supporting the latest SSE versions as well. Just Google for them. Not sure how compatible they are with Unity.
Good point. Do you think it’s safe to assume Camera.current is the camera that issued the OnWillRenderObject call? I still doubt passing each object individually like that would be any faster than passing the whole array at once, even at the cost of performing frustum culling twice, which both engines handle for you. I searched around a while ago for a way to get an array of all renderable objects and it turns out root.GetComponentsInChildren() seems to be the fastest one… It cost me 6ms to get a list of about 2000 objects 100 times. Just for comparison, simply iterating over them took around 4ms. That seems acceptable. With even a large scene of 10k objects, it would take just 0.329ms to gather them. Not to mention a basic optimization would be to pass in as occluders only the objects that were visible in the previous frame, which shrinks the number down a lot.
That would be pretty cool. Although I think it’d be very difficult to replicate it and much less allow it to work natively with Unity but I’m a simple guy so I can’t say.
