• Welcome to World Machine Community. Please login or sign up.
October 14, 2019, 06:11:47 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 - Ben

I'm on latest yeah. I'm glad I could help!

I just usually try to avoid approximate since it creates a blocky shape and often it's not much faster unless I'm doing a really large blur...in which case I find the quality of this 2 step method to be better looking. When I'm lazy I just use a single downsampled blur. It really all depends on if there's a lot of noise added down the chain, if you plan to add more noise then the quality doesnt matter so much.
Perhaps I'm misunderstanding but you can set a group resolution override in the group settings.

In my macro, which I attached, the first blur is 2048 followed by a full res blur with a pixel distance of 4 (Scale-Independent unchecked) since the previous low res blur has pixels that are 4x too big. WM's resolution up-sampling bicubic soft mode might replicate what my second blur is doing but I've never been too sure about it so I just do it manually.

This can of course be easily modified to handle lower resolutions, unfortunately there's no good way for me to make it universal with any resolution, which is why I would love a proper implementation in WM's Blur. For now you have to go into the macro and set the first blur to 1/4 your world resolution. Or 1/2 and then set the 2nd blur distance to 2.
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.
That's great news, I didn't see that you had added this optimization already. I've been wanting this for a while so thank you!!!  :D

Also local space+rescaling has allowed me to get past sample distance limitations of certain devices very well. I've been running into limits with Thermal Erosion, Expander, and Blur specifically, now I'm no longer limited as long as I'm willing to render that part at reduced scale/resolution (which is a must with those expensive devices anyway).

So far the release is very stable, no crashes yet, been using it all day.
Seems to be a bigger problem than just generators. Connections are going dotted one seemingly any device update while in a macro.

Edit: ok I'm unable to pinpoint the pattern, somehow a dotted line section fixed itself without reopening the file.
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
Quote from: Remnant on August 19, 2014, 02:23:56 amThe only situation where this wouldn't happen is in a complicated macro where the type of the combiner is set by a parameter.

This appears to be what's happening to me. This is much more manageable, I shouldn't have too many to fix and it's much easier to find combiners with parameters plugged in. I was mostly worried about the cases that I couldn't plainly see, there are just so many subtle things that could go wrong.

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 / Re: Convexity sample distance
April 28, 2014, 12:51:46 am
I figured this out today while trying to solve another problem and it was super simple. I've actually done this same thing many times with post process fx in games while experimenting with sharpen and clarity fx (the kind people love to use to fake HDR in pictures). Taking the input height map and subtracting a blurred version of itself highlights convex edges. If you swap the subtraction order and invert the result then it highlights concave edges. Take both results, 50% average blend them together, and finally normalize and that's it. Of course it has the added ability to change the sample distance through the Blur, it can also use directional blur which is potentially useful. I posted to the device library...


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 / Re: Convexity sample distance
November 30, 2013, 05:21:12 pm
Crap I'm sorry I'm working with the dev channel build so I can't share the macro. I put together an image that will hopefully explain what's going on. The problem with just bluring the convexity output (including masking the edges) is that you get very uneven results when it comes to slope angle.

Edit: I feel like I should mention that I used thermal weathering instead of a blur because it is able to smooth my convex stair edges while preserving the concave corners of the final result. Plus it ended up not being too much more expensive than an equal blur.
I think it might have been something wrong in one specific project file, it seems to be working in all my current projects. Ill report back if I see it again.
Feature Requests / Re: Convexity sample distance
November 30, 2013, 03:01:40 am
Hi WFab, thanks for the help! I just tried out the macro and unfortunately it still has some issues that I am trying to avoid. I was going to try and explain further but you inspired me to make a macro to show what I want.  :) I attached an unlocked macro so you can see what I'm going for. It's pretty much what I want because it preserves sharp edges and produces a smooth linear slope with a consistent angle, however it's slow because of all those expanders. Using less expander passes only slightly improves performance and I'd say 6 could still get good results (I'm using 8 ). 4 passes starts to look stair-stepy/smudgy. One thing also to note is that I'm testing with very low roughness voronoi and previewing the result as a height map rather than a mask (much easier to see smooth/un-smooth slopes). Hope that helps explain what I want!

Off topic: Something unrelated that I just found a good test case for is how important it is to force WM to execute threads in a certain order, even if it involves adding extra devices. For example, I put this comment in the macro:

QuoteKeeping the device count equal between concave and convex allows the expanders to stay on pace with each other to prevent one tree from waiting on the other.

The "Delay" clamp device below is only there to mirror the inverter on the concave edges so that both have the same amount of devices.

Almost a 20% performance increase!

It's a very contextual trick and in this case conveniently simple, but I do think there's a lot more to gain from thinking about stuff like this. Message for Stephen: In the future it might be nice to have some kind of threading tools or maybe WM could tell us when a combiner (or any device with multiple inputs) is waiting on only 1 input for an extended period of time. That way we would know to fix the timing in that part of the device tree.
Quote from: Remnant on November 18, 2013, 02:00:39 pm
I want 1cm per pixel detail, and my overview section is 100km of terrain. Oops.

Yeah I can see how that might be an issue. :P Perhaps it could have some min/max safety built in. It's something I've had issues with several times in the past, the disconnect of scales between multiple render extents that is. But I'm getting better at managing it.

Quote from: Remnant on November 18, 2013, 02:00:39 pm
Can you explain more of your use case on the lookup device in Filter forge?

Certainly! Attached is a simple example of why I love lookup and want it for WM. It's great for making impact craters, which is probably the most obvious example for WM use. You can generate a flow map and then use that as coord lookup for a noise. It can also work as a more powerful version of displacement (because it's 2d). Angular gradient would be a required addition to the Radial Grad device if Lookup were to make it in. See the most bottom device in the attached image for what I mean by Angular gradient.

I'm still not sure what kind of issues these coordinate warping devices would cause in an LDR environment. Are there any plans to start supporting some HDR so we can have gradients that go beyond 0 and 1 to allow them to be used as coordinate lookups? FF was LDR for a while and has done a decent job bringing in HDR without having to overhaul all at once.

Edit: Forgot to mention, as you can see in the image, it's especially useful to work on the look of my noise/pattern in a non radial environment and then apply the radial coords after. Also something else to note is that curves are their own distinct device type, which is GREAT! I can make 1 curve and supply it to as many tone curves as I want, which I didn't do in this example lol.