Just a quick update for what’s been happening here.
Build 3019 is available on the Release Channel as well as the Dev Channel. It is mostly similar to 3018 but contains a number of cleanups and bugfixes.. The full changelist is available on the Update Center. It is also now the version available to Basic Edition users, finally bringing all WM users up to date with the changes from the last couple years. No longer will Basic Edition customers be stuck running 2.3.7!
Speaking of which, the website has also been refreshed to be simpler, cleaner, and more modern, as it had gotten woefully out of date. A few things still need to be added back; Instead of hard-coding them, I’m hoping to introduce a Wiki to use for authoring documentation, which will help keep especially things like workflows to 3rd party applications up to date.
Finally, the installers for World Machine are now code-signed, eliminating the ominous “Unknown Publisher” warnings that Windows issued previously.
So, what’s next? Here’s what’s on tap for the immediate future:
The next build or two of World Machine will be focused mostly on cleaning up bugs and issues discovered in the latest builds.
Keep contributing your crash reports, as they are a major help in stamping out serious issues! I’m also looking at adding some small scale improvements sometime in the next build or two, such as:
Tweaks to how the Slope Selector functions
A new “Copy/Paste Device Settings” command, that lets you copy settings from one device to another while preserving the destinations network connections.
We’re looking at approximately an April time frame for the next feature release.
After some reflection, the approach that we’re going to follow this year is to group changes such that each major feature release (those that get a new codename) will be related in some way. This makes communication much easier than when the changes are scattered about to a dozen systems at a time.
I’m excited for what will be coming: Among other things, it involves some of the experimental work from 2016 finally reaching fruition. More to come on this as we get closer 🙂
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…
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’
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:
New Coastal Erosion Device
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.
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:
*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…
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.
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!
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 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:
General UI behavior and display
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
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.
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 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.
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…
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.
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.
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.
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
Build 3015 has been released! Besides fixing some bugs, and a few smaller tweaks, the primary focus is improving a device I’ve never been completely happy with: the Thermal Weathering device.
The old version of Thermal Weathering had its uses, particularly in concert with the erosion device to help shape the sometimes over-steep slopes produced. However it never fully achieved its primary goal: to simulate the way freeze/thaw cycles break down rock faces and produce talus slopes.
I’m happy to say that the new version excels at that task!
Let’s take a quick look. This is one of the example files included with Build 3015. Here’s a canyon-type terrain:
Right off the bat, we can see that this is not a situation where WM’s erosion model traditionally excels. None of the natural forces that would dominate in this situation are being simulated, leading to a result that doesn’t look realistic. Among the problems are the lack of debris at the base of the cliffs, unrealistic streamlines down the cliff faces, and more.
So let’s try to fix it, using classic World Machine 2 Thermal Weathering:
In some ways this is an improvement, but in others, a step backwards. Talus and other debris have begun accumulating on the slopes, but not in a consistent way or in a location that is actually where you would expect. This is due to a variety of reasons I won’t go into here, but the short version is that we still don’t get our talus slopes.
What’s worse, all of the nice erosional detail in the rocks that we created in the first world has been smoothed away. Sometimes this is desirable… but typically not.
So. Let’s take a look at the new version:
Hopefully you can see why I’m quite excited and proud of the new device. 🙂
Convincing talus slopes have been generated under the cliff faces. These slopes have a consistent (and controllable) angle of repose, as much volume as you want, and best of all not only preserve but even enhance the original erosion detail present.
The new device works great with or without traditional erosion. It’s also much more controllable than the old device (which was often a bit tweaky), has controllable mask inputs for both talus generation and talus sinks (where things like rivers can remove the talus), and, by the way, scales dramatically better than the old device in high resolution worlds — you’ll find some huge build time improvements.
In short, for most general purpose work, this device represents a giant leap forward, and finally deserves to be used on an equal basis with the regular erosion model. I’m excited that it’s now available, and look forward to hearing if you find it useful!
It’s been quite a long time since the last post here!
The latest development build (3014) of World Machine is available today, and that will be a whole topic of its own. Briefly, the two most notable and immediately useful new features are a major reworking of the River device to fully support multiple rivers and hierarchical river systems, and a usability improvement that lets you view the “before and after” of any device in the 3D View.
The next blog post will be about using the new modification to the River device.
But this post is about something else. The last post on this blog was about 14 months ago — what happened to 2016?
Seemingly a little, actually a lot, and many lessons learned the hard way.
The Bad, and What I Learned From It
Let’s face facts – I, more than anyone else, am painfully aware that I seem to have disappeared off the grid in 2016. This manifested in two main ways. First, there were no new releases in 2016. Second, I wasn’t active in the forums. To make matters worse, there was no public information as to why. Yeesh. I heard from a lot of folks via support tickets and emails during that time: some were concerned (are you ok?), some confused (does World Machine still exist?), some frustrated (dude, are you ignoring us?).
The short version: I’m OK (thankfully), World Machine absolutely still exists and is what I exclusively work on, and for that last part, I sincerely apologize, but am taking steps so that this sort of absence doesn’t happen again, starting with this blog post.
Everyone knows running a business is challenging, but what I didn’t expect is that it continually becomes challenging in new ways I wasn’t expecting. I started World Machine as a side project because I love mountains, computers, and the act of creation. Then I realized I had made something people could get a lot of use out of, and devoted myself entirely to running this business, quitting my corporate job. Since then, that’s been World Machine – me at my computer and lots of coffee, exploring how to make this software I love ever better. I created the forums with the vision of having a community of people all passionate about creating worlds, that could support and inspire each other, and enjoyed being a part of that same community myself. I looked forward to interacting with any customer that came along, happily answering questions, even if they were just teaching new users the features. It was fun and I could run the whole thing while still having plenty of time for big sprints of development.
But here’s what I never saw coming. All that was easily doable when there were a couple hundred users. But as World Machine continued to grow, the time devoted to handling the administrative and support side grew with it and sorely tested my ability to handle everything as a one-man shop. I’m amazed and grateful at the success World Machine has seen, but its success greatly reduced the time available for each part of the business – development, customer support, forum engagement, and generally keeping users updated (like the website and this blog). And those last two were the first things to drop.
I’ve finally realized this, and am looking to adapt to the new realities of World Machine’s growth. Here’s a breakdown of what I’ve learned and how things are changing.
Let’s go back to that first most obvious disappearance. After a long cadence of multiple releases per year, there were zero releases in 2016. This left anyone who had purchased a license upgrade expecting to receive, well, upgrades, likely quite upset, and understandably so. In an ideal world, I would aim for quarterly releases, but it’s not always that simple. For example, 2016 was a year with substantial time poured into speculative R&D projects, trying to do things that haven’t been done before. Some of that effort has yielded extremely promising early results; however, other efforts consumed month after month of work, ultimately never producing a viable product. To make matters worse, since much of that speculative R&D work was entangled with the changes to the River device, it impeded my ability to get any other features out that were production ready.
What I’ve learned and what’s changing
The first major business update is to make sure the upgrade policy is fair to everyone. Going forward, if World Machine does not release a new version within 12 months of purchasing your license upgrade, you’ll receive the next (Development) version once it is available, even if it’s beyond the 12-month upgrade timeline. Also, anyone who purchased a license upgrade between December 2015 and December 2016 has already automatically received all 2017 updates free of charge, not just Build 3014, just to say thanks for your patience and support last year. I can’t promise how often I can get new features in your hands, but I can promise that a 12-month license upgrade will actually provide at least one upgrade!
Next, I’ll be making additional efforts to keep the speculative R&D efforts on separate development branches so regular releases can still go forward despite stalled experimental progress. I’m also going to be better about splitting dev time more equally between near-term and long-term improvements. So if there’s a feature you’ve been wishing for, I’d love to hear what it is. I’ll be looking at the forum under the “New Feature Requests” topic to see where there might be things I can get into your hands more quickly.
Now let’s address the second part of my disappearance: no activity on the forums. This was very different than previous years, and made it seem like World Machine had been abandoned. While I was able to (mostly..) keep up with support tickets, emails, and other administrative requests, that plus development just flat out didn’t leave me time to nurture and provide support to the community that I longed to create and be a part of.
Despite my desire to help every customer with questions, it really is too much for one person. So for the first time, I’m looking to bring on some help with the creation of a part-time position: Community Liaison. If you’re already a pro at World Machine and are looking to help people out and bring in some extra income, shoot me an email at email@example.com. My vision would be for this person to help run the forums and a few other points of customer contact, answer questions and brief me on how things are going there, as well as to help keep lines of communication up during long development pushes on my part. Hopefully, this will help keep the community informed and help me more efficiently wade through that data.
The Good, And What I’m Really Excited About
Not all of the R&D efforts were futile. I’ve developed some incredibly promising new functionality, but haven’t ironed out all the issues yet. This is what’s both so exhilarating but also demoralizing with new possibilities – there’s no clear path to follow to make it work the way you envision it.
But regardless of big and exciting new developments, I’m committed to working on the easier, smaller features as well. That way, even as I pursue what sometimes seems like rabbit hole after rabbit hole.. only to find zero rabbits, there are still upgrades to be shared.
To give you a little taste of what I’ve been so excited about that I spent months of 2016 pursuing it, here’s a basic World Machine world transformed by the application of some of the new devices:
So. although 2016 was a rough year for World Machine progress, 2017 will get to enjoy the fruits of that labor. And that’s a great thing.
I mentioned in the last post that there are several improvements to Erosion coming, including a hardness input.
But that’s not the only improvement..
The mask input on Erosion previously did a simple alpha-blend between the results and the input. This is.. adequate. One consequence is that the mask is not actually used to guide the erosion itself, ie the masked area doesn’t “sit” well against the rest of the eroded terrain.
Under the next version, the Mask input is an “active” mask. That is, it actually participates in the erosion process:
Fully masked areas will be completely unaffected, as with previous.
Areas outside the mask will now be eroded accounting for the masked area. This is probably what you figured it should do in the first place 🙂 The difference is hard to describe, but profound; for example, a masked area in a low basin that would previously have been filled quickly with sediment will instead stay unfilled, acting as a “sediment sink” for surrounding areas.
Areas that are completely masked will no longer generate any waterflow. This means that masked erosion will be much faster. Fully masked-off areas take relatively negligible time to process.
The main thing that prompted this change was to make terrain with rivers work better with erosion. Now you can simply take the river channel mask, pipe it (inverted) into the erosion mask, and boom!
The river now “sits” much nicer into an eroded terrain. As a nice bonus, the hero-river systems will effectively transport away sediment for the hillslope erosion, just like in real life…
In the last picture above, you can see the effect of the river transporting sediment; the surrounding valley becomes steeply carved with gullies as the river effectively participates in the erosion process! Not bad for a simple mask input 😉
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
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.
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:
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…
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.
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.
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:
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 😉
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…
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.
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.
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.
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.
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.
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:
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:
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:
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.
News, Ideas, and Random Musings by the author of World Machine