my dream come true i was waiting this for YEARS!
Amazing!! Can’t wait to use this.
thought i’d share demos
without occlusion culling
with occlusion culling
the map
(163,240 parts)
this update works really well for part-based maps, infact, overall we see like a 20-40% reduction in draw calls for any part-based map we plug it into even when it’s not occluding that much. i have thrown 450k part maps at this thing and you can get a smooth 600 draws like butter. this is so appreciated because traditional LOD scripts we were writing and others we were using would often over-chew into CPU performance and could not do occlusion culls very well. while this one is just incredibly light. curious to do more low end device testing and see the net cpu time diffs.
it’s really a game changer for developers, optimizing these insane maps takes months of work for a coder and the builder and even then you won’t get peak performance, this makes me think it’s possible, and better yet available for anyone who tries. i am very thankful for this update! massive blessing.
13 Likes
YAAAAAAAAAAAAAAAAA! I cant wait for it to work on published games too, my project will be a laggy one and I really want it to work 
7 Likes
Is there already a release date? I’ve already tested it in the studio and honestly it’s extremely accurate and incredible, I can’t wait for this to be officially launched.
2 Likes
This is amazing. I’ve waited for this for an eternity. I have so many hidden caves and caverns and gorges that block line of sight all fully fleshed out with foliage and detail where I’ve already had to crunch polygons down to nearly nothing so that the game runs on phones.
I did want to bring attention to this FR. What sort of timeline would we be looking at for just this? I don’t care about terrain occluding parts, I do care about parts occluding terrain. Delaying just that use case for N months/years to offer complete terrain support all at once would suck.
All I want now is better control over my LOD models so that I can use streaming models and preserve my game’s art style. The algorithm Roblox uses to generate LODs for models is extremely squishy and unsightly. I love that they display when using streaming, but they look hideous when contrasted against the low-poly loaded in world.
I have to choose between a CPU bound distance culling system with custom LODs optimized for polycount and aesthetic, and streaming which takes advantage of all of Roblox’s optimization work and shows LODs while everything hi-fi is streamed out, but either looks like badly lit melted chocolate and uses way more polys than is necessary, or doesn’t change the model at all for some reason.
This is really the last thing I desperately want in the direction of rendering optimization.
Treetops are totally molten, looks like I blew a hairdryer at it for 20 minutes… My art style is low poly with strategic hard edges. This is incompatible with how Roblox smooths the entire LOD model.
13 Likes
On the topic of optimization, is it possible to add custom/manual LOD models into the engine? It would prevent models looking weird and maintain the artist’s control over how it looks at longer distances.
There could be a property within meshparts that specifies meshIds for each level of detail (when no mesh is specified it just uses the current system)
I often find that models when viewed from a far distort in a really noticeable way ruining immersion.
2 Likes
is occlusion culling does not render object behind the fog too ?
4 Likes
Thank you for your response. In fact, when we create games, we often encounter a lot of model stacking. The size and shape of the models are also very diverse. If I place many such models in front of me, the system may not be able to decide ‘which models the developer wants to hide’. If there could be an option to allow developers to choose which models can be hidden, that would be great.
3 Likes
This is an amazing update, this is going to allow us to have better performance in our games which allows us to have even more detailed builds and or larger maps. I can’t wait for this feature to be released completely.
Is there currently any timeline for when this will be released for use in our experiences?
2 Likes
It doesn’t cull skinned meshes yet, no matter if they have a Humanoid or not.
2 Likes
would it be possible to have a way to check if a part is occluded?
3 Likes
I think it could be great! It would be amazing to k ow what is culled because it also means we could disable some animations and routines througha script.
- I would not mind things outside the frustum being marked as occluded as I believe frustum occlusion is in effect and would count as being occluded.
- I can see why the shadow one is a concern. If one someone was using a acript to run animations on an object and the script stops running the animation because the object is culled, the shadow would stop animating which would not look good. I have to imagine the safer route would be to only count it as occluded (on the API side) if all representations of the object are occluded. This should reduce the false positives.
- I believe the tradeoff would work well on our end! As long as documentation makes it clear that theres a chance that hidden parts might not occlude, I believe this would be amazing for further optimization!
Important to mention that they’re working on dynamic occluders though! Also important to mention that mobile devices and weak computers from 10+ years ago did not have support for the technology.
Here’s a post where Roblox staff discuss this along with why it can’t just be a PC only feature.
4 Likes
Aa mentioned by the actual post, it is not that terrain will not be included. It is just coming in a future update. They have a list of things to support and next will be Avatars.
2 Likes
Hi there! We understand your points. Some developers have expert knowledge and are willing to put the authoring time in order to get the most out of a system.
For Occlusion Culling specifically, what you’re seeing is just the first version we’re trying to release. Our goal was for it to work out of the box with no mandatory authoring so that it covers the widest set of use cases first and can be useful for the full spectrum of developer skillset.
However, this is just the first release. We will learn a lot from how it goes, how useful developers find the system to be, what extensions and exposed controls would be useful to make the system more effective in the hands of developers (while not penalizing those ramping as developers).
Really appreciate your feedback, thank you.
10 Likes
A rare W from the Engine team.
1 Like
I hope you could release the first version for the public, it seems to be stable, so for the long run it may just be great!
This is especially true with the fact that we’ve been asking to at least separate render distance from the graphics bar for years and they respond saying they want everything quality related to be fully automated lol
1 Like
You have been living under a rock if you think this is rare; the engine dev branches over at Roblox have made it clear in recent times that they are, in fact, incredibly cracked
7 Likes