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:

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!