@ProgramDude are there any internal performance benchmarks you or the team would be willing to share based on your testing? I think many would be interested about the performance gains from different experiences on the platform based on device etc.
whats the fflag for it? i wanna run some tests
FFlagEnableVisBugChecks27 and DFFlagUseVisBugChecks
Ever since occlusion culling added ive noticed shadow flickering and geometry flickering in various games. The flickers are decently rare and somewhat inconsistent but they happen.
This was an extremely quick release compared to what I expected. I’m impressed, this will most definitely be allowing Roblox experiences to be not only bigger but more detailed. The showcase I’m working on will likely be able to work on mobile entirely due to this update.
Here are most of the FFlags I’ve found related to occlusion culling. You’ll have to validate most of these yourself as this was posted before it was released to the client and may contain inaccurate information. (that and I’m too lazy to edit it)
If you don’t know what you’re doing, just stick to DFFlagUseVisBugChecks. (FFlagEnableVisBugChecks27 no longer works, 28 seems to be the newest one, and is set to true by default from what I know)
thank you, DFFlagUseVisBugChecks works beautifully on mobile (confirmed that its not enabled by default yet).
seeing some perf improvements overall even with the unfinished release.
sorry what, you can use FFlags on mobile???
yes, you can either edit the apk or use root.
The highlights I was using were the “Occluded” depth mode. Should they be excluded from culling or should they have disappeared along with the other parts?
Occlusion culling runs concurrently on a separate thread. The simple answer is that we do more work on culling if we’re finishing before the rendering code needs visibility results, or if we are heavily GPU bound. We do less work if the opposite is true. There’s a buffer zone and a gradual transition so that we don’t keep ping-ponging and we don’t get tricked by short spikes.
This is designed to avoid the very problem you’re concerned about, and to do it automatically for any scene on any device, and to do it by degrading gracefully as needed. It will also dynamically adjust to changes in thermal throttling on a device, since that is no different to it than the content suddenly becoming more or less expensive.
We empathize with experienced devs who want full control to fix problems with automatic solutions. My personal belief from my own professional experience (not a Roblox official position) is that hinting works best when devs know stuff the engine can’t, and automatic solutions work best when the engine knows stuff that devs can’t. In this case, devs can know more about what would be good occluders, but the engine knows more about where time is going and how much time we have to work with. So if we do find we need to provide performance hinting, it will probably be hinting about what occluders are good, while leaving the automatic effort adjustment in the engine.
If you want to help occlusion culling be more efficient, use big occluders with simple geometry. Block parts are ideal. Low-poly mesh parts also work well. You can split your meshes into a “low detail” mesh that is used for both rendering and occlusion, and a “high detail” mesh that adds all the cool details just for rendering. As an example, you can use a block part for a door and a mesh part for the doorknob and hinges, instead of doing the entire door as a single mesh part. The engine will automatically detect that the high detailed mesh is a bad occluder.
And yes, we recognize that this suggestion is an argument for devs to have occluder mesh hints. We agree that there are many good arguments for occluder hinting, and we don’t want to shut the door on hints coming someday. At the same time, it is important for there to be a good “no effort required” solution for existing places and novice devs. Once we see where the “no effort” solution falls short, we have a better idea of what hints are actually needed – or (less likely) that hints aren’t needed after all. But even if we know something would make Roblox better, that doesn’t mean we have time to do it! I’m sure you as devs are all aware that you have more ideas on how to improve your products than you have time to actually implement.
Here is a more extreme test I did on a very low end PC. (by today’s standards)
Windows 7 PC Specs (with the amazing GeForce 8400GS !!):
No Occlusion Culling (1.6 FPS, oh yeah!!):
Occlusion Culling Helping (4.8 FPS, now we are gaming!! ):
FPS aside, the big help is reducing the tris count. Also, there a whole other floor underneath, so basically helps to cut down the tris count by a loooooot…
I don’t know how it’s even possible to make a worse PC after seeing that FPS
i think you gained most of your fps by going from 21 graphics to 6 ngl
another comparison with the same graphics incoming??
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