It looks like we have not yet rolled out the client improvement to only disable culling on highlights when needed; the current client still disables culling on all highlights.
Oh crap, you are right, forgot about those darn settings. I have to do two takes because I don’t know if there is a way to turn culling off on the fly, so I had a floor that was transparent (like 1%) to increase the tris count and one where the floor was not. Need to rerun the test then!!
It’s no problem since if a highlight can be seen through walls, culling won’t make sense on it.
Is terrain or the lists for the future?
Just wanted to comment that this is a really interesting optimization technique that I hadn’t thought of–splitting meshes off to let the smaller, expensive blocks not render, without having to wait for the whole block to become out of bounds.
It took so long because it’s more advanced, unlike other games made in unity or whatever, this doesn’t require baking and is fully live
Thanks for the repro and for the suggestion niveks1436. This unexpected behavior is caused by negative scales, just as you said. It is acting as if it is taking the absolute value of the scale.
Unfortunately, the fix won’t roll out until next year.
These objects are scaled negatively in the y and z axes, so you could get the same visual result by rotating 180 degrees around the x axis and using only positive scales, and then they would work with occlusion culling.
Okay, thank you for the update
cc. @TimeFrenzied I tested this out, and models that only use Animators and AnimationControllers as opposed to Humanoids do indeed get culled in real-time! very cool stuff
Tysm Roblox. I was waiting for this update to drop since it was announced in the RDC, Itll be a game changer for sure!!! Man im so happy
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.