Distance Culling & Precalculated Visibility

Help and Feedback Scripting Support
, ,
#1

Hi there, builder Souleth here.

Recently, MrChickenRocket posted a fantastic article that can be found here: https://devforum.roblox.com/t/real-world-building-and-scripting-optimization-for-roblox/3127146. I’m a diligent builder and strive to deliver the best results to clients, always pursuing new skills in modelling, texturing, lighting, terrain and so forth. I’ve always ensured games are optimised by removing faces or doing kitbashing. I always knew something like precalculated visibility and distance culling was possible but never attempted to learn how.

I’d like to ask sincerely for assistance in learning how to do this effectively and incorporate it as part of my skillset. I think we’re in an era now where the builder title should include some level of scripting that is relevant to optimising the game instead of shrugging it off as “well, the scripters will sort that out.”

So, if you can and have the time, I’d appreciate either a) some tutorials to build up the necessary knowledge to use functions like destroy() and player touched or player connect, or b) a step-by-step process to apply it to the game. Additionally, and I think this is common sense, any additional scripts to prevent exploiters from manipulating the destroyed parts/triggering visibility when it shouldn’t.

Thanks a lot.

#2

Hello Souleth, your enthusiasm to learn new skills is great! While I don’t personally recall good tutorials which will help you with this goal in mind, I just wanted to share this bit of information with you.

Making your own, effective, distance culling system might not be the easiest task unless you’re knowledgeable on the topic (as for what you describe doing it step by step from scratch with a script). I think for your skillset what would be best for you is a pre-made system for you to work with.

Thankfully, this is exactly what has been provided in the article you’ve linked!

image

It is simple and low level, which is precisely what you should be seeking for, as to try to be the least invasive as possible to your clients’ game their game logic.

working with it is straightforward:

  • Paste the script on ReplicatedFirst
  • Add a tag to all the BaseParts / Models you wish to include with the tag name of “Detail_Small”

And that’s it!

(only additional thing to note is that the models you include need to have a PrimaryPart)

1 Like
#3

as for Precalculated Visibility, there is a script available for that as well (ZoneManager), and while it is definitely useful, In such case I do consider one should consult with a scripter over the possible breaking changes this could bring, as this case is a little more delicate

1 Like
#4

The distance culling is of course less complicated haha :slight_smile: Thanks for the add on.

I was wondering if the script provided by the OP also accounts for exploiters? (though I can’t imagine how distance culling could be used to screw with the game but you never know).

#5

I realised that half-way into the script:

local invisibleZones = {}
for key,zoneRec in zones do
	invisibleZones[zoneRec] = zoneRec
end

Just learning now what de-parenting does, I assume scripter-jargon for setting visibility to 0?

Will definitely consult, although this post is somewhat a version of that lol.

#6

as a general rule, basically anything that is implemented client side can be tampered with by an exploiter, theres no easy solution to that.

it’s not the same thing, although it reaches a similar goal.

setting transparency to 1 (what you call “visibility to 0”) makes the object… invisible. However, the object still exists within the game world, and participates in physics, collisions, and rendering (despite not being visible)

parenting it to nil removes it from the game world, it is no longer updated by the server, and also doesn’t participate in the things stated above, while also being invisible. It truly helps with performance, transparency arguably doesn’t

#7

So I studied both scripts now in detail and understand how parenting works a bit more. The nil argument is pretty useful.

I wanted to ask (probably a sidenote but still under the heading of optimisation), do meshes with deleted faces have those faces appear in nil as well? Or does the game completely recognise the meshes themselves? My hope here is that the game isn’t trying to calculate/render the geometry of the missing faces when used in scripts like precalculated visibility - I heard someone mention this a while back.

Also, thanks for explaining that.