• Welcome to World Machine Community. Please login or sign up.
October 15, 2019, 07:03:21 pm


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.

Topics - Ben

Welcome back Stephen! One trick I use to optimize my large scale blur's is to use 2 Blur's. First blur is 1/4 resolution followed by a second, full resolution blur (in pixel space rather than world) with a distance of 4 to match the 1/4 scale difference of the previous blur. This usually gives me indistinguishable results but is incredibly fast. For example, I'm currently replacing a blur which takes 4:47 to render at full resolution (8192) on 40 cores and 210 GB of memory. The optimized version takes 9 seconds.
Feature Requests / Mesh Export with Vertex Color
May 06, 2016, 03:18:23 pm
How about adding a bitmap input (or maybe 4 Heightfield inputs so was can use vertex alpha too) for the Mesh Output node for assigning vertex colors?
I've been having some issues building my 4x4 world. The problem would be fixed with an option to limit how many concurrent builds are active at once. My home computer can handle building 4 tiles at once, so right now I have to manually set up 4 separate builds. I'd like to run the thing over night except I can't since I have to be there to set up the next build when the previous one finishes. It would be great if I could tell WM to render all tiles but only render 4 at a time.
To reproduce, put a noise (or any generator) inside a macro and put that macro in a group which is set to local space. Enter the macro and notice that the noise will not be set to local space as it should. If you connect that noise with any other devices in the macro then it conflicts with local space (as expected) and fails to build from that point and beyond.
Bug Reports and Help / 3.0.Dev1 - Crash R6025
August 22, 2014, 12:25:24 am
QuoteRuntime Error!

Program: C:\...

- pure virtual function call

