First of all, thank you @Kdaf for having the balls to open this pandora’s box called terrains(and everything related) in Blender, a topic which I have “love hate” relationship with for last 15 years
I see some nice ideas and suggestions, but also quite a lot of noise. I read whole(still short) thread till the end and got lost, asking myself what is this all about. Don’t get me wrong, all of the points in your initial post are perfectly valid(I do vote up for new Heightfield or 2d volume data type), but this is not really a proposal and honestly it’s “biting off more one can chew” in a single thread.
Wouldn’t it be better to split off Erosion | Rendering | Heightfield data type topics into separate threads? I’m a bit afraid that in few weeks, without your moderation, this thread will become a mess, time consuming to read/understand for community and more importantly, developers.
Anyway, I am really excited, because it seems that the makers of all the terrain generation software out there have some cartel agreement that the user interface and UX of any terrain generation software has to be as horrible as possible. So I am really happy about the idea authoring my terrains in Blender and finally stop bashing my head against the table every time I open Worldmachine
What about Gaea ? a friend tried it and seemed very enthusiastic. It mixes nodes and painting. I think this should be a goal for geometry nodes in general, not just terrains.
The UI is extremely laggy and the whole software crashes a lot. I had high hopes for it because it seemed to break that rule, but it did not deliver unfortunately. It’s been several years since the release and it still has alpha release level of stability and UI performance.
Yes I would see this more as a Node system (inside GN I suppose). Although Ocean modifier or Mantaflow have their own property ‘‘panel’’ and are working quite nicely on their own.
Sorry, I have never tried any terrain generator
I suppose it could work a bit as Embergen when you mix node to get your sim result (e.g as having a spline input to create a river, plugging wind or erosion, etc. )
Just curious, did you try Terrain Mixer, it seem they use GN with their last version. I suppose they are mixing noises and have no ‘‘real’’ terrain erosion. But result seem visually pleasing.
For going down the 2d heightmaps road, wouldnt it make sense to implement it in the new texture nodes workspace ? Its essentially just a 2d grid you can iterate on using gpu functions too.
Reading this, I am not sure Blender is in need of a dedicated terrain generator so much as giving Geometry Nodes the functionality it needs to allow users to create comprehensive terrain modifiers.
An example would be changing the integer socket in the subdivide node to a field that can take data from textures and masks (to allow adaptive subdivision so as to generate features while not causing memory use to explode).
In general, as Everything Nodes advances, a lot of requests for more specialized systems could eventually be answered by the BF having a page where premade node trees can be downloaded as an asset (which the user would then fetch from the asset browser).
I agree.
Making terrain sounds like a pretty specialised usecase.
Approaching the issue in a more general way (giving technical artists the tools to create new tools) sound more feasible.
I reckon a lightweight “height field” data structure could potentially make all terrain-related tools/nodes much faster, even for extremely detailed terrains. My understanding is that it stores only a value per element (height) and no connectivity information like the mesh structures do.
However it would also prevents overhangs, arches and such other geological structures… just like a height map applied on a grid does. But that wouldn’t defeat the pros of having it imho (provided I understand the implications more or less correctly).
Erosion effects for Geometry Nodes could be interesting, including erosion effects for Volumes.
I did not look through all answers to check if someone already wrote about it. Aren’t there plans for an improved texture node editor?
Blender’s procedural texturing system is in urgent need to be upgraded. Modern workflows offer node-based procedural textures that can be layered to do something similar to image textures – or better. Blender 3.x roadmap — Blender Developers Blog
This could be interesting for height maps, flow maps, direction maps, etc.
Might (heightmap based) erosion effects be an option there?
It would be great to have heightmaps but we must be very careful how we implement it or we will have a useless tool that only serves to create terrains where the user has little or no control and only serves to make postcards. That is what happens to many of the software of this type.
Anything other than the user having control of the initial base and being able to tweak at intermediate points is a waste of time. Similar would happen if the mesh was only usable in blender.
The system should allow to stop the calculation and work on a low resolution version. Besides allowing to save the final version in some kind of cache. Otherwise it would also be unfeasible to work with this system.
There would be several ways to allow this.
Now that blender wants to allow again to use texture nodes is a good moment to implement this kind of ideas on that texture nodes, allow to use in the splines, gradients,… with which to configure the base and masks. Enhancing this feature that you want to use.
Implement it inside geometry nodes. Allowing splines from the 3D world to form the terrain (which road creators will love). Which has a danger and it is the same that Houdini has, a joke performance and very difficult to use because of this.
The catch is that it requires Python (so it is speed limited), but I do recall numerous times where the devs. prototype something in the language first before adding such functionality as an official feature (so this could be seen as a way to test some ideas regarding the addition of the solvers mentioned in the code blog).
. Notice the long and high ridge that connects Rakaposhi and Hamarosh. From this picture, I think similar structures can be used to create cracks or lightning textures.
Another interesting (but probably unrelated) feature that can be used for generating landscapes is to have the option to feed render output from cycles back into the 2d terrain data, so you can implement the following algorithm:
Init:
Use “Sun position” addon with a sky texture, set time to Winter solstice, and set a suitable latitude
Create an initial heightmap
Set a camera to use orthographic projection, and view the landscape from above
For each iteration:
Render
Let T(z, intensity) be the temperature at ground level of a given pixel. T can also be affected by the temperature map from the previous frame
Use floodfill for starting at the sea corner to determine rain shadow due to mountains
Use T and the precipitation map to spawn rain or snow depending on T
Use (1 - green), T, and the precipitation map to control vegetation growth rate, and update the vegetation map
Update time-of-day
Repeat
Too many ins and outs and different arguments to tackle regarding terrain creation as a part of blender core.
So, let’s simplify it to a single fact.
Terrain creation is NOT a part of 3D modeling, If we go down that road, one can easily ask “What about cloud generator via volumetrics” and so on, its too case specific.
I do appreciate all the time and effort but i do not think its the right project for it, maybe a standalone software that can export object files would be better.
This could not be more wrong. Terrain generation is an exemplar use case for a typical procedural modeling system. Houdini being a prime example. Same with cloud generation using volumetrics, which is something Geometry Nodes can already do. Geometry Nodes are procedural modeling system and terrain generation is exactly the kind of work procedural modeling systems should do.
Lets also not forget Gaea and it’s node system of procedural generation.
Also as far as i know terrain generation is part of the environment design , mountains sculpting, rock models etc, in essence it’s 3d modelling just more specialised and procedurally oriented.
I’d absolutely love to have more features to help with making 3D terrain, but I can’t help wondering if our time would be better spent working on new procedural texture algorithms geared towards terrain, as opposed to real-time erosion.
If, for example, we had a “Terrain Texture” node with various algorithms to choose from (like how the Musgrave works, only more varied), representing different types of terrain, with each algorithm having some values you could adjust to your liking, that would allow users to create this sort of complex terrain with Geometry Nodes.
You can create all sorts of advanced noises and shapes by combining and distorting the basic, already available procedural texture nodes. It seems like you think of a procedural texture node as final output of a terrain shape, rather than their basic building block, which is a wrong way to think about it.
You don’t want to have one giant advanced procedural texture node with tons of hardcoded parameters. Instead, you want to be able to build it yourself from a more basic building blocks in a form of node group.
Anyway, even if you have super advanced procedural noise node for terrain, no amount of buttons and knobs will replace erosion simulation. Erosion is by far the most important part of creating realistic terrains. I mean just take a look at WorldMachine for example. Even the most basic perlin or fractal noise texture will end up looking like a realistic example if you feed it just through a single erosion simulation node. At the same time, even if you have super advanced 30-parameter multifractal noise texture node, no amount of knob tweaking will give you something truly terrain-like without erosion simulation afterwards.
So I am really happy about the idea authoring my terrains in Blender and finally stop bashing my head against the table every time I open Worldmachine 
