Beyond Heightfields

I think we need to jump straight to the marquee feature for Dragontail Peak that I’ve been working on for the last two years. 🙂

Simply this: for the first time World Machine will be able to generate and manipulate non-heightfield terrain!

There’s a lot to talk about here. 🙂 And the details should go in the WM help center / docs. But first, let’s talk about the motivation for this new development direction.

Terrain Large and Small

World Machine has always used heightfields to represent terrain. This is not an accident – heightfields have been the dominant way to represent environments since essentially forever. A heightfield is basically the digital version of a topographic map, after all.

And this has worked well for a long time. But as computers get ever more powerful and we keep pushing detail scale ever finer, the problems become more apparent and objectionable. At 40m/px, the earth’s surface essentially is a heightfield. At 0.25m/px, that’s trivially untrue for anything except piles of dry sand! The reason: in nature, rock — and even soil — has shear strength which supports steep critical slopes, overhangs, and true 3D structure and detail.

Heightfields have yet another related problem that becomes ugly at fine scales: They use a top-down, worldspace projection. You give me (X,Y), and I tell you Z. This is simple, intuitive, and fast, but for steep slopes >45 degrees it breaks down completely. Only a few pixels are available to cover hundreds of meters of cliffy, vertical terrain¹, and it produces smeary, unusable results.

You can work around these limitations by placing custom detail meshes on cliff areas where you want more detail. But besides being laborious, you now have two completely different workflows for creating the terrain surface.

The primary focus of Dragontail is to increase World Machine’s ability to create realistic, high-definition scenes by moving beyond heightfields.

If Not Heightfield..?

If trying to use a heightfield to represent fine details produces unsatisfying results… what else is there?

Probably the most common alternatives are:

• General 3D meshes are well supported everywhere and can do anything. All the same tradeoffs apply as always have – they are expensive in terms of memory. Worse from the terrain authoring perspective is the complexity of their fully general nature – many algorithms that are straightforward on heightfields are at least an order of magnitude more challenging to implement (and slower) on a general mesh.
• Sparse voxels have also become popular lately, and let you break heightfield limitations. There are some really good things about voxels! In particular, the simplicity of performing simulations and modeling with them is great, and for some game purposes they’re clearly the right answer. But: high resolution results have steep memory and performance costs, they don’t easily provide a UV mapping of the surface for unique texturing, and they’re not well supported by other tools.

There’s no obvious winner to represent next-gen geometry. There’s a great, in-depth talk by Brian Karis of Epic Games called Journey to Nanite where he discusses why they ended up going with triangle meshes for the Nanite renderer. Simply put, for fully general objects, triangle meshes are hard to beat.

… but terrain is not a general object! Even the most extreme mountains on the earth, when scaled to the dimensions of the entire planet, are smoother than a billiard ball. To a quite good approximation, a local region of the earth is best thought of as a flat plane. That exact fact is why heightfields have worked so well for decades.

So is there some way we can have our cake and eat it too — preserve the benefits of heightfields but overcome the worst of their flaws?

Vector Displacement

VDMs have been around for decades. To my knowledge, they have mostly been put to use in sculpting workflows as brushes in mudbox or zbrush. For representing general objects they have some significant limitations that prevent their use. But it is my opinion is that VDMs are the best option available for creating and displaying terrain.

If you’re not familiar, the concept is this:

Assuming the starting surface is a flat plane as mentioned above:

• A heightfield is a grid of vertices describing how far to displace each point upward from the surface (along the Z axis).
• A VDM is the same, except each point contains a full XYZ displacement, allowing a point to be pushed sideways as well.

This simple idea has some huge benefits. The first and most obvious: We can push points sideways, so we can achieve overhangs, lips, and crinkled rocky surfaces! Comparing to the high complexity of triangle meshes and voxels, we inherit a host of really desirable properties from heightfields at modest cost:

• Simple regular 2D grid structure
• Efficient memory usage (3 channels instead of 1)
• Superset of a heightfield: If XY displacements are zero, reduces to a HF. In the simplest case, displaying a VDM surface means using a float3 instead of a float in the vertex shader 😉
• With only a few exceptions, we can represent virtually any earth surface shape.
• An implicit UV parameterization of the surface for unique texture mapping. More about this later…
• Regular connectivity between vertices allows for simple and fast operations on the surface.
• Can be easily resampled to simplify or add detail
• Implicitly convertible from a heightfield
• Trivially convertible to a mesh

