Quick Update on Latest Release

Just figured I’d write a quick note about what’s happening with the latest dev channel release.

A current version with the river tool has dropped to the alpha testing team a week ago; changes and additions are still being added at this point before the Dev Channel release.

Beyond the river tool itself, I wanted to take a quick look at a few other things that will be showing up soon:

Scene View Device


Water surface display
Water surface display in the Scene View device

The Scene View device is an extension of the Overlay View, that accepts additional inputs over and above a simple terrain/bitmap combo. The first additional input is what is shown above: you can supply a water depth or watertable map which will be superimposed upon the terrain, allowing you to preview the water surface of your rivers instead of just the riverbed.

This is important because the water level slider presently available works fine for simulating an ocean height but lousy for rivers that have gradients!¬†This ability to display arbitrary water levels is pretty critical and useful; and if it gets you excited about other devices that could export water levels, it should.. ūüôā

Another key eventual purpose is to help with workflows using splat maps, where it’s hard to visualize the final result within WM itself. The Scene View will eventually accept your splat (guide) map and also the set of textures you intend to use in-engine and display them appropriately; this should give you less round-trips to the game engine when doing basic map design.

Better Curves

The rough control possible in the Curves device has been a complaint of everyone (including myself!) for a long time now. The Layout curve editor was better but still only let you have linear segments.

I finally took the time to improve the Curve Editor; crucially, the editor is shared between the Layout Generator and the Curves device now, and drastically improved:

Editing a profile curve
Editing a profile curve


This change makes the Curve Filter device about 10x more useful! Presets are shared universally, letting you use the same curve for a layout shape that you might apply to a heightfield.

And oh, did i mention that Curves are now a separate datatype that can be wired to devices? ūüôā Eventually, devices will be retrofitted to accept curves to specify their behavior in all the various ways you can imagine that would be useful…

Device Versioning

The Curve Filter is also the first device to show off the new way that we’ll handle device improvement.

In the past, when device functionality changed, an import path was attempted to be created, but sometimes it was impossible to capture the old behavior while still allowing the new.

The new method is to preserve old behavior in a deprecated version that will load by default in older worlds, which you can switch to a new version when you like.

Switching to the new Curves device…

Note that I can’t guarantee that a deprecated version won’t go away at some point; but you’ll at least have fair warning that you’re using an old version now.


Erosion Improvements

The erosion device has gained two new inputs: A rock hardness map input, and a sediment capture input. Combined, they work to provide more control and nuance than the simple mask input provides. Here’s how they work:

Rock hardness does what you expect, and modulates the resistance of the underlying substrate to erosion. Here’s an example image, where the hardness varies from very hard to very soft as you move left-to-right across the heightfield:

Variable hardness erosion
Variable hardness erosion


This is pretty simple, but useful! I originally didn’t include this input because I didn’t think it made a large enough difference — but especially with geologic time enabled, it can certainly be a very powerful thing to control.

Here’s another example. In this one, a simple gradient slope is being extremely ¬†eroded. Guess what area contains a big dollop of resistant rock ūüėČ

Extreme erosion with underlying resistant rock
Extreme erosion with underlying resistant rock


So, that’s some exciting new stuff. The big question is, when does it drop to everyone not on the alpha team?

I’m inclined to say “sooner than later”; the whole point after all of the Dev Channel is that things can be in an unpolished state with some rough edges and weird behavior still. But there’s still at least some minor things that should be done, like adding icons still for all the new devices…

A bit hard to tell what's what at the moment...
A bit hard to tell what’s what at the moment…

But once that’s done and a few other loose ends are wrapped up, it’s probably time to drop the very first version of the river tool to the Dev Channel — I’m sure there’s going to be a million questions and suggestions once that happens, and it’s better to make that sooner than later ūüôā




So, it’s definitely time to talk about the River device in the next dev version of WM.

The river device is a major expansion of World Machine’s path tool, providing a huge amount of new flexibility in terms of creating “hero” rivers; that is, major rivers that should be under artist control, as opposed to those created by an automatic simulation-type process.

The best way to describe the new river tool is “semi-automatic”. That is, you will draw in the essential path you want the river to take, much like you might currently do with the Layout Generator’s path tool…

