• Welcome to World Machine Community. Please login or sign up.
October 16, 2019, 07:32:46 am


Read the Development Diary for an inside look at World Machine's progress!

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mattnava

World Machine is a brilliant program. I think that it's core structure and approach is the most forward thinking of all the terrain apps out there. But the UI is outdated, and is holding it back.

I think it's time to modernize the program with a complete overhaul of World Machine's UI.

It's clear that the interface was started a time long ago and was continuously modified. The result is a UI with elements from different eras of development all slammed together. Just from looking at it, you can see that as new features came online their UIs were done in slightly different ways. For example, there are many kinds fonts that don't visually go together-- they are different sizes, some are anti-aliased, some are bold, etc, without a seeming hierarchy. Most importantly, the way that you interact with the same kind of UI in different parts of the program is inconsistent. There are some sliders that allow you type in a number and some that don't; some that allow higher levels of granularity when sliding than others. Some things require a double-click on to open their property windows; some things require that you select them and then hit a button on the sidebar to open their property windows. There's a whole lot of similar issues across the board.

The UI lacks a clear, consistent direction for its visual hierarchy and user interactions.

The UI is functional but it is unfocused. It's may have started with a clear design but after accumulating so many elements it's direction has become unclear. This makes it both non-intuitive for new users and frustrating for pros. The lack of an intentionally designed visual hierarchy, the breadth of organizational ideas, and the non-unified UI interactions make it hard to predict where to go to find what you want and how to interact with it. A large part of mastering the program is simply building a mental model of all the different ways to use similar elements of the interface itself.

It probably has never been possible to prioritize the interface over adding new terrain features. Understandably, UI is not as "cool" of a feature, and on a small team it can be hard to allocate resources to focus on it. But it is important. Improving it has exponential gains for users. Using the program requires hundreds of interactions with the UI an hour -- if you can make the basic acts of working with the UI faster, smoother, and more predictable, the simple time-saving benefits are enormous.

To really do this right is a big project. You need a really good graphic designer to prototype new visuals for the interface, icons, etc (I suggest looking into Figma, a nice UI prototyping tool). You have to re-architect all the UI to inherit from a robust, future-proof UI API to ensure consistent interactions across the board and low resistance to adding new UI elements that match the scheme. And you need to focus test the UI experience with new users and seasoned pros in order to identify what should take priority in the design. That sort of testing is critical to forming the right overarching direction for the UI so that it can be re-organized in the best possible way.

The goal should be to make the interface so intuitive that it practically melts away. Interacting with it should be so simple and consistent that the user doesn't even think about it-- they can instead focus completely on the creative task at hand.

Thanks for considering taking on this large and important task. The powerful methodologies that underly World Machine deserve a modern user experience, and that starts with a rich, clear, and robust UI.
It seems that if a river reach is using the trapezoidal channel type, it will not contribute any data to the flow map(making a totally still river), even when flow speed is specified manually and set to 1. Changing the reach to use the curved channel type makes the river generate flow data. The expected behavior is that either channel type should generate flow data.
Thanks for the clarification. Heres hoping for support of distributary connections at some point in the future!
Hmmm. It seems like its only supported to connect rivers coming from upstream, not splitting rivers downstream. That seems like a somewhat arbitrary limitation... Is that by design for some reason? Can we get the ability to do either? That would enhance the direct-ability of these rivers greatly.
Hey, Im trying to draw some branching rivers using the river node. When I snap a river to another, I noticed that the option to switch the upstream end of the stream disappears from the right click menu. Unfortunately, the direction of the river also changes to face the incorrect way sometimes. Seems like a bug! Am I missing something? is there any documentation about how drawing these rivers is supposed to work? thanks!

I attached an image showing the issue. the lower long river was snapped to the upper long river and its direction reversed. its no longer switchable.

