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