To See the Wizard

This post has nothing to do strictly with Pro Edition. It does, however, have alot to do with the Standard and Basic editions that will come out following Pro.

One common problem when people first pick up WM is that, frankly, they’re not quite sure what to do. Some people learn by the “Columbus Method” — they just start clicking and exploring their way through the software until they’re proficient. I learn this way, and I know a lot of people who also do — but there’s also quite a few people who can’t or won’t do this. Maybe they don’t have the time to learn mastery over an app, or maybe they just don’t learn that way.

Whatever the case may be, newbies to WM often end up rather lost.
One possible partial solution to the problem that I’ve been thinking about over the last few days is implementing a New Terrain Wizard. Now, let me first say that I’ve never been a fan of Wizards in the apps I use. They are linear, constricting, and to me feel like they are just “handholding” you through a dumbed-down process.

With that said, I can see ways in which a new Terrain Wizard could guide a newbie through the rough terrain creation process. Imagine the following wizard steps scenario when a new user opens the program and wants to create a terran:

How would you like your terrain to be distributed?

  • Endless terrain everywhere
  • Islands in the Ocean
  • Continents
  • (I’ll handle my own distribution)

What kind of dominant terrain would you like to create?

  • Mountains
  • Buttes and Mesas
  • Desert Dunes
  • (I’ll handle my own terrain shapes)

What kind of overall erosional effects you would like?

  • No erosion
  • Lightly eroded
  • Heavily eroded

How would you like to output the terrain?

  • Use a Heightfield
  • Use a 3D Mesh
  • Use both
  • (Checkbox) Output a normal map for this terrain

Obviously this wizard could never account for all the types of terrain that people might want, or that could be envisioned. However, it gives people a starting point that is going to be hopefully not terribly far off from what they want. If each main “step” of the wizard is eperated into its own functional block (see last blog entry) to keep things organized, I think it might even be quite helpful as a learning tool for newbies to see how things are hooked together to do something.

And after a user gets proficient enough to find the wizard lacking, they’re probably proficient enough to be able to make their own terrains from scratch.

Anyways, this isn’t any kind of guarenteed feature, but the more I think about it the more I like it. What do you guys think?

UI Enhancements

Although I’m leaving most UI changes till later, there are some that are simple yet surprisingly powerful.

For example, Functional Blocks (Groups):

The screenshot above is just from the rough implementation — blocks also are allowed to have text inside them, so that you can commentate on different sections of the network.
It seems stupid, but the ability to draw boxes around groups of devices to denote what “goes with” is shockingly helpful in understanding how a graph functions! This has been an idea to implement since the 0.99 days, but if I’d realized how cool it was earlier it would have gone in long ago.


Between broader design issues, I’ve been finishing off bits and pieces of different functionality; specifically adding RGB import support to the tiled File Input device (its already inside the regular FI device), finishing off the Coverage Device, adding a couple new shapes to layout mode, and some other small changes.

User-interface issues are something that I spend a lot of time on; although World Machine can be sometimes confusing to a novice because of the graph-based interface, I’ve put a great deal of time and effort into making it streamlined to use once you understand the principles. For all of the new functionality being implemented I want a similar elegance; this takes up alot of time futzing around trying out different interface possibilities.
On the plus side, I can “back load” alot of these issues towards the beta test rather than the alpha; The focus in alpha is just to get the functionality there, no matter if its the most easy to use. Once its in, its alot easier to play around with different interfaces.

Stupid RGB tricks

Note: The below is all just for fun. But it does make me realize that there are probably going to be some indie developers, in particular, that might want to just use WM to make all the textures for their terrain, period.

It’s pretty sweet looking, actually, which is totally unexpected. The network to produce the image above is just a basic eroded perlin, overlayed with an RGB network. The net consists of an imported rough texture tiled across worldspace,  with color adjustments made according to the erosional masks.


Local Heightfield space and RGB bitmaps

With the major features of tiling and layout mode beginning to undergo testing, I’m turning now to a couple areas that haven’t recieved much attention.

The File Input device is getting a bit of a makeover, so that it operates more similarily to the tiled file input device. It now also supports RGB input (although only through the TGA and BMP formats so far; eventually more will come).

As an aside,
Although I certainly have no plans to turn WM into a general purpose image manipulation program, the fact is that WM supports HDR RGB data and I/O, a simple interface, and a freely available plugin kit; it would be pretty easy to make a set of devices to allow you to use WM as a high-dynamic-range image adjustment toolkit.
I view this fact as very cool; the WM paradigm applied to more than just terrain as it were.

