How do I know Occlusion Culling is enabled in Roblox Client, is it coming in next client version?
Good question! When it’s working well, it’s nearly impossible to tell.
The easiest way is to take our word for it! All Windows PC clients already have occlusion culling enabled.
The easiest experimental way I’ve found is to have a test place with a super expensive mesh or meshes behind a wall. Make it so the wall hides the expensive stuff, but you can walk around the wall to see it. With occlusion culling enabled at minimum graphics settings, you’ll see a big change in FPS when the object is behind the wall vs when the object is visible. With occlusion culling off, you’ll see little change in FPS.
The change in FPS should be comparable to when you turn your head to move the expensive object off screen.
This experiment works best when shadows are off! If shadows are on, the expensive objects will draw into the shadow views. The shadow views can easily be the most expensive part of the frame, so the framerate difference will be much harder to observe.
Does this mean any part with CastShadow enabled won’t benefit from this optimization? i.e. we should disable it everywhere possible that makes sense?
Good question, that wording is ambiguous!
It only means that an object that is hidden behind other stuff can still cast a shadow that you see. So, the occlusion culling only helps the camera view. It cannot eliminate any shadows, which means that all shadow casters draw, even if hidden from the camera. In other words, if you have expensive stuff behind a wall, it won’t draw the expensive stuff on the camera view, but it will draw them for the shadow views, so that they can cast shadows that you might see.
The reason we called that out is because it’s easy to think that an expensive object behind a wall is now free. That’s basically true for the camera view! But if your graphics quality has shadows, that expensive object still casts an expensive shadow. It’s easy to forget about the cost of generating shadows, and to forget that stuff that’s offscreen still must cast shadows.
An even shorter way of saying this is that occlusion culling speeds up the camera view only; shadow views are unchanged.
I just checked mine, did a few experiments, can confirm it is active on PC. Mine auto-updated today with file version 0.654.1.52413, product version 0.654.1.6540477
Will NPCS with an animationcontroller as opposed to a humanoid cull? Just asking cus animcontrollers are generally forgotten about.
“Avatar” is just the most important representative of a variety of objects that go through a particular rendering code path. I believe that anything animated goes through that same code path that neither culls nor gets culled (for now).
If you’re curious about a specific case, the best way is to hide it behind a block in Studio that covers your full viewport. If you can still see it in wireframe view, then it doesn’t get occlusion culled! If you want to prove that it could be occlusion culled if it were something else, put a block part next to the object and verify that does get culled.
This experimental test is going to be faster and more accurate than us trying to figure out a definitive list from the code!
Correct me if I’m mistaken, but does that mean it is not possible to test using the Shift + F2 menu where it says “Draw (scene)” and check the tris?
You know, checking the triangle counts is a better idea than checking the FPS. If your GPU is a monster that hits 200 FPS for a billion triangles, the FPS test is meaningless, but the triangle count test would still tell you the answer.
So, yeah. Set it up the same way, with an expensive thing behind a wall, but look at the triangle count instead of the FPS. Thanks for the suggestion!
Thank you for the info Knight, I was wondering why I wasn’t able to see any difference, Do developers have to enable this feature in order to see any difference?
This test seems to confirm that it doesn’t work on large maps, like the issue from the post where this was announced as a beta feature. Was this released to the client before this bug was fixed?
Also, I assumed this wouldn’t apply to existing servers, but since this is done on the client, will it apply to existing servers as long as Roblox is updated, sorta like what happens when editing FFlags?
For anyone wondering, after testing, a regular part with an AnimationController inside of it seems to get culled! Same for a base R6 character rig spawned using moon animator.
Improvements are too scene dependent to give a meaningful number for expected improvement. Even in the same experience, it could save no time for some views, and save 90% of the time for other views. (And this assumes you’re limited by rendering rather than simulation or script.)
One way of looking at it is that occlusion culling changes the expense of rendering from being proportional to how much stuff exists to being proportional to how much stuff you can see. For scenes where these sets are basically the same, like in a sports arena, you’ll see little improvement. For scenes where these sets are drastically different, like one room in a house in a city, you’ll see a giant improvement.
I will say, that I was often surprised by how much stuff it culled. There were outdoor scenes where I thought it would cull maybe 5%, but it was closer to 50%. But arena-like games did often hover in the 5% culled range!
Either way, improvement is improvement. This really matters to the gamers not rocking high end, expensive rigs. A big benefit will be to mobile players once it becomes available to them too. This is a great update because it can fill the gaps that scrip based pseodo culling can’t fill.
Hi there!
Will it be possible to tell (from a script) whether a part is being occluded? If not this is fine–this is really only useful for stopping property setting if a part isn’t in view, plus I am aware it’s difficult to read from the GPU.
I would absolutely love this idea, I really hope they take this into consideration. Perhaps make a feature request about it, linking back to this post. to make it a more official idea?
I wonder if the dev assigned to make it work in Win7 knows about next month… 