New terrain system

Hi everyone,
Wanted to share with you my work-in-progress terrain system for Unity. I know there are several similar out there, each with their individual advantages but also limitations (in performance, features, quality, dependencies and so on) that only make them suitable to certain scenarios. In the recent years various aspects of terrain rendering have seen improvements, both academical as well as empirical, however currently there's no single system that puts all of them together.

My goal is to create a general purpose terrain system, which can serve as a good alternative to Unity's built-in terrain. It would incorporate as many state-of-the-art solutions as possible, but remain practical above all.

It's worth the effort because typically a game's terrain visually occupies most of the screen (and therefore strongly impacts the player's impression of the game), costs a lot of memory / GPU (between all the textures and meshes, including vegetation) and takes a lot of time to design and edit (for all maps/levels). Therefore it's expected that any terrain system that can give an improvement in any of the above areas, without detracting from others, would give a significant payoff.

Here's what I've done so far:

* Geometry: this is a voxel terrain, but with a new contouring technique that allows precise control over the position of each vertex in the generated mesh. As such it allows mixing smooth and sharp surfaces as well as a wide range of brushes. Disk usage is on par with plain mesh representations as only surface voxels are persisted in a compact format.

* Brushes: basic "cube" + "sphere", "grow", "smooth" and direct vertex control. More interesting brushes are possible. Brushes can be used both inside Unity's editor as well as at runtime.

* Details/objects: supports painting of grass, details and trees similar to Unity's terrain. Objects with a mesh can optionally be merged automatically into patches, to minimize draw calls. Supports more prefab types than Unity's terrain, for example particle effects.

* Texturing: allows up to 64 textures per terrain (and up to 2 per voxel), each with diffuse, height, normal, emissive and specular maps. These are automatically atlased and rendered with a single draw call per chunk.

* Heightmap blending between textures. Having two textures per voxel allows creating decals, for example pavement stones sticking out of dirt.

* Persistence/streaming/infinite terrain: Maximum theoretical terrain size is 2^69 voxels on each dimension. As such a large terrain can't fit in a Unity scene it is stored in a separate file and gets streamed in/out of memory as the camera moves.

* Support for combining generated and hand-edited terrain. Only hand-edited portions of the terrain are persisted, which allows creating maps with hand edited detail in areas of interest, and generated detail for large filler areas. (However no terrain generators are provided yet).

The code is C# only, with no native DLL dependencies, and it requires Shader Model 3.0 but not DX11. In terms of performance I'm targeting equal or better performance than Unity's terrain, as far as direct comparisons are possible.

The following work is still in progress:

* Far LOD: support for multiple levels of detail is not finalized, which means far view distance is not working yet.
* Near LOD: sparse representation and ability to edit at different LODs would allow high-resolution details for close-ups.
* Ambient occlusion, updated at runtime.
* More brushes: simple ones such as raise/flatten/stairs/ramp/copy+paste terrain, or more difficult ones like CSG (boolean operations on mesh)
* Import from Unity terrain
* Terrain generation mechanism. There are nice terrain generation tools out there, so if possible I'd prefer to integrate with an existing asset that allows generation at runtime rather than build a new one.

I'd appreciate any feedback on which points you consider more important, or if you have other ideas not listed here. I'm also interested in the scenarios for which you need your terrain, and trade-offs you're forced to make. For your specific game, what are the features that an ideal terrain would support?

 

Absolutely beautiful work. Keep this up. I don't have any general feedback to throw at you as I'm in a rush right now but had to comment after quickly watching the video. My game would benefit massively from this.

"It's worth the effort because typically a game's terrain visually occupies most of the screen" - This right here, spot on.

To do what I'm doing with my landscapes I have had to use many design work-arounds and just painful things while there you are painting away like no tomorrow in the video.

Following this.

 

Feature list and performance look great so far, good job!

I'm using a version of TerraVol in my project that I've modified heavily, so I know the technical side of a basic voxel terrain (generation code and shaders), so I was curious when I read: "allows up to 64 textures per terrain (and up to 2 per voxel)"

The 64 textures I can understand with atlassing, but why only 2 per voxel? (those seem to imply two contradictory situations: the first of large chunks being used with a flexible/many-textures shader, the second of tiny chunks that use an oddly-limited shader--for now I'll assume the second is approximately the case)

The technical translation is that means only 2 textures per material, right? And therefore only 2 textures for any given pixel? (the alternative is that multiple materials/material-passes are used, but then it might not match the 'one draw call' description)

If so, why? Can your shader not fit any more textures/texture-samplers, or do you just have no way to retrieve coverage data for further textures? (if the first, what are you using the other of the 16 textures for, and if the second, aren't there other ways to pass coverage data, such as the vertex-color, uv2/3/4, or tangent channels?)

Thanks for satisfying my curiosity... : ) (and perhaps providing side-knowledge for use later in terrain-shader development)

 

This looks great. How are you handling the UV seams?

 

This is quite impressive !

 

Excellent stuff!
May I ask how you're doing the square edges and vertex movement, please? (algorithm reference or something if possible, please?)

Background: I too am using a highly customized TerraVol. Slightly odd use-case, my voxels inhabit a world with static geometry as well. Specifically, the voxles are the Snow in a snow-centric game! A Vine speaks a thosand words so here are my snowmen rolling to regain health:

https://vine.co/v/i1O1OZFblQa

They also build by throwing it (dig with explosions, etc).

I /miiiiiight/ consider switching if enough stuff were present, source was supplied, cost viable, project looked future proof, etc. (hey, I can dream ;-) )

So, since you asked, here are some thoughts about voxel engine stuff:

Speeeeeeeeeeed.
Says it all really. You don't show operations at runtime but mention it does it.
I'd expect multi-threading, a complete absence of frame-rate interruption -- even for huge operations which might take a few frames to complete. I added particle system emmisions from affected voxels to help hide long running operations. (e.g. I have carrocket launchers that can blow huge holes in the snow!)

Size?
What size are the voxels? How small can each be? What sort of scale meshes can one make?
Sadly, in order to get TerraVol to make sufficiently small meshes, I had to scale it down. Consequently it produces *A LOT* of draw calls as a result!

Operation results callbacks.
One I really need is getting results from operations. I have to know how much snow was destroyed by a 'dig' operation (which I use to scale health added to my Snowmen).

Blocks 'being' materials.
One thing I no longer use but was completely missing from TerraVol was the concept of blocks 'being' certain materials before they were dug. (E.g. I made a Ludum Dare game about endoscopic surgery where you had to operate on a tumour burried in the gut wall.) (Previously, a dig operation would change what the blocks were!)

Capsule operations.
I would add capsule operations -- one of my best changes since so many things can be roughly modelled by a capsule and the maths is pretty easy. In fact, mathematically defined operations might make a cute thing (through this is a far future feature, I suspect).

Voxels in their own movable frames of reference.
PicaVoxel shows this brilliantly -- vehicles or whatever made of voxels that can roll along and have bits blown off them! Wow! (just a shame no curves)

...

I could probably go on but I don't know if this is the sort of thing you want to hear so I'll pause there and get back to work! ;-) Oh, you might go trawl other voxel systems' forum threads for other stuff people consider important if you haven't already!