From there however, things become different.

You’ll set some additional¬†¬†basic parameters associated with the river, for example the typical river channel width. The real power is in the river variation model; The river device accepts a¬†new datatype called a ¬†“Geomorphic Covariance Structure”, or GCS, which is a description of how the river is shaped in different scenarios. These can be as simple or as complicated as you like; they are created by new devices and/or macros that you or others create to describe river behavior.

The hope is to ship WM with a collection of macros that allow you to plug-and-play GCSes, for archetypal rivers. For example, a lowland valley river vs a fast moving mountain stream.

Some River Geology


To describe what parameters are under the control of the GCS, we’ll have to cover the basic geologic features of a river valley. This includes things like:

(All geology pictures below are wikimedia creative commons sourced)


Meanders are an emergent behavior of the fluid dynamics of a river, causing the river’s path to oscillate back and forth across the general downstream direction.

A meandering stream

From your specified river path, meanders are added. These can be specified in all manner of realistic (and non-) ways. Although the model is deterministic rather than simulating hydrodynamics, it does an admirable job of recreating river meanders.

Thalweg Behavior

The thalweg of a river is the deepest part of the channel. Our river model captures the repetitive pool and rapids behavior of a river as well as the lateral movement of the thalweg back and forth across the channel due to meander bends of the river.

Cutbanks and point bars

This includes cut-banks (eroded areas on the outer sweep of a meander), slip-off slopes (shallow areas of deposition at the inside of the river bend), and point bars.

River Width

Although you specify the average river width as part of the creation process, the GCS will vary the width of the river in a pattern relative to the meanders and thalweg.

This is very important, as wide/narrow points of the river are often strongly correlated with deep or shallow areas of the river.

Floodplain/Valley Shape

Finally, the GCS can also describe oscillations of the valley walls relative to the meanders/etc. Although the shape of the valley is more influenced by factors not specifically related to the river itself (such as hillslope erosion), including this in the GCS lets you correlate things like narrow points in the valley to the behavior of the river channel itself.


So, that’s the geology primer, now let’s look at the actual implementation in World Machine!

The River Model

Here’s a quick walkthrough in pictures of the River Model in action:

A basic river and floodplain


Above, you can see a basic straight channel with a simple but powerful River GCS applied; the river moderately meanders back and forth across the gently rising floodplain, with all of the other parameters (depth, width, riverbank cut, etc) all varying in concert to model a basic river.


Here’s a slightly more complicated river that also includes a surrounding valley:

River, Floodplain, Valley walls

The valley walls are included in this GCS; also, note that a distinct meander belt is present at the base of the floodplain (the shelf present near the river channel itself that, in reality, represents the area that the river continuously migrates within).


Finally, unlike the last few images that feature the river by itself, here’s a more complete example that shows the river embedded within an actual terrain:

Textured River Generator Example

This example uses a number of additional river model mask outputs useful for texturing, including masks indicates where the channel, floodplains, and valley exist, as well as a depthmap that can be used to identify deep pools or shallow riffles. This example also includes using the new sedimentation mask input of the erosion device to erode the terrain while preserving the river channel area itself.

The last thing I’ll mention about this upcoming release is that¬†it represents a starting point; Hero rivers were the logical place to start this process, but I can certainly envision extensions to allow a “click to spawn a river from here” method within the Layout View, and perhaps even an eventual fully-automatic river mode that can turn the basic “river networks” created by flowmaps into fully detailed individual rivers. But that’s a post for another day.


What’s in Progress At the Moment

Hi folks,

I realize things have been pretty slow/uncommunicative lately, for which I do apologize. It’s probably well overdue for me to lift the veil a little bit and show what’s in progress.

If there’s a theme to the next release of WM, it’s this:

Framework Changes: Generalize to Specialize

Cryptic? Here’s what it means.

All of the changes below are changes to the way World Machine works on the inside. These changes have been made to allow for new planned devices and features. Many of those new features have not been written yet, but I will discuss them anyways to provide the context for why the change was made.

Goodbye Layout Generator?

One of the major framework changes is allowing many more¬†“Layout-type devices”, not just the Layout Generator.¬†In WM 2.x the layout generator and the view are intimately linked.

No longer!