The crash hung so I never got to a crash report/dump. I attached an image of it here too for shits and giggles. Not much info there :(

I believe I was in layout with the preview render locked at the end of my device chain which was slow running so I set the preview render to the layout device I was working in and switched back to layout view and that's when it crashed.
I just rebuilt and the bar didn't filled to 100% though the build actually was successful The final device (Overlay View) status also got stuck on "Preparing." I've done plenty of builds without seeing this. If I keep seeing it I'll post more info. So far I'm unsuccessful in reproducing.
So after some testing I've found that when adding any new generator devices inside a macro and then connecting them to devices, the connection is dotted and the top left mini preview shows black for the whole chain.  It's not actually broken though, it has no warnings and builds fine, I can view the results of the chain in the 3D View just fine. If I save the project and reopen it then the mini previews work and there are solid black connections, as it should have been in the beginning.

Edit: meant to label 3.0.Dev1, oh well
Sorry if this was mentioned, but I noticed that the new/converted blend mode 'Detail with Differences' now has twice the strength that 'Detail' had. This is a nice upgrade actually, but it is going to cause me to have to look through hundreds of combiners to find and adjust the ones that used Detail. Is this what I should expect to do or are there any plans to help deal with this change?

On this note, has there been any consideration for maintaining old device versions in existing saved files and flagging them as old? In Filter Forge if I open an old filter in a new version, all the out of date devices have the version number attached to the title for when they were created in the project. They work as they did in that version in order to maintain results. Seems like is could be a bitch of a thing to support, I have no idea, but I think it could save you and everyone some future headaches if more device changes like these are planned.

Congrats and thanks for the new release, these are some major features! Rescaling is going to make my life SO much easier.
Feature Requests / Macro Bypass improvments
April 28, 2014, 01:59:49 am
I would love to be able to specify inside a macro what gets output while bypassed. Currently the primary input/output gets passed through but the remaining outputs just break whatever they're connected to. I would imagine if it were implemented, it would be added to the Macro Out Port individual port 'Settings...' Inside there the user would specify either a bypass value (based on output type) or be able to choose one of the macro inputs provided it's a matching type. Does that make sense? I have some pretty complicated macros that share information quite liberally so in certain cases while I'd like to disable a heavy macro because I currently don't use its features, I can't stop it from rendering (a bunch of nothing) because bypassing breaks downstream nodes.
Feature Requests / Overlay View for water
January 31, 2014, 12:29:17 am
In most of my projects I end up coloring my below-sea-level terrain to look like water and I hide the water plane because a solid blue color isn't very interesting. I made some sea foam recently and was thinking it would be nice to be able to write color to the water plane just like we can with the Overlay View "output." I attached an example image, the foam only looks good from a strong downward angle because it's attached to the terrain. I would like to add waves and more foam further out from the shore but it would only look good if it were drawn on the water plane.
Feature Requests / Convexity sample distance
November 17, 2013, 01:19:05 am
I know the focus is elsewhere at the moment but it would be great if Select Convexity had a radius option. I attached an image rendered from Filter Forge (which has radius) showing 3 results with a radius of 1, 16, and 32 from left to right. I've found it to be a very useful tool for all kinds of purposes. The 1 pixel sample distance in WM feels very limiting to me.
It seems that when a library input is missing it's source file you can no longer properly open the world that contains that library input. It almost opens, but it's missing all the connections and quickly crashes. I can provide more info if needed but it seems easily reproduced.
Feature Requests / View Last Build Stats
November 16, 2013, 11:53:51 am
I would love to have a way to open up the build stats window from by last render after I've already closed it. When I'm optimizing my projects I often find myself habitually closing the build stat window before I remember to actually look at them. Then I have to start a new build, which takes just long enough for me to forget and repeat my mistake (fingers are too quick for my brain!). Perhaps WM could auto save build logs, or provide an option to do so.

In the more distant future I would love to have a device view "view mode" that recolors all devices based on their last build time (red=bad green=good) and also display their build times.

Another request: I'd love to see stats and devices inside macros to show up on full builds. Macros could be expandable to see the inner devices and their stats. This sort of applies to the Device Navigation too where macros are also not expandable like groups are.

And another related question to macros that might be better for another thread: It seems like macros always build everything inside even when a bunch of devices don't feed back into the local tree. When I do partial builds inside my macros, I find that my builds are much better than building the macro from the outside. If I delete the devices that don't feed back, my build times seem to match up better. Is this expected? I think it's been happening forever, not a new issue.

Full detail snapshot isn't scaling the Overlay texture into the render extent area currently. I'm just seeing the bottom left 4th of it overlayed on the whole terrain.
Bug Reports and Help / Macro output connecting bug
July 15, 2013, 03:32:00 am
So whenever I try to connect macro outputs into a rout point, I'm only able to connect the first output. Every other one just acts as if I chose output 1. Example tmd attached.

Side request: I wish deleting a device didn't kill all the route points downstream. To reproduce: open default scene > add route point after the Terrace > delete Terrace and watch the route point disappear as well :(
Feature Requests / Shape Falloff Type: Centered
July 15, 2013, 03:16:53 am
It would be great to have a third option for shape falloff type that centers the falloff on the shape edge. I made a button image, but another way would be to allow both Falloff Type buttons to be toggled at the same time. Less UI that way, but it wouldn't communicate as well to the user either.
Bug Reports and Help / Inputs getting ignored
July 09, 2013, 07:32:34 pm
So I'm not exactly sure what and where things are breaking but I have noticed several cases where connected inputs get ignored. In my current case I have a perlin noise that gets packed into RGB with 2 other noises, passed into a macro, split back into individual noises, passed into another macro where it finally breaks.

Interestingly when copied and pasted my test case into its own file, it worked as expected. But after making a few changes and undoing them it broke again. So the good news is I have a working and broken copy of the same tmd.

I'm pretty sure this problem's been around for a while, I've had a few issues in the past, but I only now have a project that's complex enough to see it regularly. The project files attached are saved in Just dig into the 2 macros and render the ramp, it should be distorted as it is one level up.

Feature Requests / Future of Tiled Builds?
January 20, 2013, 12:08:58 pm
Hey everyone, Remnant! Before I tell you how much WM sucks (lol yeah right :P), thank you for your continued development and support.

First I'll say that I understand why tiled builds break (anything that samples neighboring pixels, with greater error the further the distance). I'm curious how much thought has been put into solving this issue? I'm talking about potential WM3 features obviously. I want you to finish the current beta after all! So far everyone seems to have just accepted it and moved on. In the current state, I will never be able to use tiled builds because:

- Displacement: Obviously it can't find terrain beyond the tiled borders to pull into the tile, so if I'm displacing eastward, the west border of the tile either gets stretched or mirrored. I use displacement heavily in all my terrains, it's easily my #1 tile breaker. Strike one!

- Rain Shadows: I generate rain shadows east of mountain ranges by using a lightmap with shadows only, pointing east with a very low heading. If there is a mountain range just beyond my tile borders then no rain shadow can be generated and now I get a rain forest instead of a desert. I also use this to make western coasts more lush (making a "water shadow" for roughly simulating weather) but have the same issue where a coast might lay just beyond my border to the west. Strike two and three!

Then there are the obvious ones that have been discussed in the past like erosion and blur. Erosion I feel like I might be able to get past, but I do have a few large blurs that might be heavily affected, they're currently just overshadowed by issues from displacement and...shadows.

Perhaps there's some solution where WM could get a low res version of neighboring tiles to sample from? I'm not 100% sure how good of a job that would do, but in most of my cases, I don't need high detail terrain to sample from and I'd be willing to take a fairly large render speed hit.

Here's my current project, in case you're curious. http://procedurl.tumblr.com/ I want to do a 16x16 4096 tiled render of the 2 continents, but I can't. :( The best solution I can think of is manually making tiles with extents that are 2x the size of the desired tile, render at 8192, then cut out the middle 4096 and piece together, but I feel like that will still not solve the problem completely.
I believe the Light-Map Maker shadows broke with 2.1. They were just working for me the other day. The only change is my installing of 2.1.
Feature Requests / Ideas for work flow improvements
January 08, 2009, 12:08:30 pm
There are some features I love that other node based programs have. Some are quite simple.

Dual Monitor support: I want this so bad! I want to be able to view my device tree and the 3D view at the same time. This one isn't supported by anything else that I'm aware of but I want it the most in WM.

Line Highlighting: I would like it if when you mouse over or select a device, all lines connected to it highlighted orange or whatever. When you mouse over a device input it would highlight the connecting line. Same with mousing over the line directly. This idea comes from UE3's node editors.

Better Curves: I highly recommend trying Filter Forge for general work flow ideas. They've got the smoothest node editor I've used yet. One major aspect I would like in WM is FF's handling of curves. All Generator Devices have a profile input for curves and there is a Tone Curve device (the same as WM's Curves device except with a Source input and a Curve input) for later curve adjustments. I like the idea that curves are their own group of devices that can be manipulated combined together before inputing into a heightfield. Here's a screenshot that shows what I'm talking about.