Good luck. I'll be following keenly.
Rupert.

 

Woah amazing im super impressed release this and you'll kill it on the asset store!

 

Thank you everyone for the comments. Please keep the questions coming, and I'll try to answer the best I can. Btw once this work makes its way into a package I'm planning to include the source code as well, so you can see all these details.

@Venryx:
"why only 2 per voxel": I should mention I'm using a different representation for my splatmap than Unity's terrain, perhaps this is what's causing the confusion. For each texture Unity uses a splatmap channel to represent that texture's intensity in each point. This becomes a problem when using 64 textures and the terrain is 3D, as it would require too many splatmaps that are vastly empty. Instead I'm building a single splatmap where for each voxel I'm storing 2 texture IDs and their relative intensities.

"are there only 2 textures for any given pixel": No. Even with a single texture per voxel the shader will perform blending at voxel edges to avoid sharp transitions. Therefore the color at each pixel is determined not just by the texture of the current voxel, but also by its closest neighbours. To give an example if you have 3 voxels in a row, each with a solid color A, B and C respectively, then on the screen you would see the following color transitions: A, A+B, B, B+C, C.
The second texture per voxel adds to this mix, allowing another texture to be layered on top like a decal, so you can have a blend not just between voxels but also across them, for example A, A+B, A+B, ..., A+B, A.

