Just tested this, my triangles in my super dense area went down from 589 million to only 16 million triangles, THANK YOU ROBLOX!!!
I noticed that Meshes hidden by terrain do not get culled, will support for this be added in the future? One use for this would be for example mountains would cull towns that are on the other side
Long awaited feature and the first step to the optimizations route, Absolutely loving it.
This is wonderful, all we really need to be added that’s necessary for performance is culling lights and terrain.
If I enable this beta feature, will it replicate to in-game (outside of studio play)?
It is a “Studio Beta”. It is exclusive to Studio. If it is available for Clients as well, it would be a “Client Beta”, like Script Capabilities.
I have waited for Occlusion Culling to release for a long time and I am glad that it’s finally here. Though I am disappointed that the initial release only included support for meshes and parts excluding avatars, I hoped that it would at least bring avatar/character and terrain support in addition to meshes and parts in the initial release due to the long time that this feature has took to release. I would be fine though if support for other object types won’t take too long to be added, and I really hope that would happen. I wouldn’t want to wait for avatar/character or terrain Occlusion support to be released after 2 years for example. Please don’t disappoint with this
Learn blender. Map assets with blender only take a few hours to learn.
still unions are good if your pc doesnt support 2.79+ and 2.79 looks a program from 19s and its more harder than 2.8+
unions are not nearly as performant, they’re better now but still are really unoptimal to be using en mass
An insanely powerful feature that will be even more powerful once it gets support for more object types.
Thanks for this report and easy repro case! I’m looking into it right now. It isn’t using the proper size for the special mesh. That should be an easy fix once I find out why, but it’ll take about 2 weeks for the fix to go live.
Thanks again!
Sadly, no, we can’t support transparent SurfaceAppareances. Occlusion culling only works with fully opaque meshes. With a fully opaque mesh, it is trivial to know if any part of a polygon should block stuff behind it (the answer is always “yes”). With partial transparency, answering that becomes a significant amount of computation.
Partial transparency support would be awesome if it was possible, but the reality is that it is simply too slow to be worth it.
Holy, at last we have received one of the most useful features of all time. Can’t wait for this to be expanded!
When will it be released though?
I have a very detailed map made mainly with mesh, there are lots of props inside the building. The occlusion culling is working but it’s still rending at 24fps in studio, the same as with the beta feature turned off.
Is there a timeline for when this gets pushed to prod for all experiences? I would love to see the performance boost in a live game since my studio is just so laggy compared to the player.
@ProgramDude would it be possible to enable Occlusion Culling in production for this experience?
Occlusion culling doesn’t depend on the amount of content. One purpose for it is to enable larger and more detailed experiences, which means more stuff!
But, occlusion culling does depend on having “good” occluders. It prefers lower cost occluders. The lowest cost occluder is a block part. Roblox experiences have lots of block parts, and boxes have nice mathematical properties, so we were able to optimize them to about half the cost of a box-shaped mesh!
It can use meshes too, except for CSG meshes and terrain meshes. Each vertex and polygon add to the cost of a mesh. So, more detailed meshes and smaller meshes are usually not good occluders. In your screenshots, my first impression is that your meshes are probably too detailed to use. I’d have to run the place myself to be sure.
This is due to an optimization. Like most occlusion culling systems, we don’t test whether any polygons of an object are visible, we test whether the 2D bounding box of the polygon is visible. This gives most of the benefit for a fraction of the cost, so it’s a good tradeoff.
Occlusion culling is trying to prove something is hidden. If it can’t prove that, it has to assume it’s visible, or else you’ll ruin the experience. So, there will be cases like this that something is hidden, but it’s too much work to prove that, so it draws anyway.
I’ve sketched over your first screenshot to show why this happens. The bottom left corner of the 2D bounding box of the back block pokes out from behind the front block. So, this is just a tradeoff between accuracy and performance.
A similar issue can happen when something is behind an occluder but close to its edge. To put it simply, some complex technical details mean it can’t always be confident where exactly the edges are relative to each other, so it fails to prove the object is hidden, so it draws it to be safe.
Trusses should be culled, but should not occlude other stuff. I’m looking into that. Thanks for the report!
The reason the shadow draws is that objects hidden from the camera may still cast a visible shadow., so we can’t discard shadow casters with the current technology. If you have expensive shadow casting geometry, occlusion culling won’t make that any faster.
LightBeamRays is correct. As an optimization, if a part is too detailed and too small, we don’t even consider it for occlusion.
Think of all the little items on a desk. Normally, we don’t want to waste time considering those as occluders. But, if you put the camera really close to the desk, like imagining you were a bug on it, then a pen lying on the desk may actually become a great occluder.
To handle this automatically, we have heuristics based on how expensive an object is (polygons and vertices) and how big it is on the screen. Pragmatically, this must apply to individual objects; it’s simply too much computation to figure out when a bunch of small objects combine to form a good occluder, especially since the system is fully dynamic.
Highlights should still draw for a highlighted object that is hidden behind geometry.
If you have a case where something is hidden that shouldn’t be, please let us know so we can look into it!