A List of Issues and Suggestions

Hello,

During my playing around with World Machine 2, I’ve noticed some issues and thought of some improvements that I will describe here. First of all, my basic specs:

Intel Core2Quad Q6700 (2.66 GHz)
4 GBs of physical ram
Windows Vista x64

I’m using WM2 Pro, 64 bit with the thread count set to 4, one for each core.

  1. When performing tile builds, the program attempts to build one tile per thread. This is troublesome if you are attempting a very large tile resolution build, as the program will attempt to build the maximum number of tiles it can with the threads available, even if it couldn’t possibly have enough memory available. This quickly leads to an unresponsive system and, eventually, an out of memory error. It should be possible to estimate memory usage needed to build a tile, and if it is incapable of allocating enough memory, the free thread will assist another thread in building it’s tile until enough memory becomes available. Right now, the only work around is to decrease the number of threads to prevent World Machine from biting off more than it can chew, but then I am not utilizing the full potential of my CPU.

  2. Macros seem to need to be rebuilt even though no devices before them had been changed. This could be due to the way I hook them up. Many of my macros have parameter ports that are hooked up to a network of Scalar Generators and scalar manipulation devices, but these scalars all remain the same, so the macro should not require rebuilding.

  3. It would be nice if the Slope Selector device could have textbox read-outs in degrees instead of a 0 to 1 scalar. Makes it a tad more difficult to get the exact slope you need when you constantly have to go typing away on a calculator to figure out what 78 degrees is normalized to a value between 0 and 1.

  4. As mentioned elsewhere, when you input a number into a textbox that is associated with a slider or other scalar manipulation interface element, the number does not take effect. It seems wholly dependant on the value that the slider is reporting instead of the number typed into it’s textbox.

  5. The Blur Filter device seems to have some sort of fit when it’s blur setting is too high. The higher the setting, the longer the device takes to begin working. This just seems odd…

  6. Builds don’t seem to stop very promptly when they are canceled. It seems alot like all threads must finish their current task before the process is canceled. A faster way to cancel would be nice, instead of having to kill World Machine and reload to get out of a device that would take 10 minutes to complete.

  7. The Curve Device would be loads more useful if you could use a spline fit system to generate the curves. Drawing the curve just doesn’t have the accuracy required.

  8. Being able to determine the altitudes that the Height Splitter device splits heights would be more useful then just splitting them in a linear fashion based on the number of bands.

  9. In devices that require a choice, such as the Multi-Chooser, if a scalar is passed to the device as the Input Choice Parameter, the last choice is only selected when the scalar is set to 1.0 exactly. I would have thought that, in the case of there being 2 choices, choice 1 will be selected when the scalar is between 0.0 and <0.5, and choice 2 selected when between 0.5 and 1.0. Instead, the way it works is choice 1 is selected between 0.0 and <1.0, and choice 2 must be exactly 1.0 to be selected. This behavior, however, DOES have it’s uses, and should be left in, perhaps as an option.

  10. There appears to be no way, via the user-interface, anyways, to remove a macro that was added to the Macro Library.

  11. In one of my more complex machines, encompassing 50 or more devices and several macros, the build process seems to glitch. Several devices that require building are skipped, and despite having a lack of required input data, macros will still attempt to proceed, halting midway. It takes several cycles of hitting the build button to finally get the machine to build completely. I can provide the file where this glitch occurs most often if requested. What exactly causes the machine to glitch isn’t currently known to me at the moment.

  12. One final and miniscule item, not so much an issue, but a feature request. Currently, the only units available for use is kilometers and world machine units. It would be very useful to some people, especially those involved in game modding or development, to be able to specify their own units of measure with reference to meters (70.18 Game Units per meter, for instance), and have the capability to switch between them quickly, giving them a better sense of how the world will be perceived by the game engine without having to resort to a calculator.

I suppose thats all my thoughts at the moment. I will add more as I encounter them. Overall, this program has been the best terrain generator I’ve ever worked with. Such power and control. The capability to get the terrain to perform exactly as wanted and needed. The interface design and layout is a testament to full featured user-friendly functionality. Nothing appeared to be sacrificed to make it easier to use, yet it’s design and execution provide a friendly and easy to use interface, even when dealing with complicated and advanced features. Any feature that does end up throwing you for a loop is clearly documented to describe it’s functionality. All this proves that something can be user-friendly without limiting access to functionality, something I’ve allways believed in and strived for in the programs I’ve created.

