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.

The latest 'Behind the Scenes' news from Stephen, the author of World Machine