More to the point, what this brings to my mind is something I want to do for Pro, which is to allow some devices to operate on heightfields or bitmaps (or anything) that does NOT correspond to the general world that has been strongly defined by WM.

In other words. When you import a bitmap image that is 653×542 pixels, you can certainly map it into worldspace and deal with it there.. but you should ALSO be able to take that image and treat it as an isolated piece of data; make no attempt to rescale it to fit the world size specified, etc.

Why would you possibly want this?

I can think of several different reasons to do this. Let’s say you have an artist who has sculpted a couple really nice looking shapes. We could use this ability and the new “placement” device to load in that shape, and then scatter it into world space randomly.
Or plenty of other things. I’m not precisely sure how I want things to work along this line; it’s uncharted terrain for WM yet again so I have to feel my way and see what seems right or wrong about implementing it. We’ll see if it makes the actual WM Pro.

The Tiled File Input device is complete.

Lots of little tricky cases had to be tracked down and accounted for, but its now working the way I envisioned it, and its quite nice to have!

A little more detail: It now manages a multiresolution tile cache on the fly. Depending on the amount of memory you specify for the TFI device to set aside as a cache, certain resolution versions of the tile data are kept at all times in memory so that the entire tilespan can be very quickly imaged at coarse resolutions (such as when in explorer mode, layout mode, or zoomed out a long ways) without having to go to disk. The rest of the cache space is kept for if higher or full-res data is needed from a tile, such as when you zoom in to full detail level across a small area of a large highly detailed tileset. The end result is (after a somewhat length and optional pre-caching of the tiles), you can manage/view/explore the high detail tilesets with very little slowdown.

It’s pretty awesome to be able to pull in that 1.5GB dataset that I mentioned earlier, and then explore/modify it in realtime!

The only remaining issue with the TFI device is how best to handle caching multiple devices loading the same file stream. This actually occurs pretty often; Layout and Explorer modes spawn threads that actually work on copies of the devices to prevent cross-thread pollution of the data. This is fine for normal devices, but for devices that might have up to 400MB of data associated with them — this is undesirable. We’ll see if it ends up being a big enough issue to work around or not.

Things are just about ready for the first alpha of the tiled functionality and the layout mode. Tiled processing is very very close to finish polish level, but layout mode is just in the very opening stages. I expect that it will change and gain new features many times throughout the alpha and then the beta testing.

Odds and Ends

It’s always amazing to me to realize just how much the 80/20 rule applies to software development. 80% of the code takes 20% of the time; 20% of the code takes 80%. Spent most of this week fiddling with performance issues, bugs and other development gremlins.

The Tiled File Input device now has a basic multi-resolution cache; More work needs to be done to get the performance to where it should be on very large datasets though. Right now, as soon as you actually NEED the cache, the performance will start to degrade somewhat severely.

The Spline Path tool in Layout mode is also giving some issues. It comes down to how in the heck I want to rasterize a spline path with falloff anyways. The current method is quite possibly the slowest I can envision, performing root-finding for every pixel to determine distance to the spline path. Needs to be improved on.
Lots of other tweaks happening too, all aimed at hopefully having the first testing by the alpha team begin prompty.

Inching towards Big Things

The Tiled File Input Device is pretty much done now. All that remains is adding the multiresolution cache, which will be a big help for huge datasets but is not strictly necessary. Speaking of which…
I just got done building a 1.6GB dataset for testing tiled input/output. Clocking in at around 5.5hrs of build time on my Athlon64 3000, it’s a good test for both the tiled output and input systems. Spanning a region from the “Explore 3 – Nice World” tmd file, it consists of a seamless 20×20 tileset of 1024×1024 tiles (that’s 20,480 x 20,480 if you’re counting). Note that to facilitate inter-tile blending the actual temporary dataset on disk sits needed up to 2GB (each tile is built at a higher resolution of 1250×1250 across a larger geometric region and then blended across the shared region).

Getting very close to the first alpha test release. I’m going to backload alot of the remaining work in order to get the first Alpha version out ASAP. Mostly to be able to get feedback about the tiled system / multithreading / layout mode of Pro. Everything besides those is pretty much still in progress, but the feedback and bugs can start on those already. 🙂

Layout mode in particular is going to need a lot of feedback and refinement, as it is an entirely different and extremely powerful direction; but with that potential lies the necessity of alot of streamlining/UI work/thought to make sure that it works as well as it should.

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