@Adam:
"how are you handling the UV seams": I'm assuming you mean the notorious issue with atlas and wrapped textures. I'm clamping the texture coordinates to be within half a texel from borders, however the trick is to get the size of the texel at the current mip level. I'm using tex2lod so I can also clamp the lod to avoid using higher mip levels that start blending textures between each other. It's still not perfect, however I'm expecting that all this calculation will go away around March, when Unity should finally give us texture arrays.

@Arkade: Your rolling snowman is awesome
"how you're doing the square edges and vertex movement": The algorithm is a variant of a dual contouring method called surface nets (original paper: http://www.spl.harvard.edu/archive/spl-pre2007/pages/nobrain/CD-6-99/papers/gibson/TR99-24.pdf; Mikola Lysenko has a great comparison page here: http://0fps.net/2012/07/12/smooth-voxel-terrain-part-2/ ). As you may already know a "dual" contouring method generates vertices for voxels and faces for edges, as opposed to a regular method (eg maching cubes) that creates vertices for edges and faces for voxels. Current dual contouring algorithms could be called "indirect" or "implicit" as they are trying to calculate the position of this vertex, for example as an average between edge crossings in Lysenko's "naive" implementation, or by using both crossings and normals (aka Hermite data) to approximate where surfaces might intersect, as per http://www.frankpetterson.com/publications/dualcontour/dualcontour.pdf. I'm improving on the above methods by taking a "direct" or "explicit" approach, allowing direct control over the actual position of this vertex inside its parent voxel. This way it can be either calculated through any of the above mechanisms, or just edited directly using a brush. This should make more sense once I finish documenting the base voxel structures and how they work.

"speed": I fully agree speed is paramount. I'm already careful to avoid design that requires operations each frame, and any lengthy operation (like mesh building) is done on a separate thread.
"size": draw calls are proportional to number of chunks, and each chunk has 32x32x32 voxels; each populated voxel has one vertex inside. I'd be interested to understand better what you mean by "smaller", do you mean higher resolution?
"operation callbacks": This is great feedback, I'll take this into account.
"blocks being materials": I intend to allow developers to extend the base Voxel structure to add any custom data. I'm hoping this would cover for the various requirements for biomes/materials/other game-specific properties.
"capsule operations": Thanks, I'll consider this.
"voxels in their movable frames of reference": Yes, I was thinking about something like this for further down the line, after the terrain itself was done: if you are able to create say a single terrain chunk as a standalone object you can sculpt it using the same brushes and create a regular object prefab out of it.

 

Thanks for the references and the great explanations! Ironically: since posting, I've been reading ... 0fps!!!
It's fascinating stuff. It will require more reading yet ... when it's not late at night!

One question that strikes me then becomes what your timelines are?

Due to my curious personal situation (I'm full-time Dad of a 3 & a 1 year-old at the moment, taking a haitus from gamedev for a year and a half), my indie work is a few hours a week weekends & evenings). As such, my release date is winter 2017. Obviously I don't want to knock this back further with huge tech changes but min specs is a bit of a concern for me. The voxel system's draw-call and CPU load means you need a gaming machine to play and even some consoles might have problems if I build levels too large. So yeah, I'm very interested.

Obviously, if/when you're ready for testers (especially one who's happy to supply patches), I'd love to help / evaluate.

And a couple of responses...

Yes, higher resolution. E.g. TerraVol was designed for terrain. It creates lovely big meshes. I scale it down by 0.2 to ensure a single smallest snowball can be 'solidified' when it hits the ground. Consequently, I see 3-4k draw-calls in my smallish scenes

Great choice. I love systems that do this (and provide a selection of good common defaults) ... and possibly provide a way for users to share their useful bits (see my patches on opsive's Behavior Designer forum ;-) ).

Thx again, Rupert.

 

Hi, looks good!

Some questions:

- triplanar shaders are a bit slow for our project. Does yours avoid the need for triplanar shaders?
- the shader used - will it have some standard shader features? the interesting ones are normals and rough/smoothness plus support for IBL of course / general lighting / deferred ?

It's just while the terrain looked interesting, the shader looked pretty basic, and if tied too tightly to it, probably isn't worth the trade off as rendering quality is a big deal.

Possibility for players to edit at runtime? No biggie, but still interesting.

Thanks

 

@Arkade: To get an idea of timelines I'm first trying to get an understanding of people's practical needs, to see what is a must-have for a first version and what features can wait. Thanks for offering to test early versions, I'll be sure to contact you as soon as I have a version that can stand on its own.

@hippocoder: The shader does inherit from the Standard shader, I'm still oscillating between the Metallic and Specular models. The video doesn't show it, but when adding a new texture you can choose a diffuse, height, normal, specular and emission maps. What I call "specular" here is actually a single channel used to define both the metallic and smoothness components in the shader, which is not quite right, so I'm considering changing this model to define Diffuse/Height/Normal/Metallic/Smoothness for regular textures, or Diffuse/Height/Normal/Emission for self-illuminated textures. The textures in the video do have normals and specular components, but maybe they need some tweaking to stand out better.
Regarding triplanar: it appears to be quite important to be able to tweak the shader, so I suppose I'll package the important shader bits into a standalone lib. Then you could provide your own shader and just call the lib functions to manipulate the default behaviour. But I'm not sure what alternative to triplanar do you have given that UV mapping on an arbitrary mesh is a hard problem. Are you able to control your own UV coordinates in your game?
Yes, editing at runtime is one of the goals of this terrain system. Brushes don't have editor specific code so they can be packaged with the game and used at runtime. (You'll need to provide your own UI though).

 

This look good. I have tried few other voxel terrain systems, but the only draw back they had was massive drawcalls and huge amount of polygons for just a small piece of terrain/block.

If the LOD system you are using can significantly reduce the drawcalls and polygons without having too much impact on the quality of the terrain, then you will have my money .

P.S I would assume it's not ready for mobile.

 

Posting a small refresher to show a bit more details about materials. I've also added modifiers to control the strength of normals, specular and emission, as they are a bit modest in the textures I'm using.

I have some ideas about how to avoid triplanar shading (by painting UVs at the same time as painting textures), but I would really like to focus first on finishing the LOD system.

Although I do want to add another sample to show runtime performance, maybe something along the lines of a "smoother rolling snowman"

 

Any new on this?

 

Yes, I'm hoping to post some updates this weekend.

 

The killer feature for me - and few others - would be spherical voxel planets. Space engineers did it, but they are using their full custom sharpdx based c# engine, up to date .net runtimes and garbage collector and Directx11. Which is cool and bad at the same time

 

That is exactly what the Unity Terrain tool should be! This is awesome! Especially for caves and similair things! WOW

 

Here's an update on the work on multiple LODs. The neat points here are:
* Smooth blend between LODs, with a band of configurable width.
* Option for a smooth mesh transition when bringing chunks in and out of view (as opposed to mesh popping)

@Razmot: "spherical voxel planets" - is the shape that you're after, or the scale? The engine supports spheres and other smooth curves; there's a sphere in the video below, have a look. In terms of scale and performance I suppose we'll need to wait for all the features to be finalized before all optimizations can be made.

 

What if I want to place very dense grass over large portions of my terrain?

 

Shape first :
- being able to actually do planets that wrap terrain ( go south until you arrive north)
- pseudorandom algorithms fit for a sphere
- objects / trees / vegetation planting adapted to a spehre

Then, a good enough scale, not realistic of course but not too arcade either ( not mario galaxy)

 

Another quick update. Although most work is now done on the internals, here are a few new features:
* Vertex-level ambient occlusion, updated dynamically.
* Flat/smooth lighting across edges based on configurable edge angle.
* Auto-resizing of terrain textures, very handy when dealing with a large number of textures coming from different sources.

I know I promised demos to show off terrain's performance, however I should really leave optimizations for last, after all features are done. My next work will be finishing off the object system, to make it work across LODs, which should be the last major feature before moving on to bugfixing and optimizations.

 

WoW looks greate need more Infos when is realse ?? more input more screenshots

 

Hey, your work seems like a nice replacement for those that hate the built in unity terrain I really like that you handle vegetation with automatic batching and streaming. Some questions:

1. My usual "problem" with voxel based solutions is the base voxel size that doesn't let you have sharp-smaller details on the terrain. In your description you mention something about a new contouring technique that from my understanding helps on that matter. I would like to see how your voxel terrain can represent a traditional terrain heightmap with detailed erosion (id be happy to send you one if you want to do some tests/comparison between your voxel terrain and unity's built in one).