They've got a lot of curve devices with parameters to create many kinds of base curves like bias, gain, starstepping, pulse... Then they got curve math, combiners, mirrors...

I also like how the properties of the selected device are on the left panel so I have quicker access to them without losing control of my device view. I forgot to select a device to show this.

Clean Up Device Tree: Maybe WM already has this. I want an option to delete all devices that are not contributing to an Output.

Raw16 Extension: I mentioned this in another thread. I'd love an option to have Raw16 output with .raw rather than .r16

G16 Exporting: This would be a major help to UE3 developers.

That's all I can think of at the moment. :P Just so you know, there are some major features in WM I would love to have in FF too.
Feature Requests / Node: Mid-Tree terrain Baking
January 06, 2009, 03:20:57 pm
Due to the resolution dependence of erosion I'd like to suggest a convenience node to help bypass this problem. Of course resolution independent erosion would be the preferred choice but maybe this is more viable. What I would love is to be able to have outputs set their resolution. However, this would potentially be very bad when you have such nodes that are dependent. The output resolutions would create inconsistent results.

So maybe if there was a new node. All it would do is bake its input (at a preferred resolution separate from the world res) into a bitmap and output that bitmap. Perhaps you don't let the user link anything pre-bake node hook into anything post-bake node to prevent inconsistency. Ideally, there would be a small amount of smoothing to make up for the lower resolution.

