Material for smooth terrain underside

I’m suggesting a material that advanced developers can use to optimize in-game terrain, and use for marking unseen parts of terrain. In studio it might appear as a neon orange/red pattern, similar to the CrackedLava material, but in-game it would either not create triangles at all, or appear pitch-black; Studio might also have a property that’s somewhat similar to StarterGui.ShowDevelopmentGui, which could be used to toggle between studio/live-game rendering modes while in studio.

Developers could simply paint unseen terrain with this material.
Before:

How it might appear in studio:
(pretend this has sharp edges and isn’t photoshopped lava :stuck_out_tongue: )

And now it can be more easily optimized by the engine.
How it might appear in game:

The performance boost could be much more significant with large bodies of water:

Aside from optimizing, it could be used as a marker in games with destructible maps to prevent people from cutting through the terrain’s underside. This could be almost like “Bedrock” in minecraft, although it would require some extra lua to prevent terrain-destroying explosions from tunneling into the void:

One caveat might be that adding another material to existing terrain might cause it to use slightly more memory, but terrain compression is really well done and the effect should be negligible.

The name for this material could simply be Enum.Material.None, or perhaps something that better-describes its behavior.

This could be implemented alongside other features in this post: NoRender Surface Type


Partixel’s post also suggests an invisible “NoRender” SurfaceType for BaseParts, which would take advantage of an aging feature (surface types), and enable us to both optimize our games, create parts that seem to have a different color/material on each face, and prevent z-fighting.

Before I implemented LOD for the houses in my game, their 2-material roofs/walls had z-fighting between them, and still do when I take full-LOD screenshots.

I’d also like to be able to do things like this without meshes:


And without worrying about wasteful internal geometry:


The engine might already try to do some of these optimizations for us automatically, but especially considering the performance-limitations of mobile, there will always be cases where it’s easier for advanced developers to provide this information.

21 Likes

You are basically suggesting the good old “no draw” surface ; i made a topic about this earlier but regarding to the replies it wont help that much .

Some ppl said Roblox would already prevent rendering of unseen faces ; even though iam not yet sure about that since the performance of a smooth terrain place doesnt feel like it would hide unseen faces /inner geometry .

Anyways i would truly like some reply from a official Roblox engineer about if Roblox either draws unseen faces or not ; since if roblox renders unseen faces than a “no draw” material for smooth terrain ; and a “no draw” surface type for parts would boost up any games performance by an magnificent amount :smiley:

So can someone pls get zeuxcg to reply here ?

Yes, this is correct. Roblox will not bother with rendering anything out of view of the player’s camera, so you can think of it like ‘dynamic nodraw’ that updates based on the player’s camera.

The reason a “nodraw” surface exists in things like Source is because Source pre-calculates the lighting of every brush while it compiles the map, which can get very intensive / slow if you don’t use nodraw because it’ll try to calculate lighting on a surface that won’t even be seen.

Roblox’s take on lighting is 100% dynamic, updating in a 4x4x4 voxel grid, so it doesn’t need to calculate for the entire map in the same manner that things like Source do. I think the need to pre-calculate would be the case if that new lighting system (The one featured in “The future is bright”) was implemented, but that’d probably be handled upon the game being published.

Edit: This is not the case for FiB, it is 100% dynamic.

2 Likes