Im using the latest dev channel release 3025 Alpine Lakes.
I work with a secondary window in the 3D view to see the terrain as I work. I often will edit a node's parameters, and will look at the terrain as I adjust the sliders to see its effect. I often want to see how the change will effect the the terrain from different perspectives. However, when a node's dialog is up, the 3D viewport locks and the camera cannot be orbited or moved at all. This means I find myself constantly ping ponging between adjusting parameters and then closing the dialog to change the view. The camera locking seems arbitrary and slows down the workflow. It would be great to allow camera navigation in the 3D viewport even when dialogs are up! I think its one of those small things that would really improve the editing experience. Thanks for considering this.

Matt Nava
 :D Great! Thank you so much!
I know this is an old request, but I wanted to throw my support behind it. I find that I periodically have to spend time managing wires in dense projects to try to make sure they dont overlap for readability. Having used other editors like substance designer where they have an option to toggle between square or curved connectors, I find that curved connectors are more readable because they tend to overlap less and are therefore easier to understand what they are connecting.
I noticed that I get lines of very sharp spikes, like single vertices, poking up in rows like "dragons teeth" across the boundary of soft erosion masks when "enhance mask input" is checked in the erosion node. It is possible to filter them out, however high frequency filters also tend to remove other detail that should remain. Ideally the "enhance mask input" option wouldn't generate this error in the first place. Thanks for looking into this!
Hi, I am creating a river effect using the paths in a layout generator. I have used the drop curve to surface feature to align the heights of the path to the underlying terrain. I would really like to be able to now offset the entire path up and down, to embed the path into the terrain a bit more or less. However, when you right-click drag a vertex to adjust its height, it only adjusts that single vertex. It would be great if there was a global height relative offset for the path that would maintain the overall shape of the path's height. I expected the "default Value (height)" parameter under the Shape common Properties window to do this, but it seeemed to have no effect.

Even better, I would be great to be able to offset the relative height of many paths at once, as my layout generator has many paths describing roads and rivers that I want to apply offsets to at the same time.

Thanks for considering this feature!
Hi, I'm attempting to make a complex network of rivers and roads on a large terrain. I've imported a lot of splines paths into a layout generator, and need them to all drop to the surface of the terrain. Unfortunately, even if all the paths are selected, when you right click and choose drop curve to surface, it only operates on the path that you right clicked on. it would be much better if all the selected curves dropped to the terrain, especially when dealing with hundreds of paths.

Even better, it would be nice if the paths could have a setting to remember to conform to the surface, so even when you transform them, they automatically update to the correct height.

Thanks for considering this!
WM crashes when you try to import an SVG file. To repro, create a Layout Generator. Do Add Layout from file... Click Set File... in the Layout Shape Import dialog, and choose an svg file. clicking open will crash WM.

I have found that it will not crash if the SVG contains only 1 path. Any more than 1 path in the SVG will cause WM to hang indefinitely.

I have tested that this crashes on both stable and dev builds 3021, but does not crash in version 2.3.7.

Is there a plan to create an export node for the water heightfield that is generated by the scene view node? This would be really useful for exporting complex water surfaces to other programs. I can see the heightfield with the scene view node, but I can't save it! Can the logic that shapes the water input to conform to the terrain be recreated with other nodes in the meantime? What is the logic that the scene view does to create that heightfield? Thanks!
Oh my god thank you so much! This is wonderful. This really made my day! And thank you sooo much for the maya style camera control in the viewport. Awesome update  :D

Thank you so much for the response and for understanding my perspective/use case! I really appreciate it. I hope it does turn out to be a trivial feature  :)

Matt Nava
Hi, congratulations on the release of Mailbox Peak! Its great! One small request:

The default left-mouse drag action is now panning instead of box-select. I actually much preferred the old behavior of the default left mouse drag action being box select, as right-click dragging already covers panning. This old behavior relieves basic selection and panning from requiring keyboard buttons. It seems trivial to include a checkbox option to switch between the two behaviors.


Matt Nava