Terrain Creation Workflow Proposal

Contributing to Blender
1

Terrain creation is fantastic, and a lot of artists tries to recreate them using 3D softwares.

In Blender, terrain creation is used to be fastidious, with large amount of polygons, and no real erosion system (ANT works but it is super slow and not adapted for realistic mountains).

1 - How it currently works

The main issue here is : Performance. Yes, one more time performances are an issue.

  • With high resolution, the landscape meshes are heavy to work on, and are a pain to edit
  • No real erosion simulation system available
  • No data maps available too (slope, cavity, etc…) or with tricky methods

2 - How I think it could works

Editing

Forget the current Blender mesh implementation. The current mesh system is very complex, and has a lot of functionalities, but most are useless for terrain and particularly heightmaps. Major problem of these functionalities : performances. Mesh is evaluated by the CPU for every change, and it is too slow for terrain editing.
I propose to directly use the opengl API to draw the heightmap onscreen. This way, there is only the needed functionalities available.

So, the terrain is a heightmap, that we can sculpt with no performances issues, and no resolution limit. Then, using a special water erosion brush, we can put water a bit everywhere to erode what is under. This way, the artist is free to do everything he wants.

Erosion

Using modern techniques such as GPU parallelisation, erosion can be done in real time.
I saw a great implementation from Lan Lou of a real time erosion using opengl. Github
page
My early prototype is highly inspired by this project.

Rendering

The terrain object can be converted to Blender mesh to be rendered, or into an heightmap to then displace a plane at a custom subdivision.

Technical details

The newly created object type is a HeightMap and owns multiple GPUTexture pointers for height, sediment, and other data. When computing erosion, we give these textures to some compute shaders that derive the maps, and create natural landscapes.
The textures can then be used to directly draw the terrain on the screen with minimal latency.

Demo

3 - What about an addon ?

This kind of specific feature is usually made as an addon, but in this case, it concerns simulation. Simulations are heavy to handle with python, and it would not allow the new object type with GPUTexture pointers.
Someone correct me if I’m wrong.

4 - Impact on Blender itself

The addition of a new object type is always something to consider with a lot of precautions :

  • Is it really useful ?
    → This Terrain object is used only in specific situations, similar to light probes, gpencil objects
  • Can it be merged with another object ?
    → It definitely can’t, as it is not a mesh, but a heightmap
  • Do it follows the Blender guidelines ?
    → I’m not part the Blender community from ages, so I can’t say.

5 - What am I planning to do ?

Object structure

  • Create and integrate the new object type
  • make it convertible to/from mesh objects
  • manage storage in the blend file

Erosion system

  • Find a way to erode dynamically
  • Hydraulic erosion
  • Thermal erosion
  • Try different methods (already grid erosion tested, particle erosion todo)

Future

Maybe, an integration with the Geometry nodes project would be amazing, but we have to wait for simulation implementation (fluid, rigid bodies…).

6 - Actual issues

The main question here is to define when the erosion step happens. For every other blender simulations, it is refreshed and cached on every blender frame. But for terrains, it is different; only the final frame is important, we do not care of the whole animation of erosion (for now, maybe in the future).

→ One option I thought is to compute erosion for each 3d region redraw. This way, it happens in real time, and doesn’t wait for the next frame. For erosion, the frame duration is not important, as the time step is constant. So the more step is computed, the better it is.
However, this option is not optimal at all :

  • The drawing system give an evaluated version of the heightmap, so we have to skip the dependency graph to modify the object at drawing
  • it is not in relation with other simulation systems of blender

If some have ideas, give them below :wink: ; Thanks for reading it

58 Likes
2

Currently, the main issue with Terrain creation in Blender is lack of any means of proper erosion simulation. It’s mainly erosion what gives a terrain built out of combination of random procedural noise textures their realistic look.

Blender already has somewhat robust set of built in procedural textures, and they are now much easier than ever to combine and use for displacement of meshes thanks to Geometry Nodes.

So I think that rather than introducing a new object type, it would make much more sense to have some sort of “Erosion” node as Geometry Nodes node, possibly accompanied with some other terrain/landscape specific nodes.

