I’m looking to see if there is enough interest here to warrant putting it on the asset store.
Dynamic Terrain Renderer (DTR) was designed for terraforming and overall performant loading/updating of heights, splat maps, and colliders. Unity’s renderer itself performs ok, but the flows for updating the related data perform rather badly.
DTR colliders use DOTS. It’s not required but it’s much better with.
No limit on terrain size, only limited by Unity max texture size
Heightmaps use structured buffers and sub updates
Splat changes leverage Graphics.CopyTexture using small temp textures
Partitioned DOTS collider system for zero main thread hit updates
Baking/loading heights/colliders extremely fast, raw memory using native containers.
Microsplat integration.
Simpler optional shader based on Better Shaders.
Terrain mod system abstracts out mods. Space efficient for persistence.
Design time can use Unity terrain or mesh as source data
The renderer itself is a fast bursted job based Quad tree that renders scaled patch meshes using DrawMeshInstanced. Performance here is pretty much the same as Unity’s. The core approach is industry standard.
Runtime updates were specifically designed to be constant regardless of terrain size, and have a low enough impact to support multiple players terraforming concurrently.
Sounds very interesting and I’m a bit surprised this isn’t seeing more attention.
One major thing I’m wondering about though is the support of multi-tile terrains. The most common method for handling terrains in unity is to split it up into tiles, which makes for fairly straightfoward loading/streaming as well as splitting up the authoring into multiple subassets, which is useful for version control and keeping things snappy in the editor.
I assume tiles could work just ‘as is’ with your system? If not, that might be a big one. Other than that, as you’re able to design the terrain from the ground up, it might be nice to add in support for multi-tile terrain, such as built-in LOD functionality (where terrain that is further away may be replaced by a mesh or by larger, less granular height and splatmaps).
You mention that the collider uses DOTS - what is the non-DOTS collider based on? Is it also a heightfield-based collider or a (non-convex?) mesh collider?
EDIT: I’m also interested in how the runtime modification (and storing) works - is it based on a splat/painting like approach or does it only store sub-parts of the height&splat maps that are modified?
Also, do you have some performance comparisons of stock unity terrain vs DTR?
EDIT 2: How would authoring and rendering of trees and terrain details work?
I had multiple terrains but disabled it. It’s a single material setup where terrain details and heights are in two structured buffers in the shader. That is still there so enabling multiple again is pretty simple.
It’s not designed for open world. It’s more designed for the survival/building genre. Terrain rendering is an area where context matters. Leveraging context can provide huge wins at the cost of working less well for other scenarios. If you just have a single logical terrain tied to a scene, tiling is a bad approach. It’s more complex and performs worse. Design time also should accommodate runtime not the other way around.
The runtime mod api you just create a List and pass it to an Apply() method. It sorts out the world bounds and then does a region copy of the splat map to a small texture, applies changes there, then a region copy back to the main splat. Same basic logic for the heights uses ComputeBuffer.Begin/EndWrite on the region that was changed.
Thanks for the thorough reply. I agree that terrain rendering can really benefit from being context sensitive. Tiling terrain is not necessarily uncommon in survival games, which often also feature an open world. Certainly it generally comes with overhead compared to just a single terrain but I’m surprised you call it a bad approach - you mentioned a pretty good reason for splitting things up, which is the size of single textures. And benefits during design/authoring time can absolutely be worth performance overhead at runtime, optimizing the production process is a huge task after all. Either way, not here to argue about design questions.
Yes, I asked about the non-DOTS alternative DTR uses
Ah, interesting, so it’s stored on a per-pixel/texel level.
There are no good non DOTS alternatives, because Unity doesn’t expose the Physx heightmap api directly. You could use meshes but those will be memory heavy.
Compromising runtime for design time adds up. A lot. It’s a lot of what is wrong with Unity in a lot of areas. So much of Unity’s performance issues are around the edges in these flows, while the core is actually pretty good. Terrains, navmesh, and animation are all like that.
Could you show what’s done in a video or demo of some kind? I’m always interested in a good kit if it works better than the previous assets I’ve come across.
