Terrain Overhead feature

[HYLK]

Problem

Displacement and other “moving” devices will create artefacts because WM only knows the value of pixels in our extent.

Solution

Terrain overhead, a user defined distance of “extra” terrain in all directions, from which the Displacement device or other “moving” devices can get data so that “unnatural” edge handling can be prevented.

Reasoning

The Displacement device is somewhat limiting when creating feature defining distortion, as the terrain near the edges will often have unwanted behaviour, such as weird mirroring. When there is some overhead terrain, the device can, instead of immediately performing some sort of edge handling, creating for a much more natural looking terrain, without strange artefacts.

Downsides

• Requires more RAM and CPU power, as there will be a significant amount of data stored “outside” of the extent, which needs to be stored and updated as well.
• When placing multiple “moving” devices after each other, you will eventually “run out of” overhead, bringing you back to the problem to begin with.
• Probably confusing for newcomers.

Side-effects (a probably incomplete list)

• Because there is now invisible terrain, you may get results from natural devices that come from features outside of your extent, for example, talus or deposition from a cliff you can’t see.
• The Flow Restructure device now may show some weird behaviour, as it also takes into account terrain you can’t see.
• Blurs and Expanders will have bleed from the overhead terrain.
• When normalising the terrain, your extent may not normalise as expected.

Current workarounds

• Masking, though this creates its own artefacts as, for a magical reason, the distortion stops near the edges.
• Exporting at a larger resolution and size than planned, so you can cut away the edges where the artefacts take place.
• Using the built in distortion or Distortion Generator device to distort the terrain generators and let them do the “heavy”, terrain defining distortion and only using the Displacment device for small distoriton, though this only applies to the Displacement device.

[Stephen]

The proposed solution described above is very similar to what is done to fix similar problems when doing a tiled build. Conceptually, it would be pretty straightforward to extend a blend zone to provide additional “offscreen” context that can be displaced into view. This would more or less solve the immediate problem with the displacement device.

The problem is that the broader class of problem that this kind of solution is useful to solve are applying ‘global’ operators to zoomed in render extents – things that take into account your entire defined terrain to operate. This includes devices like flow restructure, create water, and to a lesser extent erosion.

These operations really need to see ALL of the possible outside terrain, not just a small buffer zone.

One possible idea I’ve kicked around for a long time to solve this and other context related problems is hierarchical render extents. In other words, you may have a “world” render extent that defines the full area you want to consider, and then a “scene” render extent that belongs to and can sample from the previous. However, this has the capability to cause horrendous complexity and obscure bugs, which is why it hasn’t been implemented yet…

[HYLK]

Thanks for the elaborate reply. Maybe something for a far future update of WM!