2. Any chance for supporting a third party tool for terrain generation and vegetation scattering like gaia or map magic?

Cheers!

3. Do you get any in-game performance if you don't need the terrain to be editable or infinite?

 

@Twoonebe : Thanks, I'll post more videos after I finish making the object system work with LODs. This should be the last major feature for the initial release (more features to come later), however I'll want to make some performance improvements as well before putting it up for sale.

@moure:
1. I have a few approaches to deal with this problem:
* The contouring method allows vertices to have arbitrary locations. This allows sharp features, but not high frequency detail (still 32x32x32 vertices per chunk).
* (still work in progress) I want to allow editing at different LODs. For example you could create most of your terrain at LOD4 and scale it so that 1 voxel = 1 m, but still have high resolution areas designed at LOD0 where 1 voxel = 6 cm.
* if you do choose to scale the terrain so that the entire mesh is hi-res, memory/disk storage is designed to be very lightweight (only surface voxels are stored, at ~13 bytes / voxel).

2. Terrain generation is currently a callback per chunk (if the chunk does not have data persisted on disk the callback gives a chance to generate it). For the moment my callback only generates flat land. It should be possibly to integrate with other tools, let me know which ones are your favourite and I'll have a look at what's required. As I mentioned before I'd prefer to integrate with other tools rather than implementing another generator myself.

