No-Draw & LOD systems

Hello guys! :smiley:

I wanted to suggest the following performance-aimed suggestions:


The No-Draw property basically grants the developer the ability to make surfaces of parts that aren’t in sight invisible or non-existing to reduce unnecessary lag. This seems to be a common and an essential performance improvement for many game developing software.

Example video:

LOD (Level of Detail)

You possibly know this system, as it’s been recently added to Smooth Terrain. But perhaps add this to meshparts or unions. What it’d do is, just like Smooth Terrain, decrease the polygon count when it’s further away. Though, as some games could rely on a far distance, perhaps making it optional under Workspace’s properties would do?

glurbman thought of this recently and informed me as he doesn’t have access to the Dev forums yet.

Thank you for reading & considering!


I’m pretty positive that’s how rendering engines inherently work in general, you can only render what is visible in the shaders view matrices. You can’t render whats not on the screen, and generally you wouldn’t make render-calls for triangles that are known not to be within the rendering view.

Maybe I’m wrong but I’m pretty sure im not

1 Like

That makes sense, but on the other hand, I believe that it currently renders a specific distance around- or in front of your character. If there’s items, like parts with textures/materials, hidden behind e.g a mountain of Smooth Terrain, it’ll still be rendered- but unnecessarily.

Though I don’t have much to proof that, so it might be wrong too.

EDIT: Oops! I made a mistake @ROBLOX_MANNN, sorry!

This is an example of what he meant to say.

This could be implemented pretty nicely as a SurfaceType.

1 Like

ROBLOX doesn’t use No-Draw? That should be added next to player culling ASAP. I can see that increasing the living hell out of xbox/mobile performance

1 Like

Feature Requests > Client Features is the place to be, this wouldn’t be only a Studio feature but rather something new to the engine.

Regarding LOD I think this will be less useful than you think, because I think it will be a hard problem for the engine to decide what would be an appropriate approximation of your map at a distance. LOD is probably better done by developers themselves so that you can define high/low detail models and switch those in/out for certain objects in the world.

1 Like

The video in the OP shows Hammer, which is a BSP (binary space partitioning.) That sort of thing is really easy to do with BSP, but modern game engines don’t really use BSP anymore because it’s not necessary. Nowadays, we just do frustum checks with acceleration structures.

For example, you can split your game world into eight cubes and determine what objects lie within each cube. If a single cube contains too many, you split it into eight smaller cubes and repeat the process until every cube has a maximum number of objects in it. Now, when you render, all you have to do is figure out which cubes you actually want to render, which is really fast because you can make lots of assumptions knowing that you’re only dealing with perfect cubes of varying size and position. Now your list of things to draw can be a small subset of your entire scene. This subdividing cube approach is called an octree.

ROBLOX uses something else that I’m not that familiar with yet, but it is fast.


I see :slight_smile:
Thank you for your reply.
Could you explain what would be the best option to keep performance and quality optimized?
I’m interested to know, as I’m currently making an enormous map. But loading takes some time, and I can imagine that some computers can encounter powerful lag on it. I’d like to prevent that from happening, but I’m not sure how.

Oops, thank you for correcting that :smiley:

To expand on this, the Source engine (not sure about GoldSrc, Quake, etc) uses Potentially Visible Sets to determine visibility of certain areas of the map. Here’s a demonstration.

Say you have an L shaped hallway, connecting to two rooms:


Potentially Visible Sets (PVS) separate the map into different sections, with each section containing information about what sections it can ‘see’. If you were in the bottom right room, you would not render the top left room, and vice versa. The only event in which both rooms can be rendered is if you stood at the corner of the hallway and positioned your camera to view both rooms.

These sets are calculated at compile time of the map, along with lighting and other processes that effectively improve gameplay. However, depending on the size and complexity of the map, this process can take a while to complete.


The Source Engine is fun.
I actually ported Crossroads into Hammer using some Lua code about a month ago.