It’s high time to provide an update to the blog. Life has been busy lately, and I’m currently recovering from a nasty week-long bout with the flu (perhaps swine flu?).
So.. what’s been going on behind the scenes with World Machine?
Quite a bit, actually! I’m continuing to track down all manner of bugs large and small that get emailed to me. The bug fixes are very important, and are a reason that I’m having to continually force myself to scale down other enhancements so that the necessary bugfixes can get released sooner. Part of the problem here has to do with my workflow for a new release, which can only be described as “painful”. This makes me try to minimize the number of new builds pushed out to the end user, which is actually counter to what I desire.
So what are these new features that are occupying some of my time? On the completed list, there are three or four that are definitely worth mentioning here:
- Memory Paging. World Machine now has its own paging mechanism for packets, which allows for dramatically better results creating high-resolution files. You can specify a percentage of physical memory that you want to allow WM to allocate into; one of the prime goals here is to have WM take care of paging out things to disk more intelligently than window’s VM system can. What’s the takeaway? : You should get far fewer out of memory conditions. WM will bring data to and from disk and memory as requested, seamlessly allowing you to retain build results across the device network even for massive sized builds.
- Threading Improvements. This works in concert with the above to better manage memory demands when multithreading a build. You can now specify a limit on the number of independent build threads in progress at once; in tiled mode, this will be the number of tiles building at a time, in normal mode this will be the number of devices at a time. Any available threads above this will be opportunistically put to work within the devices themselves as possible. This removes a common issue where massive-cored tiled builds (8+) easily will run you out of memory.
- Session Files. A logical extension of the first point mentioned here, Sesssion files allow you to save the output state of ALL of the devices in your World Machine world file and restore it when you next open the TMD file. Note that obviously with high res builds, these session files will be VERY large (4-8GB is quite possible), and so this is not a fast operation.. But it means that you can now work on a project, save your session, then restore it on another day and pick up where you left off without having to do a very lengthy rebuild.
- Workview Improvements. WM now supports routing points in the device network. A routing point allows you to manually direct where the wire between two devices will go; this allows you to organize your device network far better than was possible before, elimining quite a bit of the “wires all over the place” clutter. To go along with this are a host of improvements to the fluidity and feedback of the device workview to make it easier to work with.
There are other improvements as well, such as new operators for RGB datatypes, and more devices supporting internal threading to speed up builds even further. There are a variety of other changes that are getting considerable amounts of time but that so far haven’t produced any fruit.
But with all that said, the most important goal right now is to get v2.2 out to the people soon. With that in mind, I’m going to be opening beta testing to the v2.2 candidates soon; you should email me if you’re interested.
Cheers!
8 replies on “What’s in for WM 2.2”
Waiting to get my hands on this… ;). Great News!
what about mesh + displace map feature?
Mesh features are one of the biggest things I’d like to see improved in WM, along with greater support for RGB textures.
However, adding fully-fledged mesh abilities brings with it a host of tangential issues; not so much for normal build modes, but for tiled onces, that are not obvious in their resolution. Just for example, edge-blending two meshes (optimized or not) is not a trivial task; the current implement skirts this issue by not letting meshes exist prior to the actual output to disk, but if meshes were routed through the network then this would need to happen. It’s a can of worms that I’m not sure if its wise to open right now.
Any news about the “mask input” fix…i doesn`t seem to work at all on any of the filters,etc…or sometimes works in some strange ways
The mask input bug is fixed.
Great! 🙂
Here`s my 100 + wishlist for next ver:
just kidding 😀
p.s:actualy a seamless tile build could be cool 😉
Great news! Obviously I’m still interested in alpha and beta testing 🙂
monks
I am a student in China.Can you tell me how do you do Terrain Texture for a Terrain generated by WM.Does the Terrain texture use color texture?How do you make the terrain texture that display in your web?It is so reality!