@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.
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.
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.
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
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.
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.
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.
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
