Feature Branch #1

I mentioned the other day that I would be posting more information about development direction soon. That post is still yet to come, but I thought I would start talking about what kind of features are being worked on for inclusion within World Machine in the relatively immediate future.

So here’s the first in the series!

Different Resolution Support

The current feature-in-development is the ability to have different sections of the device graph operate at different resolutions in the same world file. How does it work?

The basic rule of thumb is that you can set any device to operate at a fraction or multiple of the resolution set in the world file; That section of the graph will then flow at the new resolution until encountering device(s) that change the resolution again. If two different resolutions meet at a device, the lower-res one is upscaled to match the higher one. This allows existing devices to more or less ‘just work’ without requiring me to change anything.

Why would you want this?

This is very powerful and handy; you can do anything ranging from simply setting the resolution of your outputs independently (for example, for your heights vs normal maps vs bitmaps), all the way to having lots of different effects that are processed at different resolutions. For example, your high-resolution builds could run with most of the world-building done at a more modest resolution, then upsampling right before final detailing and output, saving lots of memory and time.

Resampling

Of course, having different resolutions all over the place requires improved support for re-sampling the resolutions of heightfields when needed. WM has always just done bilinear interpolation when required, which is the bare minimum but leaves a lot to be desired. I’ve just finished adding support for new resampling abilities, as seen in the graphic below.

Upsampling from a 64×64 source to a 512×512 heightfield in WM:

webimages

These will be the resampling filters implemented in the next feature release. Let’s go through them:

  1. Nearest Neighbor: This is not too useful for heightfields except if you’re going for a minecraft-look. However, this can be very useful for bitmaps as a method when dealing with material maps/atlases where each color actually is a code for a particular type of coverage; In this case blending doesn’t make any sense.
  2. Bilinear is what we’re used to. When applied to heightfields lots of creasing artifacts are in evidence, although in some cases this sharp look is very useful.
  3. Bicubic: (Soft) uses an approximating B-spline to create a smooth, C2 continuous surface. This is a great choice when you need to produce a very smooth output terrain, and will probably be the new default choice.
  4. Bicubic (Tuneable): This choice provides you with a “sharpness” tuning parameter, which ranges from the same as Cubic-Soft to quite sharp. This is immensely useful for images as well as heightmaps… As a ‘season-to-taste’ parameter, the correct value is according to your artistic judgement. For fellow math geeks, these are the Mitchell-Netravali spline family.
  5. Fractal: This adds fractal detail to the interpolated surface adding rougher details in high-variance areas. This is a simple and basic way to add some detail to a low-resolution input, and is easier than manually setting up the equivalent network in World Machine itself. It is tuned with a single roughness parameter. High roughness is also useful for things like material maps, which tend to get too blurry when upsampled from low resolutions. I’m still fine-tuning the algorithm here for best results, but the intention is to be a fast’n’easy solution, not the ultimate fractal upsizer; The Advanced Perlin device is the best bet for that, especially with some tweaks being made to improve the ability to quickly setup that device for detail-adding.
  6. I can’t resist a final image of the fractal resample with some erosion and texturing added!

I also experimented with some other ‘designer’ resampling kernels like Lanczos, but decided that they didn’t bring anything to the table that wasn’t already covered by the above.

All of these will be presented as options both for resampling within WM, and when importing from a regular or tiled file input.

What’s left to do

A fair bit:

The major work remaining on resolution/resampling support lies with the User Interface. The workview should mark all devices that are at non-default resolutions so that you can at-a-glance see where your custom settings are. Ideally the controls for setting the resolution (as well as a few other things as I will detail in upcoming posts) would reside directly within the dialog box for the device, but due to framework issues this is a mammoth task what with all of the custom device dialogs in WM. Instead, these are currently accessed through the right click context menu.

In addition, all of the various views and features (layout view / tiled builds / etc) that expected consistent resolutions will need to be modified to work within the new system.

Finally, the file inputs need to be modified to provide the additional options.

Final Thoughts

The update containing this ability should become available within the next month. I picked this as the first new post-2.3 feature to add as it is both highly requested and doesn’t require extensive R&D to implement. Have other things you’d like to see? Post about them on the forums!

 

The Taste of Progress

Yesterday I released 2.3.3, which marks the third revision to WM since the 2.3 release… which itself occurred only 2 months ago. 

I’m very satisfied with the new pace of progress! There are many reasons for it, a few of which I will detail below. But more than anything else, this characterizes how I really would like to develop World Machine — relatively frequent releases that bring new abilities and fix issues.

I’ve always been frustrated by the lengthy and slow release cycle that WM suffered from before. It’s not good for anyone to have the fixes for issues languishing for months or years(!) while the product is still in a beta phase before release. I think that 2.3 marked the end of the traditional development model for WM — more details to come.

The next section talks a little bit about what I’ve been able to change post-2.3 to make development faster. 

Development Details:

What did I change to be able to iterate versions much quicker? A few things:

  1. I changed to Mercurial for source control. The ability to branch and merge effortlessly has allowed me to keep feature and release branches seperate, something that was always far tougher than it should have been using the old style SVN (or nothing!).
  2. I automated much of the build process, so that kicking out a new version to the website takes maybe a half hour rather than most of a day.

Not a lot of differences, but enough to remove the friction from the process and make it easy to get changes out rapidly.

World Machine 2.3 Released

Its time!

World Machine 2.3 Final is now released. 2.3 is now available on the upgrade site at http://update.world-machine.com.

There are some seriously awesome improvements and compelling new features, not to mention a whole slew of bugfixes.

