Heightfield erosion in v2.5

[Aaron]

Hello all,

I've done some minor tweaking to the channelling erosion routine to improve the strength and speed of stream-based erosion, as can hopefully be seen in the quick screenies below:



With these improvements I think I can start looking at full river-course erosion using longer run-lengths, more levels, and weaker erosion per pixel. I'll let you know how it goes.

Cheers,
Aaron.

[JavaJones]

Very nice-looking results. Realistic river-type erosion is something of a holy grail still. I'm looking forward to seeing how this comes along.

- Oshyan

[SeerBlue]

it is looking really good, I spent quite awhile staring "thru"the water in the lower left corner of the first render, looks like erosion rills following the flow of the water to me, but it is late and my eyes are old, so it may be wishful vision. SeerBlue

[monks]

Very nice! I'll say it again, there's always something pleasing about L3DT's terrain.
full river-course erosion...go for it!

Does L3DT use/ generate sediment carry? I'm thinking that not generating sediment is beneficial in ME-DEM's case because we are generating heightfields from topos which show river courses post erosion. Erosion tends to make things less predictable: sediment is the biggest culprit for blocking of river valley exits.

monks

[Aaron]

Hi Monks,

Does L3DT use/ generate sediment carry? I'm thinking that not generating sediment is beneficial in ME-DEM's case because we are generating heightfields from topos which show river courses post erosion. Erosion tends to make things less predictable: sediment is the biggest culprit for blocking of river valley exits.

Somewhat. You do have to account for sediment in some way or else the erosion will take away all your land. If the flow of water only takes away land and doesn't put it anywhere, it will be rather hard to avoid a chaotic solution in which the water never finds a minimum and sloshes around eroding everything. However, the particular implementation in L3DT is rather cut down for high speed and low memory use, so it doesn't do a particularly fancy job of sediment deposition. It won't, for instance, make all those winds in rivers as sediment builds up on the inside of bends, and it won't make a river delta.

Will it clog the exit to a valley? My feeling is no, so long as the valley exit is actually downhill. A continuum model of water flow might be able to open up valley exits since they can model pooling in the valley, which when reaching a certain level will overflow and erode the valley exit. I do have such an erosion algorithm in L3DT, though it's never been refined or released for public consumption as it's much slower than the current drop run algorithm. I might revisit that if it proves necessary.

Cheers,
Aaron.

[monks]

However, the particular implementation in L3DT is rather cut down for high speed and low memory use, so it doesn't do a particularly fancy job of sediment deposition. It won't, for instance, make all those winds in rivers as sediment builds up on the inside of bends, and it won't make a river delta.

Hmm- there are a few options kicking around at the moment for erosion. The super duper option is ooCAESAR but that requires big iron. However, ME-DEM might have access to big(ish) iron soon so I'd like to try that. Usefulness of such models depends on a few other things as well...you really need a high res model for starters to really show off those subtle effects (in a model like that anyway). At the moment we're running 20m dems max. Again though, we can get those down now pretty easily for closeups: a 2m dem is certainly on the horizon. The again, I'm sure though those subtle effects would show up in a 20m dem. A refinement in the model would be visually appreciable- you'd think so.
. Redrobes' geomorpher may have things to offer (apparently it can do those things you mentioned above)- it's hard to say: a gui is always a good thing to have. I've been pretty impressed with his shots over at the TS so far but a comparison between all of the apps to assess their strengths/ weaknesses would be useful for us anyway and interesting because I'd like to know more about how these algos work...so I'm trying to look into erosion more.

Will it clog the exit to a valley? My feeling is no, so long as the valley exit is actually downhill.

That's the real rub, but I think we've cracked that bit.

A continuum model of water flow might be able to open up valley exits since they can model pooling in the valley, which when reaching a certain level will overflow and erode the valley exit. I do have such an erosion algorithm in L3DT, though it's never been refined or released for public consumption as it's much slower than the current drop run algorithm. I might revisit that if it proves necessary.

So is this what redrobes has in the geomorpher: a continuum model? Sounds like you've got stuff stashed away for a rainy day. What qualifies as necessary? User demand/takeup ?. Ah I'm with you: if it helps with the full river erosion you're looking into.


It seems to me the problem with erosion is that it tends to break down at the lower gradients. you can see this in both Geocontrol's procedural zoom and redrobes' geomorpher. Could this be helped by running all erosion on vertically exaggerated terrain? I suspect that will bring with it a new set of problems for those really steep sections. Would increasing inertia/mass of water flow come into play downstream?, sounds reasonable. Is this one of the things current erosion algos are missing? I noticed you mentioned increasing the strength/speed of channelling erosion so that the rivers get a longer run. Sounds like the same thing.