By providing this list, I hope to provide feedback that will further improve it’s usability and efficiency.

… Speaking of which…

My license DOES grant me access to minor version revisions to World Machine 2, right?

Hi there,

Excellent set of suggestions. Some further replies below:

  1. It’s actually more of an art than a science to predict memory consumption of a network at the moment. However, your point about a simultaneous tile limit is well taken.

  2. I’ll take a look at this issue.

  3. Which devices have you run into this on? The generic-dialog-devices (ie Voronoi noise, snow device, etc etc) shouldn’t suffer from this, although some of the custom dialogs may still.

  4. A large blur radius takes longer to process – I believe the progress reporting on the blur device may be a bit “off”, however it is fully working even when it says 0%. :slight_smile:

  5. Right now you can only cancel once the device being processed is finished, which for slow devices like erosion will take ages. This is not a difficult thing to fix, it just involves making all of the slowest devices check for cancellation during processing. It will probably be done in the first WM2 service pack.

  6. I’m very interested in this bug. Can you send an example world that exhibits this to support@world-machine.com?

Yes, bug fixes and minor-version enhancements are free upgrades for purchasers of WM2!

Thanks for the praise for WM – It’s always great to hear! And I’m always listening for ways to make WM better.

I’ll keep track of devices that exhibit this behavior from now on and provide updates to this thread as my list becomes more complete. At the moment, I can only say for sure the Slope Selector has this problem.

Done. I was also able to figure out how to reproduce the error. Instructions included in the email.

Finally, one more thing I’ve discovered. Alot of the terrain I build is flat in appearance. This is because when I’m building worlds, I keep the terrain altitude scaling at it’s maximum. This is because its the only way to reliably produce terrain maps with altitudes that scale properly with the game I wish to import maps into. Because terrain that can reach 10667 meters in altitude is ussually too sharp to traverse, I clamp the terrain down to around 1 to 3 km leaving alot of unused altitude, depending on the size of the world I am producing.

Anyways, I noticed an interesting behavior involving the erosion device and it’s multi-threading capability while working with such “flat” worlds. The more unused altitude there is, the less efficient the device works. When building the world with a maximum height of around 1km, the erosion device starts off strong, but then it’s CPU utilization tapers off, sometimes down to around 37% of my available CPU power. It does state that all 4 threads are working, but each CPU seems to only be using a fraction of it’s power.

I can probably come up with a work around, like design the world at a more suitable altitude scale, then maximize the scale and clamp the terrain to restore it to proper scaling when I’m ready to export a heightmap (really, I should have done it this way anyways). However, I thought I would mention it in case this isn’t a behavior that was anticipated or desired.

On that terrain height and operator behaviour point, i’ve made liberal use of normalize(clamp)->operator->reclamp, especially for coastal erosion.

I’ve come across another machine that fails during a tiled build. The program just outrightly crashes. Haven’t found the exact reason why its failing. It can complete the first 4 of 16 2048x2048 sized tiles before it crashes. I thought at first it may have been a memory problem, but it does it with 64 1024x1024 tiles as well. Let me know if you wish to get a copy of the machine.

hmm. I’m assuming that the disk that WM is installed on has plenty of space left on it for temporary files?

If this is a repeatable crash, I’m very interested in seeing the world that causes it.

Just a little follow up on the last crash I mentioned (I sent you the world file for it), I thought it might have been a lack of memory, as I was really pushing the limits of my system (most/all of the background programs were shoved into page file during the build). I would like to say that it wasn’t the case, as I have since doubled the amount of RAM in my system allowing ample space for the program. Still crashes at the same spot, but it gets to the crashing point a whole lot faster. :wink: I guess that rules out a simple lack of memory…

But, with the extended amount of RAM, I can do a non-tiled 8192x8192 build now. Its slow during the erosion device (33% utilization of total CPU power), possibly because I’m having to use the conserve memory option, but it works.

By the way, while I’m on the subject: What exactly does “Conserve Memory” do…? It says in the documentation it causes World Machine to discard final heightmaps after they’re no longer needed, but wouldn’t you store those on the hard disk until they’re requested for viewing by the user? Why keep them in system memory? Or are you using the term ‘memory’ as an all-encompassing term for any data store on a computer, including system RAM and the disk drive?

Just wondering if using this option is even useful to me.