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.
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âŚ
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.
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.
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.
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.
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
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.
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.
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âŚ
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).
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.
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â
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