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.
-
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.
-
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.
-
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.
-
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.
-
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…
-
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.
-
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.
-
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.
-
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.
-
There appears to be no way, via the user-interface, anyways, to remove a macro that was added to the Macro Library.
-
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.
-
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?
I guess that rules out a simple lack of memory…