That’s a pretty hefty set of benefits for such a simple idea!

Of course, there is no completely free lunch. The very thing that makes VDMs so efficient and powerful is also their limitation: the uniform connectivity between vertices. You could imagine the grid as a square made of stretchy fiber. You can wrap it around objects, stretch it, deform it.. but you aren’t allowed to cut the cloth². A mathematician would describe the surface as simply-connected genus zero. That means: no holes.

For terrain, there’s really only one shape that is missing: You can’t create an arch. Also, you also can create an entire cave system if you want, but you can’t leave an blank opening somewhere (that would be a hole).

There’s one other major benefit of a heightfield that we lose when we allow XY displacement: We lose that nice map-like property of being able to instantly find the elevation at a given location. With a VDM, to find the surface nearest to a given location, you need to build a BVH or similar spatial lookup structure, just as if it was a mesh. This is mostly painful if you’re creating a game engine or writing terrain algorithms 😉

Dragontail + VDM

There’s a LOT more to say on VDMs and terrain and what World Machine is doing with them. Dragontail contains a whole host of new tools to power this VDM-based workflow:

• VDM native 3D noises and surface displacement, including incredibly useful curvature-aware modes that protect against self-intersection
• Many (but not all) heightfield based devices have already been extended to VDMs, including the simulation devices like Erosion! Also tools like Height/Slope/Wetness selectors, flow restructure, etc. Eventually, I hope for this to hit functionally 100%.
• Powerful VDM specific tools like repair and optimize that fix issues that can happen when working with VDMs
• You can output VDMs natively as 32bit EXR files, convert them to (possibly optimized) meshes, or output as a hybrid: Generate a heightfield surface from the VDM, and also automatically create companion detail meshes where the terrain becomes too steep for a heightfield to work well.

The export part is really important. I expect most people other than me are creating their terrain to actually use somewhere else. 😉 Since VDMs are not that common as a geometry primitive, you may not be able to use them natively. Here’s the same world as shown in the leading image, set to be exported as a base optimized mesh:

I’ll end by showing off showing off how Dragontail Peak makes it easy to create VDM terrains. Let’s start with one of the most powerful new devices – VDM Optimize, and see how it can improve an impossibly bad heightfield terrain.

VDM Optimize

One of the early discoveries I had was that in many ways, a VDM can be considered the mathematical dual of a mesh + uvmap. Ignoring connectivity, a mesh is a collection of vertices in space, each with a connection to a point in a UV map; a VDM is a (uvspace) map which is essentially a collection of vertices in space. What this means it that each VDM defines an automatic unique UV mapping.

In practice, that means that a lot of the things we want to do with texturing and materials on a terrain — they Just Work the way we want them to. If you apply a tiled texture or displacement onto our surface, it will wrap exactly around your shapes as you’d hope.

However, when you start pushing vertices around, it’s inevitable that the implicit UV mapping will become distorted. We can use that duality I described above to re-structure the VDM to keep the same shape but with vertices located where we need them to provide, as much as possible, a uniform UV mapping.

This is the purpose of the new Optimize device. Here’s a quick example in action.

Let’s start with a basic steep (~89 degree) heightfield cliff, as it’s a classic pathological case for heightfields. There’s almost no detail on a heightfield that steep at all! Although you can create that shape in WM today, it’s not really functional.

In Dragontail, we can convert this to a VDM and make it usable by simply wiring the output into the VDM Optimize device.

Which moves vertices around so that they are distributed evenly on both the flat and cliff areas:

In exchange for the flat areas losing a bit of resolution, the cliff area is now at the same level of detail as the base!

And we can plug that new surface into our new VDM Noise device to displace it and achieve some nice cliff detail:

And by the way, all of our texturing macros still work, since all of the primitive devices (selectors, etc) have been updated for VDMs:

I hope to get the first Dev Preview out within the next couple weeks for ya’ll to start playing with this!

Until next time.

Stephen

1. I’m ignoring workarounds like triplanar texturing here, which do exist but don’t provide a uniquely addressible surface location. You could also UV map your terrain, but – well, see the rest of this article. ↩︎
2. I mean, you can. it’s basically like creating multiple charts / UV islands. But once you start introducing surface cuts, you lose a lot of the simplicity benefits that we inherited from heightfields, and so I’m ignoring that possibility here. ↩︎