3. Yes. If terrain is not editable some in-memory constructs are not necessary and can be avoided. If terrain is not infinite then chunks can be pre-loaded, avoiding a potential lag when streaming from disk/network or when generating. I'll expose a ReadOnly flag for the terrain. Unity's light-mapping is also not possible unless the terrain is read-only and fully present in memory.

 

@pawfessor fluff (i lol-ed at that username )
I don't own MapMagic (i have messed a bit though with the free evaluation version), but its node based procedural generation and distribution workflow seems like the easiest integration you could try as a first step. It is basically like worldmachine built inside unity.
Besides integration with other packages, imho you should definitely support on release a simple heightmap input for generation and splatmaps for vegetation and material distribution for non-infinite terrains. Ideally you could use the same formats that unity terrain uses so that people can easily convert their terrain to your voxelized equivalent.

That seems great!

 

Thanks for the suggestion, yes importing a heightmap shouldn't be a problem. Please do send me your sample map, I could generate my own but it's better to look at a real-world example.

 

When starts your terrainsystem on the store i can not wait to test it

 

@pawfessor-fluff: It has been a while since your last update. Are you still pursuing this project?

 

@jrhtcg: Yes, I am.
Sorry for the long delay with no updates. I did get side-tracked pursuing a mesh-based (non-voxel) geometry blending method. This would allow arbitrary detail, full UV mapping and better runtime performance, but it's not ready for prime-time. I guess it will have to wait until version 2. I still intend to release the voxel-based terrain before the end of this year.

 

Will the terrain shader for this support heightmap based blending between textures? After seeing how realistically that blends terrain textures I could never go back to the cruddy default blending.

Old default blending of textures:


Really nice blending of textures where things blend into crevices and cracks:

 

Hi @JamesArndt: yes, it already does, have a look at the Terrain Materials video above. The quality/sharpness of the blend is driven by the heightmap. I suppose I can also expose a shader parameter for finer control.

 