This would, however, require Geometry Nodes to gain some asynchronous/lazy evaluation system first, because erosion is often time consuming and no one wants to spend prolonged moments looking at a frozen UI :slight_smile:

3 Likes
3

Yep,

I agree that now the procedural system is robust and performant.
One issue is the refreshing of the whole mesh when doing erosion. With Blender meshes, it too slow to modify large meshes. My pc (32g RAM) literally crashed when going edit mode with a 4000 by 4000 grid. And in fact, it is a problem when sculpting terrains. Nodes are cool, but sometimes you want that mountain to be a bit higher, or a little river there, and sculpt mode is the only solution. With the light system I propose, it would be possible to edit a 8K by 8k mesh as you edit a 500 by 500 grid.

The real force of a dedicated terrain object is, in my opinion, to handle more easily heavy terrains.

4 Likes
4

Wow, this sounds incredible! Having the ability to do something like this natively would certainly be very useful, and it’s something that I’ve wanted (if not expected) for a long time!

I think @LudvikKoutny is correct in that it should be implemented natively into Geometry Nodes.
There could be nodes to convert a field/texture to a HeightField, where operations such as erosion could be performed quickly, and then a node to convert it back into a mesh so that it could be displayed/used for other operations.

This would of course need geo nodes to progress to the point where it can be used for simulations, but once it’s there, it wouldn’t really make any sense to have this as a separate system, especially as other simulations are probably going to be removed/deprecated once they have been added to geo nodes.

Otherwise, I think it’s an amazing idea, and even just seeing your prototype in the viewport is very exciting!

4 Likes
5

You summarized really well what I tried to explain.
I’m totally with you. I did this attempt of a new object type since it doesn’t makes sense to try on my own to do a simulator within geo nodes.
I’m definitely waiting for news in the area of solvers in geonode.

2 Likes
6

I saw that this existed for terrain generation

Terrain Nodes | Terrain Nodes (iperson.github.io)

7

Yeah, I’m not sure exactly what the plan is for when to expect solvers, but I think 3.2 will probably be continuing to focus on procedural modelling. That means the 3.3 is probably the earliest we could expect progress for simulations, and even that’s not guaranteed. Still, it will be worth the wait!

1 Like
8

Erosion sounds great as independent physics solver inside Geometry Nodes. I see a lot other uses for it beside terrain generation.
The simulation could be baked and cached for performance.

3 Likes
9

I’m not sure other’s opinions on a dedicated object type, but I think it’s a reasonable idea. As is often the case, using the right data structure can make things possible that just weren’t possible before. Even just the memory requirements for meshes are a good reason to have a separate type. Using Mesh here, that’s 84 bytes per vertex, for MVert, MEdge, MPoly, and MLoop for every point. That adds up quickly!

Even though the simulation is an important part, I would suggest waiting to incorporate that, and instead focus on getting procedural operations and fields working with geometry nodes. The fields system is well set up to handle things like this, integration with geometry nodes wouldn’t be very hard. Only CPU evaluation is supported for now, but we’re planning to add GPU support at some point, and these things should be unified too.

Simulation is one of the next topics for the geometry nodes project, and like others are mentioning here, it would be best if this used the new generic node-based simulations as they are developed.

Generic attributes should be supported on the heightmap data, just like the point cloud object type.

For rendering, might it make sense to support rendering a heightmap directly, rather than converting it to a mesh?

This doesn’t sound like a great option to me, the UI and evaluation should be separate where possible I think.

15 Likes
10

That makes sense as long as baking to a Mesh doesn’t become an after thought. Export to a game engine would be one of the most important use cases for this. I’d rather wait for something that’s feature complete than have something that can’t fit into a pipeline, which often happens with new features.

11

Rendering height maps directly sounds interesting. But I wonder if a native heightmap object might raise compatibility issues with other renderers. Like Luxcorerender, Prorender, … which do not nescesarly support direct rendering from height maps.

12

Hello everyone, this is my first post on dev talk :slight_smile:

Having a proper way to generate these with erosion in blender would be an absolute blessing. It would open up the creation of realistic heightmaps to a lot of people.

