This is a module that detects which instances are in your camera’s view, at a certain distance from the character, and runs functions on those instances which have been moved in/out of your camera’s view.
Why should I get this?
This is very useful for optimizing your games, as optimizing a bunch of particles, textures, high-poly details, dense part areas, or other memory-intensive aspects of your game can be tedious when you want to still keep as much quality as possible. This module helps you do that.
Doesn’t roblox handle this?
Rendering-wise, yes. But computing-wise no. For example, with particles, you get a ton of lag if too many particles are being spawned at once, even if you’re not looking at them. The computer still has to account for what stage of the animation each particle is in, the speed its moving at, its rotation, size, transparency, etc, so when you do turn back to look at it, it seems as if it’s been rendered the entire time. This comes at a cost, and for most things, you don’t need to pay it.
Examples of Use
Here is a video on examples of how you can use it
Here is a test place showcasing the service at its simplest level: When you look away, the parts turn black, when you look back, they turn yellow.
The CFrame property of Attachment is in local-space, not world-space, therefore this would not work.
Why did you get rid of the typing? It is just intellisense information, to help when programming, and does not actually change how the code runs (plus there is a \ which would cause an error).
Onto the module itself:
There appears to be a random server-script that does nothing but print “Hello world, from server!”, as well as a localscript that appears to be a test script and uses the CollectionService tag “TestTag”.
The code structure is a bit weird, why is this client-side culling system in a shared folder instead of the client folder? I am not very familiar with Rojo project hierarchies, but I am pretty certain it should not be like that.
This is extremely useful for conserving the lua heap and memory
What? Lua heap is memory used by Lua code, not by objects being rendered. Also, culling objects do not remove them from memory, especially on the client, it just stops them from being rendered.
Some benchmarks would be nice.
Currently, it seems pretty barebones right now. It doesn’t even appear to cull objects on it’s own, and seems to be more like an overcomplicated distance culler.
There is a video of roblox doing that, I’m aware. But if you tested for yourself in studio (dont worry I’m bringing benchmarks), leaving particles, textures, and other things in the workspace without looking at them, they still put a load on your computer.
This is not a ‘traditional’ frustum culling tool where the instances get ‘removed’ and put back. Lets say you had an object that you attached a bunch of connections to, but was far away so it didn’t matter whether or not those connections fired: Thats a waste of the lua heap, because you’re never going to see it.
Its a tool to help you cipher which things you need, and which things you dont. Of course, you can use it like a regular frustum culling thing, but like you said roblox already took care of that. This is a tool, not a package.
They both do the same thing. If you want it to be more organized for yourself, you can simply move it to the client side, but both StarterPlayerScripts, and ReplicatedStorage replicate from the server to the client, meaning there will always be a copy on the server.
It has extended functionality rather than just removing the objects when outside the fov or beyond a distance. Maybe you don’t want it completely removed? Maybe you just need all of its events disconnected. Ok then you can assign your own functions to said culled objects to fit your needs.
Aye I liked how you provided reasonings for how it could be useful beyond what roblox already does with its frustum culling, I was wondering anymore about some things that could be optimized in the background?
Kind of a side question but i’m also working to optimize my game so for any device poor or high its run for performance, but not making everything low quality, but things up close an okay quality for lower devices, but good for higher ones, but in the end the quality gets reduced in distance. I was wondering if that quality could be reduced by performance and not just a simple 500 studs here and 250 studs there like render fidelity’s automatic mode, but yea I hope this is also interesting for you, and thank you for your system.
MrChickenRocket’s article provides a bunch of ways to optimize your experience, alongside metrics to aim for.
A one of the big ideas of optimization on lower-end devices is reducing the number of draw calls, per scene. The details about what draw calls are and how to reduce them you can find in his article. I do believe he provides a tool that has distance culling with custom Levels of Detail which removes a heavy load on the rendering side for lower end devices.
What CullService can do alongside that is add additional functionality to objects that are farther away/not on screen: You could set up a system where the objects closer update more frequently than objects farther away, for example.
In terms of reducing it by performance, I’m not exactly understanding what you mean; I’ll answer it in two ways:
If you mean to change the distance at which objects are culled based off graphics quality, you can code that yourself and change the distance whenever the user graphics level changes.
If you mean by changing the distance based off fps, or through the task scheduler, that implementation is a little more complex to fit into a post, but I do know of a tool to help with this hurdle here. It basically moves scripting tasks over to the next frame cycle if the current one is full.
Ya I’ve checked out his article I didn’t like too much of how he performed his optimization for rendering with zones and small details disappearing. Not that they’re bad but I’ve been looking to figure out something thats more systematic like similar to eye vision. If you have a bad computer or bad vision, details are going to be a bit worse, or if you have a better computer it’ll be better, but overall they’ll have the same render distance.
With CullService I’m thinking I can use it for something like that with culling certain things at this distance if you run this graphic setting, but a bit further if you run that one. I don’t wanna clutter too much here, but I found liking this tool as it felt like something like CollectiveService where I can just reference the tool and use it, not feel like using an entire module plugin.