@pawfessor-fluff This looks incredible! I've spent hours scouring Google for the simple ability to include specular maps into the terrain shader, and eventually resorted to purchasing a terrain shader from the asset store. I must say I'm pretty disappointed with it, and I feel very limited, considering what I paid. Yours, however, looks fantastic, and I wish it had been available at the time! Do you have any plan to release a demo that we can test, perhaps? Or at least a rough idea when we'll be able to purchase it?

 

Yes, I will try to put a demo online so you can see it before you buy it.

 

This looks promising, I thought on doing something similar in the far future. But I stumbled upon two issues:

1. Baked occlusion culling
2. Baked realtime GI

How did you managed to get the terrain into Unity's static culling mechanisms? The standard Unity terrain is separated into chunks, and each individual chunk can be treated as a 'occluder' or 'occludee'. How did you mimicked that behavior?

How did you managed to integrate it into Unity's baked realtime GI?

If you managed to solve that then there's a chance that you only need to add tesselation to bring this terrain at Frostbite quality

 

Hey is it possible to use for something like floating island ?

 

@Assembler-Maze : Both GI and occlusion culling are possible: this terrain is also split into chunks, which can be individually occluded, and objects on it are grouped into batches which can be occluded as well. However baking in Unity will be incompatible with streaming/infinite terrain (as it requires all data to be present in memory) as well as dynamic changes (as baking is too slow to be done at runtime). You would still be able to use the terrain in the same way you use Unity's: one static fixed size terrain per scene.
This being said fixed size terrain requires a bit more work so I might leave it for the next version.

@Elzean : Yes, floating islands are possible.

 

I did not understood that, maybe a little bit of explanation? What do you mean by 'fixed size'?

And how can you integrate the occlusion into Unity's pipeline, when there is only one objects? Or the chunks get separated during occlusion baking?

Thanks a lot!

 

I meant at the moment the terrain assumes its full data is stored elsewhere (either on a large file on disk, or on a remote server, or is being generated on the fly) and it's only downloading the portions you can see, up to a configured distance. I'll need to add a parameter to say "enable baking" which will force you to set limits to your terrain size and will ensure all terrain data is always present in memory.

Regarding occlusion: There's a single terrain object but it has separate chunks as children, and as far as I can tell Unity is able to see through the hierarchy. It seems to show/hide individual Renderers.

 

Ah, yes that was my question. Excellent, that's good. Looking forward for future progress!

 

very promising asset!
any info when it will be available in the asset store?

regarding UVs, indeed triplanner have some performance cost.
so i think the ideal solution to tackle this , is if the brushes do this immediatly after mesh editing.. for example using box.. will make a box projection on it right away.. and so on.. depending on the tools used.

 

@mangax: Thanks, the brushes do indeed trigger various updates for the regions that they affect. When using a shape as a brush (cube, sphere or even an arbitrary mesh) you can indeed migrate the mesh UVs, but this won't work with other brushes such as grow/shrink or even raise/lower. For these type of edits you need to recalculate UVs, which is an expensive operation. But if you have an idea let me know and I'll be happy to implement it.

 

The end of the year is near something news about the release

 

Does this system use compute shaders? That is, would this work in WebGL 2.0?

 

@Twoonebe : I'm still working hard to finish it. It has to be good though, you would be equally disappointed if I released it sooner and would be filled with bugs.

@StaffanEk : It's not using compute shaders (although they would have made things a lot easier). However WebGL has other limitations such as no threading, so for WebGL I'll have to add an option to run single-threaded.

 

@pawfessor-fluff

That is awesome. I'm exited.

 

Can you give a date for publication?

 

@Twoonebe : If you're under time pressure send me a private message and we'll try to work something out for your specific needs.

 

Amazing - I'm still a Unity newbie but I constantly swear at the limitations of the native terrain system.
The more I learn about how it works the more I understand exactly why those limitations are there but I love seeing someone tacle this problem from a different angle.
I have to follow this thread

 

As one who finds the Unity terrain to be horribly inefficient and limited, this looks very promising. Any idea of a ship date? Do you need testers?

 

Hi jwilliamsen, sure if you'd like to help with testing send me a private message and we can arrange something.