On the flip side, perhaps sometime soon I will post a postmortem on 2.3 — on the whole it took far, far too long to get it put out the door. The extended development cycle was hard on me, and hard on the users waiting for bug fixes! I continually forgot that new users not part of the public beta were using a version (2.2) that was out of date and contained bugs that I fixed long ago.

One of my goals moving forward is to change to a far more frequent release cycle; bugfix releases should come as fixes happen, perhaps monthly; the plan for large feature releases deserves its own post and will get it.

In any case  I mentioned earlier, there will definitely be time for reflection soon. But for now, I hope you enjoy the changes: The very-soon-to-be-updated website has an extensive list of them. It really is not hyperbole at all to say that some of them will quite change how you create your World Machine worlds.

 

 

Improving Real World Data

I wanted to talk briefly about a very popular but often unmentioned use of World Machine: Taking low resolution real world DEM files and creating something with more detail suitable for use in art or simulation.

This is one of the areas that I think could definitely use a tutorial! For an example of the power of the transformation, here’s a quick look at a before and after of a low-resolution DEM of an area of Washington state in the USA:

Before and After

 

Click on the above to blow it up. Specifically, note how we’ve carefully added artificial detail that complements the quite coarse real-world data we have to work with. Hopefully I will get a chance to make a walkthrough soon.. but here’s the network for the world above:

transforming-real-world-data2

World Machine 2.3 Ready for Christmas?

Hi folks,

Just wanted to mention that code changes are essentially complete for 2.3. I was originally hoping to have it released by Christmas time, but it looks like it will slip that a little bit.

Mostly, because I am trying to include some additional resources such as new macros and example files. Many of these reflect common questions or scenarios addressed on the forums over the years, so I figure it makes sense to make these available to everyone included in the default distribution.

For example, here’s an image from a newly included example file demonstrating how to create a volcano:

volcano

The example above demonstrates how to place a single “hero” mountain onto the terrain, as well as punching a crater into the top of it and simulating lava flow with the snow device.

Merry Christmas to all!

June Update

So, what’s been percolating behind the scenes in the past while with World Machine?

Mostly things like bugfixing, business-side, and other custom work. I believe that 2.3 Beta-3 is starting to achieve very solid status; there are only a few more things I want to get into line before final release.

I’m writing here, however, about a new feature. Even though I’ve sworn to myself to feature-freeze 2.3, I find that the allure of working on a few small things from the feature-request backlog sometimes gets to be too much. Which explains the reason for this post…

Take a look at this screen capture straight out of World Machine:

There’s nothing obviously strange about this image, but it’s showing off a couple very cool new features that, despite being small, will revolutionize the way people texture with World Machine.

In particular, this image is using the new Colorizer tool to create custom textures. The existing Colorizer was only ever meant to simply allow you to use the built-in colortables in your texturing schemes. That can be useful, but is of only limited power.

The new colorizer allows you to quickly create custom RGB gradients. But far from simply using them as a height-color lookup table, in my experiments so far I’ve found them to be indispensible for practically every texturing purpose. Any time you want to vary color based on a heightfield, the new colorizer is now your go-to tool. Whether that means a gradient based on height, slope, erosion status, or practically anything else — being able to quickly map your input to a custom set of colors is huge.

In particular, in the image above I created a rough grassy pattern using a couple noise devices, then drove a colorizer with it to get a nice mottled grasslands color set. I did the same thing for the dirty areas, then Choose between the two based on slope/erosion data.

One other last interesting trick:  You may notice there’s alot of “rough” feel to the surface; I plugged a small collection of nodes together to effectively combine the texture with a surface texture heightmap and bake the resulting light+bump map into the surface texture. This is a cheap, but fun, hack.

 

To Crash, or not to Crash..

Hi folks,

I just realized that its been a while since I last posted here, so I figured I had best make an  update!

There’s been lots of work being done but not much visible progress lately. Partially this is because I’ve been doing a fair bit of work not directly related to the main  World Machine codebase  lately. However, more important is the fact that I’ve been doing lots of work in the last few months or so in improving the error handling of World Machine.

WM never really has handled error conditions particularly well; your answer to asking to do something beyond its capabilities was almost always a crash. The crash reporting handler in the last beta was the first step in refining things. For this next beta, enormous amounts of work have been put in to make World Machine maintain stability, recover gracefully, and inform you properly when things don’t go according to plan. This is particularly true of memory handling; My goal for the next beta is that you will be unable to make WM crash no matter what you ask of it! (Whether this is achieved will remain to be seen..)

Happy Holidays

Hi folks,

It’s been a while so figured I should write a little update! I hope all of you are having a great holiday. Things have been extremely hectic here both personally and professionally over the winter to date so I’ve been pretty bad at keeping up with my correspondence — if you’ve emailed me and not received a response yet, my apologies.

There are some interesting changes coming down the pipe in the next 2.3 Beta due to some contracted changes requested by a customer that will be shared to everyone. More about that in the next post. But for now I just wanted to get a shout out that I am alive and wish you all the best this season!

 

 

Texturing w/ Roads

Hi guys,

Just wanted to post this image which I thought demonstrated a use of mask outputs that I haven’t seen much of yet.

I’ve created a basic terrain, eroded and then placed a road into the terrain via a spline path.

What’s interesting, is that I’ve then looked at the terrain before and after the road insertion to determine the areas that have been cut, and the areas filled, and then textured them appropriately:

Capturing cuts and fills

What struck me how simple this information was to extract from the WM network, but how bloody useful it is to anyone doing paths on terrains!

 

News, Ideas, and Random Musings by the author of World Machine