I wanted to suggest the following performance-aimed suggestions:
No-Draw
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.
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.
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.
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.
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
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.
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:
R
X
X
X X X R
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.
