Category Archives: World Machine Development News

Development News concerning World Machine

Build 3018.. What’s in a Name?

Build 3018 should be available tonight, and it will mark a significant milestone for World Machine…. without even considering what it contains!

Specifically,  3018 will become the basis for the next Release Channel build.  Although it’s natural to think of this as “World Machine 3”, we’re moving away from Big Number Releases entirely. In a world where quarterly+ dev channel feature releases and constant improvements are happening to World Machine, Big Number releases simply lose their meaning (unless you like Mozilla-style versions like ‘Firefox 53’…I sure don’t.)

Instead, World Machine will simply be branded as…

World Machine.

Whatever build number it may be.

Of course, some releases are still much more important than others, and it’s helpful to have a way to refer to them. Following in the footprints of Apple, Intel, and others, when a World Machine build contains major new features it will also receive a build name. We’re adopting a whimsical but appropriate version naming system; the build names will be notable mountains or natural features in the Pacific Northwest part of the US, my home.

And so, I introduce to you:

Build 3018 ‘Mailbox Peak’

The actual Mailbox Peak, midwinter.

Mailbox Peak is a local mountain near to Seattle that is beautiful in its own right, but serves especially as notorious training for mountaineers aspiring to larger summits. It’s a fitting name for this build…

Which more than anything, is about getting faster.

Let’s talk about:

  1. Speed
  2. UI Improvements
  3. New Coastal Erosion Device
  4. Many small changes


Build 3018’s primary focus is improving build speed for large worlds on modern, many-cored machines.

The subtext here is that I finally updated my 2012-era dev workstation to a modern, high performance machine — one of AMD’s new Threadripper processors. This thing is a beast, with 16/32 cores available, and it was immediately obvious that World Machine was not always putting such parallelism to work. So I set about to change that. You’ll certainly still notice the benefits even on more humble workstations.

Here’s a performance comparison on a selection of example worlds between 3017 and 3018:

Build 3018 is faster across the board, even where 3017 already did quite well. In certainly very common cases, it’s dramatically faster.

As you can see from the above, not only does 3018 bring sometimes-dramatic improvements in speed, but World Machine now scales quite well to high core count machines. Individual easily-scaled devices like Noise show completely linear improvement, while entire world builds aren’t that far behind.


Multicore everything

Virtually all* devices are now multithreaded. Many of these are relatively fast devices like the Combiner that on smaller worlds have a negligible effect. Nonetheless, when building large worlds, speeding up these common devices shaves seconds-to-minutes off the build times.

For completeness, the following devices received multithreading support:

Coastal Erosion, Equalizer, Clamp, Height Curves, Height Select, Slope Select, Select Convexity, Select Aspect, Select Hue, Combiner, Chooser , Channel Combiner, Channel Splitter, Circular Gradient, Constant Height, Constant Color, Height Combiner, Height Splitter, Normal Maker, Splat Converter, Local Placer, Local Scatter, File Input.

*The only remaining 1x devices are essentially just the parameter devices and the Tiled File Input device, which has a separate set of improvements in progress that needed to be coordinated with. That will happen later…

Optimized Implementations

Some optimizations have been made to the Erosion, Advanced Perlin, Snow, and Layout Generator devices. In addition, many internal core operations including mesh creation, grid resizing,  etc now use all processor resources.

In particular, the Layout Generator device benefits, now being able to use all threads to build a single shape whereas before each shape was only built by a single thread. In worlds that heavily use layout shapes, this will be a massive speed win.

New Compiler

World Machine has finally been moved to a modern compiler — Visual Studio 2017. This brings with it improved optimizations that on their own improve performance between 0-15%. It should also make writing plugins easier, as the old compiler was difficult to get a hold of these days.



This alone would be enough to merit a new release.

But.. there’s more.

Workview Improvements + Dark-theme

The workview has gained many small tweaks, most notably a new “dark” color scheme.

If you don’t like dark colors, you can switch back to the old default light scheme in program options. Due to the old framework that WM is built on, full dark throughout the UI will have to wait, but all of the OpenGL viewports use the new color scheme.

Also, a new option for wirecolor-by-group has been added. Just like the dark scheme, you can switch back to color-by-type if you’d like, but I think you’ll find that it’s very helpful to be able to color a set of wires according to a purpose.

In addition, various other bits of the workview UI large and small have been tweaked, including:

  • Improved grid/snap behavior — this is actually quite helpful as you can finally consistently line devices and groups up properly.
  • New “Snap All to Grid” to fix old worlds 😉 and for those who don’t use a grid normally.
  • Some improvements to wire routing, highlighting
  • Removed device deletion warning thanks to having Undo now
  • Pan using arrow keys in Device View
  • Default left-mouse drag action is now panning instead of box-select (use shift or ctrl for that)

In general, I spent some time revisiting the Device Workview to try to make its operation more understandable for new users.

New Coastal Erosion Device

The Coastal Erosion device has been improved for 3018. Although operating on essentially the same principles as the previous version (mostly based on modifying height curves appropriately), you’ll find it that it creates more pleasing results as well as being easier to understand and use.

