Cache Terrain device

[HYLK]

A device that is not build by the global “build” commands, but instead is build only when the user opens it and presses the build button within it (or some special key combination, shift+left mouse click on the device). Then, this device will store it’s input and only let go of it when told so by the user.

This is nice when working with terrain that is not supported by the layout generator, f.e. when using distortion on your terrain. You cache your current terrain in the device, then lock preview and open the layout generator. You now have a layout that is accurate and already rendered.

A very useful scenario is when you want to edit/add headwaters. I tried to do this but because the layout generator was busy rendering my terrain the UI was very slow and the resulting render was inaccurate. I had to export the current height map, import it and then lock the preview in order to edit the headwaters.

[Stephen]

Hi there,

I agree, this is a very useful idea!

It has a lot of applications for tiled builds, working with water, etc. And funny enough I’m right on the same page with you - this almost made it into build 3028! There are some corner cases where it wasn’t clear how best to handle, and also the question of where the data should be stored - putting sometimes-gigabytes into the TMD is a bad idea, so it should instead go into a companion .state file or something similar, which then requires some additional plumbing throughout WM.

This was actually going to be added to the Checkpoint device, transforming it from an inert routing aid to a useful utility device. An initial proof of concept of this exists but the corner cases held it back. I do hope to get it out into one of the next couple builds!

[HYLK]

Funny coincidence! I hadn’t really thought about the whole storing issue. I suppose it could be stored in RAM while the file is open and then on closing, just as with any TMD, ask you to store the session? Maybe an extra prompt, reminding you of cache that will be lost.

And the checkpoint device is really helpful as it is now, will its behaviour be changed drastically?

[Stephen]

The additional results caching would be fully op-in. The checkpoint would be passive (identical to current) when first added; you can then capture/release input data as needed.

Of course, it would also be possible to simply create a separate device as well if that ended up working out better.

[HYLK]

I think it may be confusing to newcomers if this ability is hidden in some other device.

And I can think of cases advocating a separate device.

• What if you have multiple inputs for the checkpoint device, will it then cache all their data, or will you have to toggle caching for each input? If not and you only need to cache the data of one input, then you should add a new checkpoint anyways, so why not make it a separate device?
• How will the outputs of the checkpoint device behave? They will no longer behave predictable, that is, simply routing the data, but instead it now may be possible the outputs no longer update their internal state, leading to maybe confusing World Machines, especially if one output is cached and the others aren’t.
• What if you want to cache at a lower resolution? Will it be possible to override the resolution for the every input? I think this will really clutter the device.
• The device’s name no longer describes its behavior. This may be the most important reason, as the name checkpoint gives no clue as to being able to cache data.

I think a separate device is better since it will have a unique and clearly defined function, giving you all the flexibility of a normal device, all while the checkpoint device’s function will also remain unique, instead of becoming a hybrid device.

Thinking about the checkpoint device a lot, I thought of a cool UI feature, I will open another thread for that!