Sketch Shapes

A few things:

As far as new functionality goes, I’ve finished implementing the Mesh Output device. Currently it does NOT create optimized meshes, although that is planned. Even so, combining a lower-tri count mesh with a generated normalmap for the terrain can produce the appearance of quite a high detailed terrain if your engine supports such things.

The bulk of the time has been spent working on Layout-related things. The Alpha1 release had a rather rudimentary UI that was really intended only to expose the functionality that needed to be exposed. That UI has now been refined to what will probably be it’s end state. The new Layout UI is (in my opinion) the best of both worlds, giving you a simple, uncluttered view to work in… when we hit Beta I’ll start releasing UI screenshots, but until then you’ll have to take my word for it. 🙂

I’ve added two new Shape tools that will be in Alpha-2. The Sketch Poly and Sketch Line tools. As their name implies, all you do is draw with the mouse to define enclosed shapes/paths. These are damn cool! They certain give you a lot of the “painterly feel” to creating terrain shapes and masks without storing anything but vector data. In addition, it’s quite nice to be able to make a shape and then tweak the vertices so that it looks just right.

There’s lots of layout-related stuff left to do this week and next, but hopefully Alpha-2 will be released at the end of that. I’m informally targeting the “85-90% completed” mark for the end of the Alphas and the beginning of the larger Beta test.

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.

Miscellany

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.

Fun!

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.

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