Yes, this sounds like what's happening in World Machine: sediment is being carried down the valley and once the gradient becomes very low near the valley exit, the water gets trapped. Now WM may have a continuum model (or approximation) I don't know at all to be honest. I've not looked into it enough yet. But I noticed that the best way to have control over river exits is playing with the sediment carry. In WM's case, there was a sweet spot where the rivers all flows out correctly; a higher or lower setting and it blocks up. I've got some nice results if a little artificial looking but all we would have to do is introduce a bit more noise and things would improve.

Check out these two threads on the Terrain Summit:

http://terrain.cg-arts.org/forum/index.php?topic=73.0

http://terrain.cg-arts.org/forum/index.php?topic=78.0


monks

[Aaron]

Hi Monks,

So is this what redrobes has in the geomorpher: a continuum model?

Well, there's probably a better name out there, but that's what I call it. From my reading of the TMS posts, Geomorpher has a map of water height/sediment/etc, which is iterated using something like Newtonian dynamics. The 'dropwise' algorithm I use (I've coined another one!) simulates the path of each drop individually, which has certain limitations, but works well with large tiled data that's too large to hold in memory all at once (crucial in the context of L3DT.) With the dropwise algo, I can erode one tile at a time quite easily. With a continuum algo, you have to do the whole map one iteration at a time, and with disk-paged maps, that's really slow. Then again, continuum algorithms will give better results, but as with all simulations, it's quality versus speed.

Sounds like you've got stuff stashed away for a rainy day. What qualifies as necessary? User demand/takeup ?. Ah I'm with you: if it helps with the full river erosion you're looking into.

When I get some spare time...

It seems to me the problem with erosion is that it tends to break down at the lower gradients. you can see this in both Geocontrol's procedural zoom and redrobes' geomorpher. Could this be helped by running all erosion on vertically exaggerated terrain?

Yes, but it's not very elegant, and it will erode your hillsides away. A better solution would involve using two or more erosion routines. I can't say what the best settings for rivers on flat terrain in a continuum algo would be, but in a dropwise algo you need to have very low erosion strength, and very long drop run lengths. Naturally, this will take more time, but I can't say how much until I start to play around with it. I'll be sure to let you know.

I suspect that will bring with it a new set of problems for those really steep sections. Would increasing inertia/mass of water flow come into play downstream?, sounds reasonable. Is this one of the things current erosion algos are missing?

Some algorithms are missing that, yes. Namely, the faster ones. If you want to handle inertia/mass/momentum/viscosity/etc correctly, you will need much more serious hardware. In L3DT I am somewhat constrained in that I can't increase the memory requirements or calculation time by a factor of 100, or even 10, if I want greater realism/accuracy – users wouldn't accept it, and I could never test/debug it. All my algorithms are greatly simplified to fit into the hardware profile of an average desktop.

Yes, this sounds like what's happening in World Machine: sediment is being carried down the valley and once the gradient becomes very low near the valley exit, the water gets trapped. Now WM may have a continuum model (or approximation) I don't know at all to be honest. I've not looked into it enough yet.

I have a vague sense that WM is dropwise too.

But I noticed that the best way to have control over river exits is playing with the sediment carry. In WM's case, there was a sweet spot where the rivers all flows out correctly; a higher or lower setting and it blocks up. I've got some nice results if a little artificial looking but all we would have to do is introduce a bit more noise and things would improve.

That's the problem with erosion. We (users) want a particular outcome (e.g. river to run from here to there), but the algorithms just follow physics - or approximations thereof - and are therefore blind to our intentions. You can tweak parameters to get the particular result you like, but at the next river/valley you'll have to tweak all over again to get the right set of parameters for that case. Of course, users want an algorithm that "somehow" knows what they want and just gives it to them. A cynical programmer could make a remark about "unreasonable user expectations" at this point, but unreasonable or not, I suppose the pressure to meet them won't go away. So as not to be left too far behind the other developers heeding this call, I'll have another look at my erosion algorithms sometime later this year.

Cheers,
Aaron.

[DeathTwister]

A side note from the peanut gallery if I may /winks.

As to rivers, as I see it, they always follow terrain and always go downhill.

I know that is very simplistic, but wouldn't a physic's engine in the program cover the river erosion problem? Then if say you want a river start at this point and gather speed and width as it goes down hill, just like in real life. Then it would be allot easier to allow the math to calculate and create what you want and still maintain a certain amount of control that we need? Most all that math is out there as free source in one way or another, so wouldn't be hard to get that info, just getting it all to work is the trick /winks.... My money is on Aaron, hes the Man, err Elf as far as I am concerned and know when he puts his mind to something, he will figure it out. Hope ya don't mind me tooting your horn Aaron Brother, but you are that good /bows.

Anyway just a shot and a Thought to share with.

DeathTwister

[monks]

That's the problem with erosion. We (users) want a particular outcome (e.g. river to run from here to there), but the algorithms just follow physics - or approximations thereof - and are therefore blind to our intentions.

That's the crux of it.

You can tweak parameters to get the particular result you like, but at the next river/valley you'll have to tweak all over again to get the right set of parameters for that case.

Yeah that's the current situation. We don't have a general solution.

Of course, users want an algorithm that "somehow" knows what they want and just gives it to them. A cynical programmer could make a remark about "unreasonable user expectations" at this point, but unreasonable or not, I suppose the pressure to meet them won't go away. So as not to be left too far behind the other developers heeding this call, I'll have another look at my erosion algorithms sometime later this year.

OK. No, I agree. blue skies is very nice but if you're in the market you have other considerations. We're trying to work find a doable solution specifically for ME-DEM.

We (users) want a particular outcome (e.g. river to run from here to there), but the algorithms just follow physics - or approximations thereof - and are therefore blind to our intentions

I intend to get the initial model (pre-erosion) to a state of 'predictability'. All of the large scale terrain undulations are flowing correctly along the major rivers. I've pretty much done it with the last terrain I built. There are no pixels in those courses that flow uphill (famous last words!) (stop water flow) though there are tracts that are level (between tracts of downhill flow) The next one will be better from experience and new tools on the immediate horizon.

I had a look at NWN2 water mill...
http://www.bundysoft.com/phpBB2/viewtopic.php?t=413

From what I've read, in the electron toolset, water is stored as a map in the same way as a terrain. So it has a heightmap equivalent onto which the engine paints the textures, animates, etc.
It's forcing river 'flow' in one way or another. In Water Mill's case, the 'physics' of the flow is only as good as the flow in the model. It still uses raise and dig tools. When it paints a water texture it cannot ensure that the water is indeed flowing downhill; again that's the modellers job.
Notwithstanding the limitations, I quite like it and I'm tempted to try and use it at some point for a real time viz. Just look at the user feedback- there are a lot of people out there looking for more realistic solutions. I also like the anims that Redrobes has produced from the ViewingDaleGeomorpher- it's great to see that.

What if we had an algo that forced the flow but actually altered the terrain; bulldozed it?

This already exists (in some capacity) in GIS apps that have to deal with missing data in dems. I'm not sure if they alter the underlying model but they do correct the water /flow maps.

Carrying on from that last idea I've been looking more closely at the ME-DEM workflow and I've made a few suggestions on the TS.
http://terrain.cg-arts.org/forum/index. ... 309#msg309


monks

[monks]

I know that is very simplistic, but wouldn't a physic's engine in the program cover the river erosion problem? Then if say you want a river start at this point and gather speed and width as it goes down hill, just like in real life. Then it would be allot easier to allow the math to calculate and create what you want and still maintain a certain amount of control that we need?

Maybe one day game engines will have fluid flow simulation. That could be achieved one (sunny!) day but only if the terrain model will allow it. Having a terrain model with downward flow across all of its length would also lend itself for the engine to not have to calculate flow over the whole river course- only for that section you could see.

monks

[Jovin]

Has anyone played with RealFlow in Max or whatever? I'm about to order a copy, for all kinds of particle effects but water especially. I'm curious as to how anyone has used this plugin with terrain modeling/rendering.

[monks]

Hi Jovin, wow, that looks a lot of fun! No, I don't use Max. Most of the stuff I'm involved with is really to further our project (ME-DEM)which is not (currently) aimed at real time- though the output could freely be used for that. We're dealing more with terrain rendering (TG2 et al) and 3D maps, 2D maps. However, some ideas have been floating around about real time water sims in terrain editors- modelling in the rain if you like with the ability to turn erosion on/off. It would enable real time maps of river courses. These would be updated as you modelled.
I'm not sure how practical that would be but it's interesting nonetheless.
monks

[Jovin]

Hey monks! Imagine you on a river discussion ..

I've got RealFlow to play with now, and just need time. I'm actually going to attempt (if I have time left over) to render a terrain/sky in L3DT/TG2/et. al., import into Max (could be an experiment in itself) and try to drop a RealFlow waterfall/pool into it. Just thinking about getting some cliffs on one side of a heightfield map and drop a hole in front of it, carve a channel (probably end up doing this in multiple programs, I'm interested to see how Max is useful with heightfields) and twiddle with RF a bit. Haven't had a chance to really go through the documentation yet, I'll post anything related to simulating river erosion - sometime in April most likely (crunch time on my demo reel, currently currently obsessing over car model detailing . )

[monks]

Hehe- I'm a broken record...
Am I talking to Arandil...? That all sounds like it's going to be a lot of fun- especially the fluids yeah, cool! Post some shots when you're done. It must be nice to have 3DMax- ...//dream

monks

[Jovin]

Hehe- I'm a broken record...
Am I talking to Arandil...? That all sounds like it's going to be a lot of fun- especially the fluids yeah, cool! Post some shots when you're done. It must be nice to have 3DMax- ...//dream

monks

Yep! Yep! Totally. Although my 1 year cheapie educational license expires this fall. I may buy Lightwave or something, don't have the cash for a commercial version really..