The main goals here were:

  • Simplify the parameters, as many of the old ones were not obvious how to best manipulate together
  • Create higher quality output, in particular the way that terrain above waterlevel was affected.
  • Fix problems that made masks output from the old device hard to work with

Pursuing the first goal, the number of parameters was reduced to the essentials:

While hopefully the first image shows the kinds of results that you can now more easily achieve!

Smaller Things

Finally, a number of things large and small  have been tweaked:

  • Build Estimator lower bound improved
  • River Device goes directly to layout view
  • Entering river/layout devices scrolls to the render extents
  • Left-side preview says what device is being displayed
  • Checkpoint device now auto-names from the input names if nothing else is provided
  • Height Curve now lets you specify that it affects only a certain height range. This is incredibly useful! In addition, you can fade the curve effect.
  • Height Selector falloff is now specified in meters
  • 3D View now uses anisotropic filtering for improved graphics quality, and is smoother and more responsive
  • Build Statistics now update faster
  • Bugfixes, including “Disable group instead of device” and “3D View doesn’t update when view is frozen”


Build 3018 will go live tonight, hopefully.

The Release Channel version will follow along as quickly as I can make happen — it will contain reworked examples, etc, as it will also become the default choice for new Basic Edition downloads, and that will take some time. And then the WM website in general is getting a refresh to go with it. So there’s lots happening, but Dev Channel people get the action first!


Build 3017

Build 3017 is now live on the Dev Channel, with the full changelog posted on the update center.

The primary focus of this release was continued improvements to the River device, with special focus on making the UI and controls more intuitive to use. Although still certainly not perfect, this release is a major step forward.

Of course, there are several additional very useful changes in 3017, including the life-saving “Estimate build time” command in the World Setup dialog, but the focus was on the River device.

The first thing you’ll notice is that the rivers are displayed more intuitively; the flow direction is indicated by chevrons on the path, including marching flow direction if you don’t have a GCS overlay selected.


And although it’s hard to show in a static image, the behavior and defaults are now much closer to what an artist might expect, while still preserving the specificity that was possible before.

For example, if you just take the default WM world, drop a river device onto the output of the noise generator, and then click “Add Reach” within the river device and sketch a river, you’ll get this:

Which may not be especially pretty, but is probably a much closer match to what you were hoping to produce than the previous versions!

The main things that have been improved are:

  1. General UI behavior and display
  2. Elevations can now be manipulated much more easily: You can still manually specify a datum and slope as before, but you can also have the reach elevations be set automatically from the terrain (the new default). The river will be placed below the terrain elevation a distance specified by the valley height
  3. The reach valley walls are now improved and include both a fractal breakup and also control of the valley shape, allowing you to achieve both U and V shaped valleys.
  4. The behavior of child reaches is improved, both in the display blending between them and also the way they get their elevations from both the terrain and their parent.

There are still some issues with the River device, and it is currently flagged “Experimental” within WM, a new status for 3017 and beyond. Experimental devices are those that have notable issues that remain to be resolved, or expect to have their interface changed, but are too powerful to let them not be included.

I’ll end with a larger view at one of the new example files included, modeled very loosely after the Grand Canyon area. What’s awesome is that if you play with this example, you can easily add tributaries and extend the river with almost no additional work, while getting results like the below:
I don’t know about you, but that’s pretty compelling to me!

Lastly, I wanted to mention that this release is also going to lead into a major milestone — All of the features of the Dev build are going to be synced to the Release build soon.

Compared to WM 2.3.7, The current dev build is incredibly feature rich and advanced by this point. It was never intended to get quite so far ahead in the first place.  A variety of circumstances conspired including an unclear conception and policy on my part on deciding how perfect a feature needed to be to be Release-channel-worthy.

The result, among others, has been that new users of World Machine have been completely kept in the dark about all of the advancements over the last several years until they by chance read about or try the Dev channel.

There’s a lot more I could say about updating the release channel but I’ll keep this short for now. Briefly, the next steps  are going through reviewing, packaging, and revising examples, macros, and blueprints for all of the new features in preparation for updating the Release channel (including the Basic Edition). This shouldn’t take long.. keep your eyes peeled in the immediate future!

Build 3016

Hi folks,

Build 3016 is almost ready to go. I’ve been trying to rotate areas that get attention with each release, in an effort to evenly hit various pain points, requested new features, and features that you didn’t know you needed until you seen em. 😉 There’s still a lot of exciting things to come regarding rivers, texturing, new erosion models, etc, but I wanted to address a few other areas with this build.

One underlying goal is to be able to move the Dev channel build over to Release channel soon. Thus, a number of the changes are aimed at enabling you to create good results faster and with a better experience. Without further ado, here’s what’s new, improved, and changed, large and small:



Blueprints are a snippet of connected devices that you can quickly paste into your world. The intention is to speed development of common tasks of world creation, while still keeping all of the various parts visible and tweak-able at will.

