Yeah, I sorta figured this out. Thank you though! Glad to see people actually helping on Devforum.
This will be useful, but I believe avatars and things with animations will get culled in the future anyway.
There’s a rig that can use clothes without a Humanoid, and have transparent limbs, which will probably be useful to use with this if you care enough. I don’t know much about it, but I saw it when scrolling and skimmed over it.
Is there a Fast Flag to disable this 
I don’t believe that Occlusion Culling uses magic. I think some hardware has performance issues with this.
Why would you want to disable this? Have you experienced any issues or FPS drops? If not, I’d recommend keeping it on.
Also:
DFFlagUseVisBugChecks set to false SHOULD disable it. Someone correct me if I’m wrong.
Experienced some “lag spike” since there was a BetaFeature Fast Flag that you could turn on to try out in Studio.
Debugging that is a bit more difficult for atm.
The MicroProfiler is not like vprof from the Source Engine. And whenever DPI update ran out, the entire UI for it stretched.
I appreciate the detailed response! The system around good and bad occluder seems pretty smart to be honest for props to yall for trying to make that as efficient as possible!
And on the topic of the suggestion, you know what would be cool to have? Invisible occluders. I do appreciate that we can technically work with the occlusion culling system to more efficiently manage occluders and occluded instances but there are cases in which we can’t exactly create a good occluder due to high mesh complexity. So my suggestion and idea would be the ability to create invisible occluders! For example with that door example, i think it would be more efficient if we simply made the entire door a bad occluder and instead opted in using an invisible single face mesh as a good occluder from inside the actual door!
Ok, this is a much and more consistent test, making sure I didn’t leave the detail levels in different settings. 
I also made sure to check the wireframes in Studio standing in the same spot to make sure I had a “before” culling and “after” culling benchmark on my low end system that use to be awesome 20 years ago. 
Windows 7 PC Specs (with the amazing GeForce 8400GS !!):
Studio Check Without Culling, the second floor is rendering underneath as well:
Benchmark in-game for the PC at the same spot (2.3 FPS):
Studio Check With Culling to make sure the second floor is NOT being rendered underneath for the most part:
Benchmark in-game for the PC at the same spot again (3.8 FPS) and the fog started working? 
So, the gain was from 2.3 FPS to 3.8 FPS (39% improvement) with the same detail levels in both places this time, the only difference was the bottom floor was being rendered the first time and the second time, it was being properly culled. This is an extreme case of course, don’t everyone take this to believe every game on Roblox is going to speed up by 39%, it just works well in my test case. 
Just how “detailed” must a mesh be in order for it to not be considered for culling? Is this a metric of triangles, and if so, how many?
Are there any plans to have these be considered for culling in the future (if an object is culled, disable its shadows), or have a setting for this in Workspace or Lighting? It would actually be extremely benefitial in some maps, where shadows take the vast majority of triangles right now due to occlusion culling having been enabled, and where disabling shadows wouldn’t actually cause any noticeable visual impact.
I tried it, it does turn it off. But there’s more of those flags, so I am not sure how much this turns it off.
Disabling it didn’t solve this strangeness I experienced in Studio, so it must be something else OR I need to re-open Studio, because I probably can’t trust the DFlag actually being dynamically.
Damn! Are there roblox games which the 8400GS can actually run half decently? Or does it just struggle even on a baseplate?
My game is an extreme example because it uses so much client memory and the test scene above was the “lowest” tris count one I could find that didn’t have my character scooting around at 1 FPS
In most other Roblox games, it can actually get +60 fps depending on the detail settings and how much is going on in-game. It’s not going to play Fisch very well, but other games seems to run quite well. Or maybe better put, at an “acceptable” level.
thats insane, and considering most experiences (as far as im aware as a player) are in-doors or a small packed area, perf gains should be pretty noticeable, like in your case.
Heck, even open world games should have some performance improvements when culling trees, rocks, interiors, etc…
And this is just the beginning, some things (notably Players) dont get culled yet.
Unrelated to this Update. But does Roblox plan to add native linux support?
I found 2 different issues while playtesting in VR. One is VR exclusive and the other seems to be universal.
In the first clip, the helmet mesh doesn’t occlude well with structures made of lots of parts:
In the second clip, the culling appears to be relative to the right, VR viewport (video recorded from left viewport). This can also be seen inside the house in the first clip when the gun blocks the right viewport. When closing my left eye and only looking through the right viewport, I can’t see this:
this is actually amazing! ik literally everybody before me has said the exact same thing, but it do feel it deserves that praise. thanks roblox!
yeah i imagine accurate occlusion culling on vr would be pretty difficult. i think it would be best for roblox to just make it a little less accurate for vr if they cant figure it out.
now this is what i call this update a game changer because you change the games, an absolute win
Okay, who let Roblox cook? Nice one engineering team! 
We’ve been waiting this, thank you!
I’m still confused, is Occlusion Culling automatically applied to all experiences?
yes
