As a Roblox developer, it is currently hard or near impossible to make optimized maps with smooth terrain.
Smooth terrain has too many triangles and too many drawcalls associated with it to be optimized for lower-end hardware (without the end user needing to lower their graphics settings, and or without developers needing to limit themselves on what they create.)
The default terrain baseplate has over 108,000 triangles, and 247 drawcalls.
This makes smooth terrain incredibly resource-intensive just by itself on lower-end hardware.
Higher-detail smooth terrain should only be generated in areas where it is sculpted - i.e. dips, valleys, hills, etc.
Flat terrain should not have 100s of thousands of triangles.
Terrain is incredibly unoptimized, especially the voxel system. Voxels can single-handedly cause massive network lag spikes whenever a player joins. It becomes even worse with StreamingEnabled when people are constantly requesting voxels to be streamed in. This system should really be optimized more to better handle larger terrain. The network bloat terrain voxels cause is one of the sole reasons I still hesitate to use StreamingEnabled.
that triangle count made my jaw drop, i knew it was bad but come on??? iāve had more optimized models in games (only a fraction of the triangles) crash bad video card drivers from sending too much data
that explains why every game ive played using smooth terrain has either ran worse or made my fans run louder than games with normal part terrain.
Assuming this goes through, they should reintroduce pre-smooth terrain by allowing developers to lower manipulate and lower/raise the voxel grid respectively. That would allow more cartoony terrain and more specific and high fidelity terrain design easily. The Rock terrain material has a lower voxel grid contribution compared to Grass but has itās own unique look, so itās something to simply ponder on, I guess.
Thereās probably a technical reason why even flat terrain ends up with that many triangles - maybe the system just always prepares for dips and slopes, even if the surface stays flat. Looks always end up fighting with how well it runs - and terrain really shows that.
That said, itās easy to see why this becomes such a problem on bigger maps - itās just not worth the hassle. It might be fine for small spaces, but once things get larger, Blender just makes more sense, as already mentioned above.
In our game, we found that textures tended to cause more issues than triangle count. But still, too much geometry does catch up with you eventually - especially on low-end devices or when loading times matter.
The reason I assume itās high triangle is because it always expects to be updated. In other engines you typically have the terrain in the editor which is very dense and high in tris, but you can then later āapplyā this terrain as the final result and it would be recalculated to be visibly the same with the least triangles possible for performance. Here this isnāt the case because well, terrain can update and always change, so if this source information isnāt preserved what would you do? I might be misunderstanding it though, thatās just what I can think about?
Even with the dynamic nature of terrain, it should still be possible to use greedy algorithms to collapse the tri-count, or at the very least do static application like you mentioned other game engines do.
Worst case scenario would be the engine would have to āresubdivideā collapsed regions when they get altered (which I mean, come on, whoās actually using WriteVoxels in live games in 2025?)
Roblox seems to be working on this, since it appears that Terrain has Occlusion Culling now. Able to be occluded and occlude other things including itself, except for water & decoration grass.
I might be enrolled in some A/B test for this, since as far as I know Roblox has publicly said that Terrain currently is not part of this. But, assuming that itās implemented for everyone, this basically means that as long as your terrain has a decent amount of variance in the way itās shaped, it will occlude itself and massively reduce the performance footprint of the terrain. (And of course, buildings and whatnot.)
This is probably the best choice for improving performance of terrain, since well, things like Greedy Meshing are not as effective for improving the performance of smooth terrain in real world use cases as people tend to think. Additionally, with there already being LODs, there isnāt really much point to Greedy Mesh the terrain anyways.
Final note, 100K triangles really isnāt enough to be concerned over for the grass baseplate which is a huge piece of terrain, the triangle count also doesnāt really go up very much with geometric complexity (100K->180K with complex procedurally generated terrain of the same size), decoration grass will easily take up double that amount. To put it into perspective, According to Roblox, 90% of devices (including mobile) can render 1 million triangles at 60FPS, with my own experience with graphics hardware I reckon that sounds about right.
Enabling that triangle view mode increases both draw calls, and triangles (because it includes the visualization as well), it really shouldnāt but I believe it does.
Try checking draw calls and triangles again without having the grid view enabled
I disagree with the premise of triangles being the culprit.
I donāt think this is true. Even the simple greedy mesher algorithm Iāve taught here on the DevForum for cube geometry is pretty expensive to run, and thatās before you introduce the complexity of having to deal with non-planar surfaces. Instead of a greedy mesher, youāre likely looking at some kind of dynamic decimation system, that will have to preserve the edge geometry anyway to ensure that neighbouring chunks of smooth terrain mesh properly together. (either that or skirts)
All of that is to say that a flat plane of grass is a pretty bad way of evaluating smooth terrain, because if youāre using smooth terrain to create unadorned cuboids of matter, well, you may as well use a part for that, which is the most efficient way to create an unadorned cuboid of matter. Smooth terrain is designed to represent smooth perturbed surfaces, and its output reflects that.
For that use case, to my eyes, Roblox isnāt operating with a volume or size of triangle thatās particularly problematic here. If anything, itās on par with exactly what Iād expect for a cross-platform engine.
You can see in the above picture that smooth terrain uses an LoD system to roughly normalise the size of triangles over distance; the only difference between each LoD is the angle at which the triangles are seen:
These triangles are generally much, much larger than the 2x2 regions that GPUs compute for fragment shaders, so there should be relatively little expense with this arrangement of triangles (not to mention they seem to satisfy the āmax areaā rule of thumb relatively well). The more relevant cost with a scene like this IMO would be in memory overhead and the cost to update the scene, and Robloxās current system seems to do well enough on those fronts for my satisfaction. 108k triangles is really not a lot compared to the triangle counts thrown about for individual assets in not-so-modern titles!
All of this isnāt to say that I think smooth terrain is perfect - for sure it could be improved, it has one of the most expensive fragment shaders judging by the profiles - but people who point at the triangle count here are not pointing at the right thing. Iād perhaps focus on the cost of fragment shading, or the memory consumption, or the draw call count. But definitely not triangles.
I think in particular what Iād want to see if I were a rendering engineer, would be a case study where smooth terrain is taking up the majority of the profile for a real scene. At least then, the profile can be studied to see where the real bottleneck is, and extra profiles can be taken to see how it varies across devices. Perhaps then you might identify that some texture reads in the fragment shader are maxing out the memory bandwidth on a mobile device somewhere, and you could start looking into a targeted intervention to combat that.
I do agree triangles arenāt really the biggest issue here - itās mostly the drawcall count for seemingly 4 unique materials for the default plate.
Iām not sure 100% what makes the draw count so high.
This is a 10k x 10k region and the triangle count only increased by 300k? Iāve seen games on Roblox take up more triangles in a smaller area than this, so yeah. Triangle count definitely isnāt the issue here, but I feel it could be improved for flat areas. There are mods for Minecraft that handle greedy meshing cubes pretty effectively. I think Minecraft also has built-in greedy meshing? Iām sure Roblox could use some algorithm that would make the triangle count lesser.
However, drawcalls increased quite a bit. Admittedly thereās a lot of unique materials here, but if you were to build this out of parts, youād only have a max of 45 drawcalls or so - assuming you only build with BaseParts and none of the other part types.
I mean, youāre obviously more knowledgeable in this area, so Iāll take your word for it.
The thing is, if this is truly the best smooth terrain can offer, thatās terrible. The performance issues are so big that I donāt know how you or anyone else could be fine with it. If you just look the wrong way in a game, you can go from 120 FPS to 20.
As smooth terrainās performance is now, I have to categorically rule out ever seriously using it. I cannot accept this is normal when any other engine from 2006 can handle this competently.
If people care that much about the triangles inside their terrain, they can just export their terrain as .obj into blender and merge the triangles themselves. Or recreate their terrain in blender.