I think having the erosion node/system is the most vital. In general I think this should work in geometry nodes as it would give you acces to a lot of tools such as RGB curves, basic math opperations, domain warping. Having full control of the height values is a big thing that is also missing in ANT landscapes, having acces to nodes would solve this issue.

it is not in relation with other simulation systems of blender

not sure if you mean this from a code perspective or from a feture perspective.
I thinkg feture wise its not an issue seeing that most simulators in blender already do not interact with each other.

For rendering, might it make sense to support rendering a heightmap directly, rather than converting it to a mesh?

I think this would save a lot of pain as you do not need to set up a lot of things anymore to quickly generate something.

13

@LeonardSiebeneicher @theois I don’t see a reason why there cannot be both? Mesh will always be the default representation, but having the option to render the height map directly can only be a good thing, right? If other renderers don’t support it, then you can just convert it to a mesh and render it that way.

3 Likes
14

Very nice idea, heightmap for terrain open so many possibilitys

Extracting heightmap from scene meshes maybe a good feature… for things like roads, paths, flat areas, lakes and rivers.

Dinamic mesh generation with LOD.

15

Looks really nice! I am interested in how the whole process work because it will affect several areas in Blender (Object Type, Rendering, UI). Are you already in touch with the module owner of the different departments? I would really like to see this becoming realitiy.
Many environment artists will try to use Blender and it could be a very cool workflow for game development. But I want to avoid that you are too far in the process and then experience some showstoppers that could be avoided in the very early stages.

16

From the rendering side, I don’t think we’re very likely to see heightmap geometric primitive in Cycles or Eevee, and I don’t think it’s a common feature in other renderers. Instead a displacement map is something that renderers can handle and might already implement optimizations for.

7 Likes
17

I’ll prefix this by : I’m not in the modeling module, nor in the physics one, so my opinion shouldn’t hold too much weight, i’ll share it regardless since it seems counter to what’s been said in this thread sofar…

While revamping landscape support sounds exciting, I can’t help thinking this proposal aims… a little low… 2D heightmaps were an awesome cheat when compute and memory resources were limited, but erosion (and plate tectonics for that matter) are inherently 3d processes, there’s overhangs and crevices, there’s caves and waterfalls with plunge pools, landscapes are 3D structures (for some reference material, punch in johnston canyon into google images),

Starting something new in 2022 and aiming for “just” heightmaps, feels more like a catch-up than something new and exciting.

The next gen game-engines have seemingly said goodbye to 2d heightmaps already, why would we be investing in them?

14 Likes
18

I agree with a lot you say, terrain certainly is 3d. However I can tell you I am involved in a project where Heightmaps are crucial to making the terrain. Having a solid, realistic looking base terrain saves us a giant ammount of time. From this heightmap we can work further adding in the more 3d parts.

The big reason why I would like to see this in blender is because frankly all the other software is paid.
What is worse is that often you get limited in render size as well. Next to that, the only thing I miss in blender that would make this workflow possible is to have good erosion. Even the most boring looking iteration of noise can be made intresting with erosion.

so essentially you are only really paying for this one feature.
It is quite frustrating there is no good alternative at all.

I am not sure about the status of heightmaps in terms of prevelancy.
But I would assume they are still quite common since they are easy to understand
and in my mind quite flexible for smaller scale projects.

4 Likes
19

I understand that 2D heightmaps are very limiting, but it can cover most of the cases.
Holes in terrains are rare for large landscapes.
I rarely see some landscapes with caves, or floating shapes.
Of course, some mountain cases are not possible with heightmaps, like floating rock structures.
But these structures are usually small(relative to the whole terrain) and handmade ( sculpting or so).

Imho, 2D heightmaps are good for a part of the process : erosion.
It can seem a little part, but in fact not.
A terrain is nothing without this natural touch of erosion.

I do not know of any technique doing erosion on a 3D mesh.

What technique do you have in mind for 3D meshes in terrain creation ?
I would be very interested in exploring them.

4 Likes
20

It seems to me
or by analogy with physics modifiers
erosion could be the first baked texture modifier
edit:
In such a case, the texture modifier stack could also bake shaders
bake scene images
…