The Layout Generator will be renamed “Layout Shapes”, reflecting that many more Layout devices will be on the way. A new “Layout” tab will be added to the toolbar, and any device (including plugins by other authors!) can now potentially expose a layout UI.

This will immediately be useful in the River Generator device described later. But in the future, other exciting abilities would easily include:

  • Layout Faults (create specific terraces/fault lines at a location)
  • Layout Roads (an enhancement of the path tool that could better model roads by including concepts like banked turns, etc)
  • Layout Segments (let you create segment maps interactively — for example, quickly create a mask for a particular valley by clicking anywhere in it)

I’m sure you can think of many more specialized layout devices that would be useful! And I’d love to hear your ideas. The main thing that has held this back in the past was that the layout interface was only available to the layout generator; that will no longer be true.

Curve Datatype

This is a simple but powerful extension — there are now a variety of devices that produce and manipulate 1D curves. More will appear with time. ¬†Eventually the existing devices will be retrofitted to accept them — making the existing Curves device much more useful since it won’t just be hand-sketching curves anymore.

More Macro-like things?

The macro device is also quite special in WM 2.x. It’s special-ness has been extracted, and can now be extended into new devices. Why would you want to do this?

  • A Repetition (or Loop) Device would apply its internal network multiple times, looping the result of the first application back into the input for the next time around. This lets you do things like apply a “little bit” of erosion of one type, then a bit of another, repeated over and over to create novel effects.
  • Devices can now have “internal networks.” This is like a mini-macro where you can override and provide¬†more sophisticated effects than are built in to the device — for example, the Scatter device is planned to have a “User Specified” compositing type that would let you¬†create¬†the merge operation with an internal network rather than than using the default alpha blended/max/etc options.

User-defined Datatypes

I can already imagine the head scratching on this one — Not exactly the kind of headline that gets you racing out of bed to use World Machine. And yet, this is a really powerful framework feature, and I’ll explain why below.

There are lots of places within World Machine where you really need more than one piece of data to make sense of something.

Essentially, it’s now possible to¬†create custom datatypes that are a bunch of existing World Machine datatypes (heightfield, RGB, parameter, etc) glued together.

This is roughly equivalent to creating a “struct” in a regular programming language. What’s more, the same code allows for treating an arbitrary number ¬†of the same datatype as one thing — roughly an”array” in a programming language.

What does this enable?

Composite Things

Common things you might want to specify that previously would take two or more wires can now be carried around as a single thing. Some examples include:

  • Distortion amounts (specified as either an X and Y distortion amount map, or angle and amount maps — what’s more, you could throw in a parameter as well to let you tell apart which one you have on your hands!)
  • RGBA (RGB and an alpha mask)
  • Texture weightmaps (rather than a bunch of individual wires, you can treat textures and their weights as one unit)

Collections of Things

“Collections” ¬†of heightfields/textures/etc that can be treated as a single entity. This lets you do things like:

  • “Execute for All” macro device that could perform all of its internal operations on each element of the collection. For example, if you imported a whole library of textures and want to color-correct all of them the same way (or, have each one automatically adjusted according to the network you’ve set internally). I haven’t pushed in this direction yet much at all, but it certainly would enable “batch processing” type workflows..
  • Provide bulk variations to the¬†Instance Scatter device — if you have a whole library of individual things you want to scatter, you can just connect the library to the scatter device rather than 20 individual wires…


How does a complex feature like this actually make your life easier? In lots of ways. For example:

  • Remove clutter from the workview by having groups collapse all of the wires from devices in one group heading to another group into a single “cable bundle”.
  • Macro and plugin authors can transfer large numbers of settings between several different devices without exposing any of them to the user, making things much cleaner and intuitive for the end user — keep all the spaghetti inside the black box where it belongs.

So far, I’ve talked about framework changes. I should emphasize again that at least half of what I’ve talked about here is still in the future. What’s been made so far is the framework to enable them.

The Loop Device doesn’t exist yet, for example, but with the new framework in place it is trivial to create. The focus so far has been in designing the generalizations that will allow better specialization in the future.

In the next post, I’ll talk about the major new feature that inspired and leverages these changes, the River Generator…

The latest 'Behind the Scenes' news from Stephen, the author of World Machine