Does WM support Fluvial Erosion?

@Delta_Research and I were wondering if WM is supporting fluvial erosion or not, after reading this article.

As far as we know, the erosion device emulates the erosion caused by rain droplets carrying small amounts of depositions, but does it also take water systems into account, and with that, does it support fluvial erosion? If not, would it be possible to add fluvial erosion to WM for better water simulation? To our understanding, the Flow Restructure device and Create Water device already have “knowledge” regarding “all water from this area goes through this point and creates a river”, something fluvial erosion would also require, indicating it is possible to implement?

And thinking of it, this may help with the problem the Erosion device has with existing water systems, as described here. The create water device and erosion device would sort of “merge” then.

1 Like

Combining the erosion and create water device might create problems with tiled builds, so we should have an option for old erosion in the event that fluvial erosion is implemented.

1 Like

We should also have a slider for the No. of samples to take? Or is it just the erosion duration slider?

Right now that is probably implemented as the erosion duration, but it could be added as a “iteration” slider. The duration then only indicates the timespan, and the quality the number of iterations per duration, and therefore the quality of each “duration”? As I’m writing this comment I’m doubting if that is a useful feature or not…

I don’t know if this is helpful, but I seem to recall the GeoGlyph set of macros for World Machine including a Fluvial device, so it’s probably possible to get something going just in stock WM. It could be possible to study the results of that macro and reverse engineer it. That being said, while the “Community” version of GeoGlyph is available for free, I don’t know if it supports newer versions of WM.

1 Like

GeoGlyph, however, also had some plugins. It could be this fluvial erosion was done in code rather than with existing devices.

1 Like

That is definitely true. I wonder, with the LTE version, will we see the return of user created plugins? I’ve been getting heavily into development lately, and would love to try my hand at creating some new devices.

To my understanding, user created plugins never were lost? The PDK is up to date, so you should be able to create your own devices right now. However, since WM is going to use a new layout system, QT, I don’t know if that is something new plugins should keep in mind (probably they should). Too bad I don’t have time to learn C++, otherwise I would’ve surely written some of my own :slight_smile:

I meant more as “Will we see an updated PDK”, I assumed one would be needed, and wouldn’t want to spend a whole lot of time working on something only to have to rewrite it when LTE comes out. Though it could still fun and useful to just get a handle on World Machine plugin development.

Well, I don’t know but I suppose a new PDK will be released? You could ask Stephen directly :wink:

1 Like

Fluvial erosion is simply erosion by water-based processes. The existing World Machine erosion device models fluvial erosion via a direct simulation process.

From a (very) quick glance through the paper above, it looks like they are doing something similar to what the Flow Restructure device does in “Synthesis” mode; which is to say, using stream flow relations to create terrain. I’ve attached a quick example here.

Synthesis Example.tmd (8.0 KB)

The Flow Restructure device is incredibly powerful, and useful for much more than its namesake; the more exotic purposes haven’t been fleshed out or made very controllable yet, so it is more of a proof of concept.

Regarding plugins:

I very much want LTE to support easier user-created plugins.

The achilles heel of the C++ plugin system has always that it requires the plugins to be rebuilt every time the internal framework is improved or changed, which is pretty much every release.

For LTE, I’m about 90% sure that at some point I’m going to embed a Python environment in WM. This would let you create a ‘Code’ device that implements your custom simulations, etc in a higher level language that also wouldn’t break on update. Python is of course quite slow, but things like Numpy or Halide can go a long way to helping this. Absolutely no promises on when this will happen, but it is currently a higher-priority on my list.

3 Likes

Glad to hear our hunch was in the right direction :slight_smile:

The plugin system to support Python would be really cool and surely will benefit WM, though complex terrain generation may be a problem. I just watched a talk regarding Haskell talking with C++, and may will explore this to see if it is possible to let a device use some Haskell code. As of now I don’t really have any meaningful ideas for plugins, but it surely would be interesting to delve into this possibility :wink:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.