A lot of years have passed and Unity has improved a lot, from render pipelines to lighting, even the ECS and DOTS systems have been added, the Unity team is working really good.
Have you ever tried to build a game using Unity’s terrain though?
It is the worse experience ever, the tools are pretty nice, the landscapes you can create awesome, but when we talk about performance, expecially on mobile devices it’s really sad, even if you:
-Enable Draw Instanced
-Increase Pixel Error
-Reduce Base Map Distance (pointless)
-Disable Terrain Details
-Disable Realtime Shadows
All of your attempts are getting crush by the way the terrain is rendering, it should be edited because it’s really bad and it cuts a lot of the features that the egine could provide for mobile developers.
I understand you perfectly. But I want to add a “small and insignificant” part. Unfortunately the work with terrane remained at the level of Unity version 5. Yes, they added a tool to work with splat map, and layers. The realization of these moments looks like a crutch. For example, if we take URP, then in layers we can insert 4(?) materials that can be at least somehow customized. But if we take HDRP, there is nothing but pain and frustration. Layers, yes. Quantity - as many as you want. Materials into layers - no. Take and insert/change them by hand. At the same time catching errors in the fallen off materials (how they fall off and why the console writes that the material is deleted, God only knows). Everyone advises to use an asset, but I’m tired of fixing errors when changing the version of Unity and think - and whether there will be a conflict, and whether the asset uses another asset on which it is based. In general, the problem with uniti terrane is that there is no terrane and its tools. There is an illusion. In my work, I quite often need a high quality landscape and unfortunately unity is very far behind the unreal engine.
Hello WST, are you talking about Micro Splat right?
I will try to profile the performance with and without it, in order to see if something changes…
Yeah it sucks. Luckily there are terrain to mesh tools on github which are good
Hi Patrickmol
No, I don’t mean microsplat. I try not to use other assets. I prefer to work with the tools provided by the engine itself. It eliminates most errors. At least you can study the documentation (yes, there is also documentation for assets, but it does not get rid of problems with code editing when switching to another version of the engine and does not guarantee stable work even in the current version of the engine). I sincerely don’t understand why unity won’t make universal shaders for different rendering engines. I watched a video about microsplat… The solution is interesting, but rather cumbersome. Also, I understand that in some cases you have to write your own tools because of the specific approach to implementation. But the main tool of work, in my understanding, should be at least universal and not depend on other factors and certainly not cause a headache with the choice. I’ll say it again. In the built-in terrane tool there are 2 types of material that depend on the render engine and works differently. Ideally though, neither I nor you should have to think about the terrane shader when selecting a project on URP or HDRP or any other options
UPD
Just downloaded the HDRP demo scene. To say it’s horrible is an understatement. Of all the pluses you can name, it’s the sun. It looks more or less attractive. The rest of it looks like plastic. The water’s like plastic jelly. Textures of the earth as painted plastic and fake tessellation. And the vegetation… What can I say… It’s an epic fail.
Agreed. The performance of building a height map from input data needs to be optimized. Integration with native arrays and the jobs system is needed, as well as a faster method for syncing data back for physics.
This doesnt help much, still need to go through the Terrain for this to be viable. Still limited to 4k res etc
You can export terrain in chunks, so the resolution can actually be good.
It depends on your exact setup of course. I think Unity does not recommend using terrain if the size is under 100 x 100 or 1k x 1k units (not sure which one). Unity terrain is for many projects just too slow to use sadly
Unity’s built in terrain system is not up to the task for building a real game. It is only adequate for building small, simple demos.
If a developer wants to a build a modern game using Unity and HDRP, then the developer needs to build their own systems or use 3rd party assets. This is true for both rendering the materials on the terrain and rendering vegetation on the terrain.
Game developers can make awesome looking games in Unity, but only in spite of the native Unity tools, not because of them.
In 2023, why doesn’t Unity have something like Microsplat built into the terrain system? And why not have something like Nature Renderer build into the terrain system? Why does Unity require every game developer to solve these things themselves instead of building solid solutions into the engine itself?
Compare the terrain situation with Unity right now with UE5. The contrast has never been more stark, and Unity appears to have completely given up on this.
Update:
-I tried to use MicroSplat as rendering shader instead of the default Unity terrain’s one
-I carefully searched up for the best performance settings of the shader
Did the framerate improve?
No, it is still running really slow on my mid-end phone.
I will try to bake the terrain into a mesh and see if that does improve the performance.
Happy new year everyone!
Preach on, brother. I feel this pain.
I had someone say to me, “I thought your game was built in Unreal Engine”. I took it as a huge compliment.
This is so sad: Using Unity Terrain with DOTS workflow
Yea, they said that the terrains system was going to get improved in 2019, now it’s 2024 and it’s still a really bad terrain solution.
This might be a good solution for now
Orbis - DOTS Terrains | Terrain | Unity Asset Store
Lol i just asked about a bug that has months xD it is hilarious because today i wanted to give unity one chance and:
https://unity3d.atlassian.net/servicedesk/customer/portal/2/IN-54298
https://discussions.unity.com/t/928228
2024 update:
I have managed to increase significantly the performance using MicroSplat, in order to render the shader of the Terrain faster. That wasn’t enough though, and the performance wasn’t even close being good. I did try to add MicroSplat Terrain Mesh, and the magic is done, the render time is 3.6ms with Unity’s Terrain, whereas is 1.9ms with MicroSplat Mesh Object.
It is just incredible how bad the optimization of Unity’s Terrain is, I was able to cut the render time to half simply by stopping to use it. I suggest everyone to get a good Terrain to Mesh conversion tool if you want to boost the performance of your game, expecially if it’s targeting mobile devices.
I agree. Even on the highest end, latest generation graphics type projects, it’s still well worth it to use mesh terrains. If you don’t, you are missing out on being able to make your levels look way more awesome with more post processing, more realtime lights, more skinned meshes.
The difference is pretty extreme imo. Just the other day, I had an open world scene open just the other day for prototyping. With just the terrain and a single triplaner shader, the terrains were clocking in thousands of batches and set-pass calls. As meshes terrain the set-pass calls with the same shader was around 20. Yes 20 set-pass calls that is not a typo. The more terrains you have, the bigger difference it makes. 2000+ batches vs 20-ish batches. I’m giving somehwat vague numbers here obviously, but for anyone wondering who wants to know how big of a difference that is, it’s roughly the same overhead as having 50-100 skinned mesh animated NPC’s walking around on screen with zero optimization done to those NPC meshes.
I’ve seen and done way too many tests like this that I would not consider using anything other than mesh terrain for any platform. That’s just me though.
I find the problems with terrain ( ground only ) rendering very interesting.
AFAIK Unity is using some form of chunked LOD ( maybe clipmaps but I don’t think so ) for the terrain, where it is split into chunks and each chunk is rendered using the optimal LOD mesh. This system has been the accepted and standard method for two decades and was vastly superior to methods that came before as it was one of the first to utilize the distinct advantage of GPU’s throughput to render chunks quickly.
So what went wrong?
Granted it took Unity way to long to support instancing which due to the nature of chunkedLOD substantially reduces the drawcalls and increases rendering efficiency. However it would seem that once you add shadows, especially cascading shadow maps your drawcalls are still going to grow massively, instanced or not. Add to that fancy terrain shaders, splatmaps etc and I can see both drawcalls and set-pass getting out of hand quickly!
I feel its important to state this because at its heart the chunkedLOD system depends on splitting a terrain into many chunks and each chunk could be a drawcall unless instanced and even if instanced, other rendering aspects such as shadows, global illumination, spltmaps could cause additional setpasses/drawcalls.
This would seem to suggest that perhaps chunkedLOD, at least with the default settings Unity has, is no longer as efficient as it once was. Certainly once you start dealing with larger terrain areas having small chunks ( maybe 16x16 vertices) is going to be pretty detrimental, though its unclear if simply making the smallest chunk larger ( more vertices) would help. Plus it would appear a considerable amount of the algorithm is still being processed on the cpu ( culling, LOD calculation etc ) giving a constant overhead per a frame.
There have been some newer terrain rendering systems in recent years (e.g. concurrent binary tree), though I’m not convinced they have proved themselves to be viable replacements. There is also the approach to put terrain entirely on the GPU, maybe using clipmaps for LOD, or just brute force as GPU’s can efficiently render a very large number of triangles in a few drawcalls instead of trying to be fancy and have many chunks. One issue with the newer algorithms is they are not really scalable to lesser devices such as mobile, either due to sheer power or missing api features.
Of course all of this is purely dealing with the act or rendering the ground terrain, once you add in foliage, trees, rocks etc then costs just keep climbing, but that is unavoidable.
So i’m left wondering what is the most efficient method of rendering large scale terrains ( or even modest terrains ). What new systems/algorithms can be used? Are there any new algorithms?
In many cases, at least for Unity type projects I feel like perhaps rolling your own tile system using custom hand made LODS (using decimation on the triangles, instead of reduced grid of chunks) might be the better solution as its more tweakable and at least for desktop you have the power to render it.
Anyone got any thoughts on this or know of a drop in replacement algorithm for ChunkedLOD?
Yeah, just use combined meshes and apply fundamental hard surface optimization concepts, but just make it more user friendly and not custom script reliant (terrain to mesh asset nature manufacture etc). It’s how the people with the fastest running environments are doing it tried and true.
Maybe it’s just me, but I feel like alot of other approaches are over-engineered and none of them come close with sticking to basics I mentioned, particularly combined with layer culling instead of LOD’s.
I’m also experimenting with imposters for large terrain chunks for more vertices bound projects.
Vertices used to be a much bigger deal than they are now. The old/existing terrains and all this LOD focused stuff were designed for projects that are more vertices bound. That and I think they really focused on making the terrain system ridiculously easy to use. I only use LOD’s for huge objects the are near vertices limit(s).
Modern hardware can handle tens of millions of vertices easily. We need to start looking at this more simply because it actually is really simple to optimize terrains, it just takes some manual legwork at the moment. Improve the workflow of that manual legwork and call it a day. Don’t over engineer it I say.