This contrasts with macros, which intentionally hide their contents away and present themselves as an abstract, black box. This goal is complementary to Blueprints, which can make connecting and setting up your macros quicker and easier.

The uses are many, but especially:  Rapid creation of your world by dropping prefabricated “bricks”,  quickly placing sets of commonly used-together devices, standard file I/O blueprint for your project’s needs (directory structure, what to export, low and high res exports, etc), etc etc.

Blueprint files are simply TMDs stored within the Documents\Blueprints library folder, so they are easy for you to edit and share. You can create them either by saving worlds into the Blueprints folder, or using the handy drag-and-save blueprint creation tool within WM:

3016 will ship with some basic blueprints, but this is definitely an area where you will hopefully find  yourself quickly creating a custom set of blueprints, as the bar to creation a useful blueprint is intentionally much lower than macros.

New Library Interface



Build 3016 promotes both Macros and Blueprints to the same level as devices: Any favorite macro/blueprints are now available in the menubar as well as the right-click context menu. The improved library dialog fixes a regression where favorites were not being saved or handled properly, and now allows you to mark an entire folder as a favorite as well.

New Examples


The “Load Example World” command now also uses the library dialog, making it easier to browse the library of example files.

The library of how-to files and scenes  is being revised and fleshed out with an eye towards the next build becoming the standard Release channel build that is downloaded by new users.

I’m experimenting with making the Load Examples function more visible by promoting it to the menubar. This may or may not persist, but I want to make browsing and experimenting with examples as easy as possible for new users.


Several very important bugs have been fixed in this version, including finally tracking down a crash & build problem that has lingered in the dev builds for quite a while revolving around state corruption after undo/redo, device deletion, etc.  And in case you still run into a crash bug, World Machine now has:


The current state of your world is kept saved at all times; if World Machine crashes or your machine otherwise has an interruption, WM can reload your work on its next start.  This has been unexpectedly helpful to me during the development of WM itself, and it should continue to be useful to ya’ll in the field.

Copy/paste between instances

You can now copy/paste between multiple running instances of WM, as WM now uses the windows clipboard rather than its previous internal one. This may also prove useful for 3rd party utility authors, as the clipboard format used is simply the WM file format.

Misc small changes

  • Deleting a group now deletes all of its contents, including other groups
  • Instance scatter bugfix so that its placement mask does not move with the device origin
  • Checkpoint device ports can now be named by the user

Basic Perlin revamped

The Basic Perlin device was previously a “vestigial” device, as it was simply the older fractal noise generator and wasn’t necessarily simpler or easier to use than the Advanced Perlin that replaced it.

There’s now a reason for it to exist : going forward, Basic Perlin can/will be your go-to device for simple noise, reserving the Advanced Perlin device for when you needs its more sophisticated tools (multifractals, guide maps, custom fractals, etc).

Basic Perlin has been both simplified and had some very much needed improvements like output elevation controls (including an option to specify the typical slope of the output instead of the height range).

Advanced Perlin and Voronoi will in the future also receive a number of updates soon as all of the primitive devices get a once-over, but  that will have to wait until build 3017…

Roughness Selector

Saving the best for last, perhaps one of the most transformative features is the new Roughness Selector, which promises to almost certainly find its way into your texturing schemes.

The Roughness Selector is a natural, powerful complement to height, slope, and erosion mask-based texturing. In a nutshell, it does what it says : Produce a mask that indicates what areas of your terrain are rough, and what areas are smooth.

Roughness Selector Output

So simple, and yet — I’ve already found the Roughness Selector useful enough to rethink my entire basic texturing scheme, and I’m sure you will discover even more uses!

The Roughness Selector produces output that cannot be achieved by the Slope and/or Convexity Selector, as seen below. In this comparison, each selector is simply fed into a Colorizer to texture the terrain based upon its action. The roughness selector picks out rocky areas while leaving smooth meadows alone, even if they are steeply sloping.

Slope-based on top, Roughness-based on bottom


This seemingly simple device was actually much harder to tune than expected, as many of the methods you might think of to identify roughness (such as std deviation of elevation or slopes, for example), don’t produce aesthetically pleasing output or are too highly correlated with the terrain slope to be useful. The output mask can range from smooth to relatively “noisy”, which is actually very useful as the noise is correlated to terrain features and looks good, much like the erosion masks.

As hinted previously, one perfect use case is identifying areas of the terrain that contain rock vs soil. There are many natural locations that will have smooth but steep soil-mantled terrain right next to jagged rocky cliffs — we can now analyze our terrain for these and treat them differently.

Color by roughness — smooth hillsides interpreted as vegetation, rough hillsides as rock

This is pretty much as good as it gets right now, short of a full scale soil evolution model. Ahem. 😉

This is a masking/texturing primitive that I’ve always wanted to have available, so I’m very happy it is finally making an appearance. Individually or in concert with the existing selectors, you will find it a very powerful tool for texturing.


That’s it for now! Build 3016 should come out next week, and Build 3017 should follow along a little ways after that. Cheers