How to mitigate resolution dependencies?

[hamzaaa1988]

Hi all,

I am currently trying to work out a workflow (huehue) for a little project I have. In this project I want to create different islands of different sizes which are then later put back together to form the game world. For hardware, rendering time and organizational reasons I want to create each island in a seperate WM file (different resolutions and extent sizes but the same m/px ratio) and already prepared a node-setup that islands can easily be created and ensure the same look and quality.

Currently I run into the problem that in World Machine many devices are resolution dependent (like Erosion) which can result in that erosion on smaller islands looks different than on bigger islands. Now I try to mitigate or solve this problem, but I am not sure how.

Here you can see how different resolutions/extent sizes impact the outcome of the same island:

Here are some ideas I came up with:

• Create all islands in a big extent and high resolution and crop the outputs later → Results in high rendering time and ram consumption due to high resolution
• Create all islands in a big extent and high resolution and use tiled build to get the separated render in the correct crop and resolution → Unsure if tiled build works the same as just using a smaller extent and introducing the same problems again? Also there is this problem too

Do you maybe have ideas how to solve this? Thanks!

[Stephen]

Resolution-dependent output is a thorny problem. It can’t be solved pixel-perfectly without all of the data in one place.

The good news is that fine details are usually pretty local, which means that what we mostly need from the surrounding terrain is the broad strokes of the erosion simulation, etc.

My preferred way of dealing with this is creating a big extent that contains all of your world, and build it at least at a moderate resolution ( it does not have to be your final desired build).

Pipe all of your various important outputs into a Library Output device. Then in your individual island files, use a Library Input to bring in all of the data from the larger extent. It will already be placed correctly in the world.

You will need to apply some additional detailing (fine-scale noise and erosion, etc) to this lower-res data to get to your final result, but if you let the big-extent do the major earthmoving, you should get very broad agreement between your overview extent and the detail extents.

You can use this same technique to produce high-res tiled terrains that have proper context from the entire world, as tiled builds will run into the same issue when you’re building at world-scale.

[hamzaaa1988]

Hello Stephen,

thanks for taking the time! It’s very much appreciated! Thanks for explaining how you deal with that. I will definitely try it out even though I love to have everything in one node network/one file because I can of course access all elements for texturing or the likes and I don’t have to switch between extents/files which feels way more natural to me ^^
I guess another way to solve this would be the possbility to bake nodes in a larger extent and then keep working in a smaller extent or kind of having the option to set in which extent devices should be computed? (similar to the resolution override feature) Maybe there can be a cool solution in the future
Could you also comment on this in the other threat? Thanks a ton, I love World Machine a lot! Keep up the good work!

[Stephen]

You can definitely keep everything in one file if you’d like; the only issue is that once you finish working on your base terrain, you’ll want to disable the group to keep it from trying to build (or you’ll have to use the build-to command exclusively).

You can setup your world like this:

Where the Library Out/In pair decouples things.

You’ll also need more than one render extent; the large one that contains everything that you use to build your global results, and then the zoomed-in ones that you’ll switch to when it’s time to build the detailed areas.

[hamzaaa1988]

Ah I see so it already is sort of a baking process (or more like a portal?) Cool, I will definitely try this Thanks!

[hamzaaa1988]

Then I’d love to have an option to say which extent a library node is using

[hamzaaa1988]

I have made some further tests so for my case it seems that the erosion is the main factor that can differ depending on resolution (@Stephen is there a list of devices or can you pinpoint devices that are heavily influenced by resolution as well?). Unfortunately for me it’s hard to isolate just the erosion from my network or split my network in two with library nodes because so much stuff is interconnected so for me a solution within the erosion node itself (or a general feature for nodes that is) would be best. Maybe we could have a feature for nodes that is something like a “working extent” or “extent override”. Because then together with the resolution override I could define for specific devices to use a bigger extent and higher resolution and feed the cropped result back into my network all in one step without the need of library nodes. Do you think this might be possible and if yes could be added to the feature backlog?

[HYLK]

You can also try reducing the resolution of the world, prior to the erosion node, and then work in a higher resolution afterwards. Are you familiar with changing the resolutions of a device?

[hamzaaa1988]

Yes I am familiar with the resolution override feature. I am not sure if overriding resolutions prior to erosion would help me here since I have the feeling that erosion is the device with the most resolution dependency. Also pretty much my whole landmass and detailing is done before the erosion and erosion is one of the last steps so maybe I have to overthink the order and workflow of my node network…