This idea is, I like my major terrain features at 512 but I want to further detail it at higher resolutions. If I set my res to 1024 all my large terrain features that result from erosion are replaced with smaller details.
Bug Reports and Help / G16 Bitmap export
January 05, 2009, 04:21:54 pm
Is it plausible that in the near future, exporting to G16 could be supported? This is the terrain height format of choice for UE3. In the mean time I am using G16ed to convert r16 to G16. There are two annoyances with this. First, G16ed doesn't support anything above 1024. UE3 terrains like 1025 so that puts my limit at 513. Second, G16ed wont open .r16. This is minor (sort of), I just rename to raw, no further problems. This becomes a time waster when I have many terrain masks to convert. Now, this is really not WM's fault, but is there an option somewhere (or ini) where I can make WM save Raw16 to .raw instead?

Also, does anyone know of an alternative to G16ed that I can use? I would love to try 2048 (sorry, 2049) terrains in UE3... :P

Edit: Never mind the r16/raw question, I can just set the extension on the height output hehe.

Edit #2: WM resets my .raw extension back to .r16 when I close the height outputs :( So my question stands!
General Discussion / Filter Forge
February 16, 2007, 01:37:56 am
I came across the coolest photoshop (and stand along) plugin yesterday. It's a node based filter editor very similar to WM. Just take a look at the user submitted library of filters and you'll see the power.


Try the demo and definitely download a bunch of the filters, if nothing more than to see how they were made. I figured you guys would appreciate it :)
Bug Reports and Help / Building terrain in sections
October 01, 2005, 10:02:47 pm
I was wondering if there is a way to slice my terrain into a set number of sections and render each section seperately without screwing with the devices. I know i can basically zoom in and pan around in the world size and positioning options but that doesnt work well when you're using lots of gradients and such for stuff like coastal regions. It would be really nice to be able to slice my terrain into 9 squares (3x3) and render each square out seperately.

In my case, i'm using this for Battlefield 2 which has a central terrain height map for the playable area and 8 surrounding lower res height maps so the terrain doesnt just end in view of the player. So you'd think i could just build the terrain and slice it in photoshop or whatever. The problem is that on the central terrain, i am able to use a 4096x4069 texture but since i can only build the terrain at a max of 8192, split that by three and i'm not getting the potential detail, if that makes sense.

Anyway, whether or not i can hack it, i think it would be a really useful feature. But i can imagine that it wouldnt be as simple as it seems with the way the different devices work. I guess my best option would be to build an 8192 terrain, use the midle 4096 of it and just stretch the surrounding terrain out accordingly.
Bug Reports and Help / 4096 building incorectly
August 17, 2005, 06:43:24 pm
This seems to have to do with the memory conservation. I've got a gaussian blur masked by a height selector. The blur is not being masked however (this is my best guess) so my outputs are totally incorrect, 2048 works fine, but i dont use memory conservation for that. The height selector, like all my file outputs, is being preserved even though the memory conservation is only supposed to preserve outputs, right? So it seems like that's where things get messed. Somehow that height selection is not being fed into the blur mask. Like maybe it's acting as an output, so its info isnt fed into the mask... i dont know. I'm going to test the memory conservation out at lower res and see if i get the same results. Just got to wait a while for this latest 4096 build lol.

Edit: Ok, the problem isnt the height selector, its simply anything being fed into a mask input. I'm going to try outputing the select height and input that into the mask for now.

...Well using a file input didnt work either. I did go another rout though with a chooser for the same effect, but a fix for that would be nice :P
General Discussion / Sea level + related filters
August 13, 2005, 05:07:31 am
Hey everyone, first post, so this is my intro as well.

Anyway, excuse me if this has been discussed but i'll just post it anyway. Now that 1.0 is out, what would be awesome to see in the next big release would be the ability to set a Sea level and include a host of water dynamics filters that affect the coastal areas. There are lots of erosion possibilities. It would certainly be awesome to have beaches and coastal cliffs created realistically. With a mask input you could determine where soft unstable earth is to create cliffs or whatever. And obviosly, erosion below Sea level would be drastically different. Pretty please? :P

- Ben