Unity3D : Adventures in creating huge outdoor areas (terrains) — Part 5: It’s NOT the trees, it IS the bloody terrain!
When I’ve seen people complaining about the terrain system, there were two basic kind of posts:
- gamedev (and unity) professionals, or at least semi-professionals, who were pretty comprehensively listing reasons why the terrain system is bad to the point of embarassing. They used to mention mainly the number of drawcalls (surprisingly lot, for basically being a single mesh composed of several LODed submeshes) and setpasses (one per detail texture layer) it generates, making it surprisingly expensive for the “blobby excuse for a terrain that it is”.
- gamedev (and or) unity beginners recounting their experience from trying to use it for the first time, who tended to write things like “when I added few hundred trees and grass objects, my framerate tanked. how am I supposed to make the big lush forrest that I planned?”
The first kind sounded like people who know what they’re talking about. When reading the posts of the second kind, I usually thought “guy probably doesn’t know LODs exist and he’s using some 10k vertices detailed models with none, and some stupid grass models which actually model the blades of grass in 3d”. Which… yes, was a bit patronizing, but to my defence, responses they were getting were usually along the same lines (except formulated much more sensibly as suggestions that “you need to be more careful with stuff like this, when you’re a bit smarter than just plopping down everything and expecting it to work flawlessly immediately, and do some tweaking, it gets better”.
Needless to say, I was wrong. And those responses were also mostly wrong.
Yesterday, before I went to sleep, I couldn’t resist and I actually did try what I said I would.
And to my shock and horror, I found that the problem IS the bloody fuckin terrain! ESPECIALLY its tree (and by extension I assume also grass) system!
Which is… Incredible, and insane. It gives a completely new meaning to all the claims that Unity’s built-in terrain system is basically worse than if it didn’t have any such system at all… Because it really is.
Let me show you.
This is the bare terrain, all of it, all 25 tiles, each using 4095x4095 heightmap, and CTS shader (no, I’m not removing it again just to prove the point, because I would have to muck around with painting several different textures on each anyway, to make unity do its setpass dance). Notice that it’s running at not great, but usable 84–108 FPS, 9.3ms per frame renderthread, 89 setpass calls. About 30 of those SetPass calls are reflections, shadows and skybox. Another 20 are ImageEffects (that being Unity’s term for fullscreen shader effects — bloom, distance blur, stuff like that). Meaning about 40 are the actual terrain drawing.
Now, here’s the terrain with 3000 trees as actual gameobjects, being auto-batched nicely:
And here’s the terrain with exactly the same 3000 trees, in exactly the same positions, except this time, they are part of the terrain tree system:
And… to be honest with you, I don’t really know what to think about this, in this small example. Firstly, I’m going to ignore the FPS on the left, provided by CTS. Secondly, You’ll notice that this second case, with trees in the terrain, is 4.3 FPS slower, due to the CPU time increasing, even though the rendering time decreased slightly, and even though the batches and setpass count is lower. There’s also 12 more shadowcasters, which… I don’t understand, since these two really literally are the same view.
I should find a better way to test this, with larger amount of trees, but it’s not really possible for me to run this terrain with more than 3000 (gameobject) ones. It’s taking about a minute to start up as it is.
I feel like I’m slowly losing my mind, but let’s press on.
Next step, even though I’m doing it on the same day, will be in a separate post so that the titles actually relate to what the content is about.
