Terrain Creation Workflow Proposal

I think a grid base erosion system might be extendable to 3D. Instead of a heightmap you use a 3D voxel grid to simulate on, same for particles.

Instead of saving an image file you save a pointcloud.

I am not sure about sharing yt content here but if you have not yet seen the impact of erosion on terrain I recommend watching Sebastian Lague video called: Coding Adventure: Hydraulic Erosion
He goes through the process of implementing nosie and shows the result.

The diffrence is huge,

1 Like

as I understood
according to the plan of using very large textures
and this makes 3d textures extremely expensive
8000 * 8000 * 8000 * 4 * 3 * 32 / 8 / 1000 / 1000 / 1000
gigabyte
for one texture…

1 Like

I see what you mean. Maybe the best approach would be particle erosion.

He uses the CPU, so I read the height from the geometry at the time. It is still based on heightmap. It can not be expanded to 3D with GPU computation.

1 Like

Just to explore this avenue a little bit.

If the erosion is limited to gravity only, it leaves very particular shape that can look common across all models.

There is at least one other way of making it more fun - wind erosion. Certain regions have winds of constant direction and can form land or vegetation in very specific way.

To make things even more interesting the ground could have different properties like granularity, type of rock, friction. Even couple generalized types could give very different outcomes when combined with different stating shape.

I do not think you would need to save texture channels anymore. Seeing you go to a full grid, I would have a 3D grid to just indacate where the mesh should be.

With images you need the channels to store the data, here you just need 1 or 0.

Basicly like smoke/fluid sim. I could be wrong do

intresting point about the GPU, I can see that being probemetic when extending to 3d.

My recommendation was primarily to those who have not seen the ressult of t hese erosion algorithms,
3D or not, they make a huge diffence.

the mistake is
what’s on the plan
you want to simulate smoke
like clouds
in a huge area
you would never in your life do such simulations

1 Like

That was somewhat my point, designing a brand new system and using a 2D storage somewhat prevents extending the design in the future to 3d, it be yet another rewrite, of something we just rewrote, while if you design the system to be 3d, extrapolating a 2d view of said 3d data would be essentially trivial, don’t get me wrong, I’m not saying do not support 2D whatsoever, it’s a valid use case still. I just wouldn’t make a new design/simulation based on it at this point in time.

This code needs to last another decade or so…

2 Likes

It is not because it is 3D based that it looks different. It is because he uses a different technique. He do particle erosion, and I used cells based erosion.

2 Likes

So what’s the point here ?

What you propose looks cool, but how technically it would be possible ?
Nowadays simulations are more and more done on the graphics card. However, doing a 3D grid strange to represent a surface. At the beginning, a terrain is a surface. How you would make a 3D grid from a surface ?
You can handle 3D meshes directly from the CPU, but it would make the simulations way slower. Correct me if I’m any wrong.

Agreed, I wish I could code better and knew more about Mathmatics to really contribute to the practical side of things.

Right now I am half trying to code my own version of a particle based “model”. It is helping me learn a lot, but I have a lot more to learn seeing it does not work great :joy:

So,
Is a 2D heightmap still valuable nowadays ?
Should we try to develop a whole new way to make terrains ? Do it really worth the time ?

In my opinion, heightmap is still valid, and offer some incredibly fast erosion even if it does not handled some specific behaviors.

The real question of this thread is :

  • How could we integrate a terrain workflow to the current Blender system ?
3 Likes

Think my point is, do better, aim higher, building something new in 2D feels like the wrong direction at this point, but do note I may as well be very wrong, it’s not even my module. I’m just giving a different perspective.

Making the leap to “how would you even make this run on the gpu” seems to be a little premature at this point, I didn’t suggest to use a 3d Grid, I never made any suggestions on how to solve the problem really. If you forced me to guess, erosion essentially a fluid sim with side effects, perhaps we can bend SPH to our will.

2 Likes

To be honest, I think that’s a lot to ask. 2D erosion simulations are a very well documented and there are a lot of practical examples of implementations online. It is used by all major terrain creation software, and is a very mature technique that has been shown to work well and produce amazing results.
However, 3D erosion simulations, as far as I can see, are comparatively non-existent and would probably require an entirely new algorithm to be designed and implemented. Not only is that quite a big ask, but I don’t think the advantages outweigh the disadvantages of such a system:

Disadvantages:

  • Harder to implement
  • Much slower to simulate
  • Would probably require a completely new algorithm to be designed
  • Couldn’t be calculated on the GPU (admittedly, I’m trusting @Kdaf’s word on this one.)
  • As such, it wouldn’t be nearly real-time, which is one of the goals of the Geometry Nodes simulation project.

Advantages:

  • You could have overhangs/caves.

The problem with that is that pretty much any terrain you would want to erode, would probably be too large to see features like caves or overhangs. If I simulate a mountain, the potential caves in it would be absolutely tiny.

Then again, maybe there’s some use case that I’ve missed that would make it worth it.

8 Likes

we have done no work on this, not a single hour spend to see what it would entail or if it’s even feasible but you have have already decided all these things, no clue how we would build this, or how it would work but you already have decided, it can’t be on the GPU and it’ll be slow… ok? not saying you’re wrong, am saying you can’t possibly know any of these things at this point.

me: we should do better
Y’all: ZOMG! that be …haaaaaaaaaaardd…

oh no…

3 Likes

It’s true, these are educated guesses based on available information. It stands to reason that a solution that works in an extra dimension will probably be slower, right? Again, I’m no expert on GPU simulations, I was just going off what had been said earlier.

I’m coming from the point of view that there is already a very good solution that has a lot of advantages over the one you propose.

Come on, we’re all adults here… What I was saying is that it may not actually be better.

Apart from anything else, this has been suggested by a solo developer, who is willing to implement it as is. If the BF is willing to come in and help with it, then you’re right, there’s no reason not to try, but as is, it seems unfair to place this responsibility on a single volunteer dev (unless they’re willing of course).

2 Likes

With all the jumping to conclusions, I wasn’t quite sure we were all adults, aside from that don’t get me wrong, I’m not against this proposal, if this gets implemented as suggested I have no doubts it be a big improvement over what is there now, however sometimes its good to challenge people a little bit, maybe we can do better.

4 Likes

I completely agree. I was simply responding to what you proposed. Sorry if I sounded a bit standoffish.

In my opinion it would be logical to implement something that’s well documented on something that’s never been done in this software. Regardless of how “old” it is, if it still has place in the industry pipeline and gives good results at good speed’s then i dont see the point to “reinvent the wheel” for the sake of “different for the sake of difference”

5 Likes

purely theoretical
I had ideas about making a fully destructible model
like spaces from tetraders
but even despite the great simplicity on large and empty spaces
this is extremely costly for huge landscapes
and I have never worked on it, but I still understand that operations on volume will be expensive
and requiring either differential equations or quantitative samples