Building a Reusable Terrain Stamp Library with Data Assets in UE5

Why a folder of heightmaps is not a stamp library

Most terrain workflows start the same way: a folder of heightmap PNGs with names like mountain_final_v3 and canyon_use_this_one. It works for a week. Then the folder has two hundred files, three of them are the same export at different resolutions, and nobody remembers whether the good crater was the 2K or the 4K one. The moment you want to organize reusable landscape stamps into an Unreal Data Asset library, you discover that a raw texture carries almost no useful information about itself - no category, no sensible default intensity, no record of where it came from.

The fix is to stop treating a stamp as a texture and start treating it as a record. In Unreal Engine 5 the natural home for that record is a Data Asset: a small, editable object that bundles the heightmap together with everything you need to know about it. Landstamp Pro takes exactly this approach. Its stamps are data-driven UStampAsset records, and the entire library - the company line is 370+ stamp data assets backed by 100+ high-resolution heightmap textures up to 4K - is browsable and filterable because each entry describes itself rather than hiding inside a filename.

This tutorial walks through the anatomy of that data-asset approach so you understand what each field buys you, how categorisation keeps a large library navigable, why a source-file hash stops you importing the same PNG twice, and how the Stamp Browser turns the whole thing into a drag-and-drop catalogue.

Anatomy of a UStampAsset

In Landstamp Pro a stamp is a UStampAsset, which derives from UPrimaryDataAsset. Using a Primary Data Asset matters: it makes each stamp a first-class, individually loadable object that the asset registry can scan, so a browser can list and filter the whole set without loading every texture into memory at once.

Each record carries a small set of descriptive fields - a DisplayName, a Description, a Category, the Pack it belongs to, and a list of Tags. Those are the fields a browser reads to group and search the library, and they are the reason a stamp can introduce itself instead of relying on a filename convention.

The heavy data is referenced, not embedded. A UStampAsset stores its HeightmapTexture and its ThumbnailTexture as soft object pointers rather than hard references. That keeps the data asset itself tiny and lets the editor show you a wall of thumbnails while only streaming the full-resolution heightmaps you actually place - useful when the underlying texture library is large enough that the plugin notes a footprint of roughly 1.97 GB.

Finally, each stamp records its own placement defaults: a default blend mode, a default intensity and scale, and an invert-height flag. This is the part loose PNGs can never do. When you drag a river stamp in, it can arrive pre-tuned to subtract rather than add, at a sensible strength, because the data asset remembers how that particular stamp is meant to behave. You can still override everything per placement on the spawned actor, but you start from a good default instead of from zero.

Categorising by landform keeps a large library navigable

A flat list of 370-plus stamps is unusable; the structure has to come from the Category field. Landstamp Pro types this with an enum, EStampCategory, whose members map directly onto the landforms you actually reach for: Mountain, Canyon, Hill, Crater, River, Volcano, Directional, Creatures and Custom.

The discipline to take away for your own library is to make the category an enum rather than a free-text string. An enum gives you a fixed, spell-checked vocabulary, so every mountain lands in Mountain and you never end up with a 'Mountains' bucket and a 'mountain' bucket holding half the set each. The Stamp Browser can then build its filter sidebar straight from the enum, and a new stamp slots into the right group the instant you set one field.

Categories answer the broad question - what kind of landform is this - while the free-text Tags field handles the finer cross-cutting traits that do not deserve their own category: eroded, alpine, snow-capped, dry. The two work together. Category narrows the list to all rivers; tags let you find the eroded ones. The Custom member exists precisely so that stamps you generate yourself, including ones extracted from a static mesh, have an honest home rather than being forced into a landform they are not.

Stopping duplicate imports with a source-file hash

Any library that grows by import eventually faces the same hazard: you re-import a PNG you already have, and now two near-identical stamps sit in the browser, slowly diverging. UStampAsset guards against this by storing a SourceFileHash - an MD5 of the source PNG - on each record.

The pattern is simple and worth copying. When a heightmap is brought in, hash the source file and store that hash on the stamp. Before creating a new stamp from an import, compute the incoming file's hash and check it against the hashes already in the library. A match means this exact image is already a stamp, so you skip the import and point the user at the existing record instead of minting a duplicate. Because the hash is taken from the file contents, it catches the same image even when the filename has changed - the case a name-based check always misses.

If you are building your own data-asset library, add a hash field early rather than retrofitting it. It is far cheaper to record a hash on every stamp from day one than to deduplicate a library that already has hundreds of entries and no idempotency key to join them on.

Browsing and filtering in the Stamp Browser

All of this metadata pays off in the Stamp Browser - the visual thumbnail UI that the data-asset design exists to feed. It organises stamps by category, lets you search and filter, supports drag-and-drop placement straight onto a landscape, and keeps a recently-used tracker so the stamps you reach for most stay close to hand.

The workflow in practice: open the Stamp Browser from the toolbar, filter by category or type in the search box to narrow the wall of thumbnails, then drag the stamp you want onto your landscape. That drop spawns an ALandstampActor which auto-resolves the landscape beneath it, arriving pre-configured from the data asset's stored defaults. From there you tune StampSize, HeightIntensity, BlendMode, FalloffMode and Priority on the actor, use the CallInEditor PreviewStamp to check it, and ApplyToLandscape to commit - all non-destructively, because each stamp drives a Landscape Texture Patch you can move or re-tune later without baking.

To grow the library, run the mesh-to-heightmap extractor on a static mesh, pick an output resolution of 512, 1K, 2K or 4K, preview, and save the result as a new UStampAsset. Set its category - Custom is the honest choice for an extracted feature - give it a name and a few tags, and it appears in the browser alongside everything else, deduplicated by its source hash. That is the whole point of the data-asset model: a new stamp is one well-described record, and the library it joins stays searchable no matter how large it gets.

What a UStampAsset stores

The fields a Landstamp Pro UStampAsset (a UPrimaryDataAsset) carries, and what each one buys you in the library.

FAQ