Geometry-Based Armor Occlusion / Spatial Mapping to a Character Skeletal Mesh

Development Rendering
,
1

I’m working on a layered armor system for an isometric ARPG and I’m trying to determine the best Unreal Engine approach for mapping equipment geometry to a character’s canonical Skeletal Mesh (SKM).

The SKM acts as the canonical spatial reference for all armor, and each armor asset has its own pre-generated coverage data/mask. I need to determine where the armor geometry sits relative to the SKM and expose that spatial mapping so overlapping equipment can be resolved and used to drive a Dynamic Material Instance.

Basically, I’m creating a 3D version of a 2D sprite depth/occlusion system. I’m specifically trying to figure out how to detect where the armor sits relative to the SKM and expose that data to the rest of the system.

Any Unreal systems, APIs, or tutorials I should be looking at for this type of spatial mapping?

Similar systems that utilize this approach Project Zomboid’s Clothing system, and Exanima’s armor system. But a lot less variation, and strict structuring to mitigate Performance loss

(5 Layers total.)

2

the honest answer is that runtime geometry to geometry mapping between different meshes is expensive and fragile, so established layered armor systems either bake the mapping or replace it with data.

option 1, data driven zones, what most layering systems actually do: forget projecting geometry. each armor piece declares which body zones it covers (head, torso upper, arms, legs), and the canonical skm gets sections or sockets tagged with the same zones. on equip, hide the skm sections whose zones are fully covered. zero spatial queries, trivially fast, and it is how most rpg layering works in practice.

option 2, baked coverage masks: if you need per pixel coverage, bake it offline. project each armor mesh onto the skm surface using nearest point on surface, and splat the result into a texture in the skm uv space. geometry script in editor can do the sampling in engine, or do it once per armor asset in blender or houdini. at runtime the skm material samples the masks from a texture array and composites them.

option 3, runtime render target: render armor pieces from a uv aligned camera into a target the skm material reads. only viable when all armor shares the skm uv layout, which they do not by default, so this usually dies here unless assets are rebuilt around the canonical unwrap.

for an isometric arpg, option 1 plus careful section splitting on the skm covers gameplay occlusion, with option 2 only where you need pixel accurate silhouettes, like visible skin between straps.

3

Location/Detection Functionality:

This is the area I’m primarily looking for guidance on. If an asset already has a painted opacity mask, I’d like to dynamically determine where that mask maps onto the character’s skeletal mesh surface.

The goal is to detect when two masked assets occupy the same surface area and, based on their layer priority, modify visibility only where the overlap occurs. Ideally, this would resolve clipping/overdraw without modifying topology or requiring per-region mesh variants.

Trigger/Runtime:

The system would only need to evaluate during equip/unequip events, with the processing hidden behind the inventory workflow rather than running continuously.

I’m envisioning some form of runtime compiler/subsystem that can evaluate the equipped assets, determine their visual relationships, cache the resulting data, and update it when equipment changes.

The appeal is that artists could create an asset + its corresponding mask and register it with the system, rather than having to build specialized versions for every body region or combination.

Main question:

What Unreal Engine systems or techniques should I investigate for dynamically determining where an asset’s mask lies on a character’s skeletal mesh surface, ideally down to the mask’s actual outline?

If I can reliably establish that surface mapping, I believe the remaining overlap/priority/visibility logic becomes much more straightforward.

So I believe Option 2 fits best with my planned plugin

4

option 2 is the right family, and the runtime version of it is simpler than it sounds: the bake is just a projection, so you can run that projection at equip time instead of offline.

the primitive you want is nearest point on surface with uv readback. two routes:

geometry script route: capture the posed skm as a dynamic mesh once per equip (geometry script can read skinned meshes, or grab skinned vertex positions in c++), build its spatial index, then for each vertex of the armor piece find the nearest point on the skm. the query returns the surface position plus the triangle hit, and from the barycentric coords you read the skm’s uv0 at that spot. that uv is your splat target.

c++ route if you want it fast and untethered from bp: the GeometryProcessing module is the same machinery the editor bakers use. fDynamicMesh3 snapshot of the posed skm, fDynamicMeshAABBTree3 for queries, and a projection target call gives you nearest point + barycentrics + uv in one shot. wrap it in a parallelfor inside a world subsystem and that is your “runtime compiler”. a 5 piece loadout is maybe 100-200k projections against a cached tree, that’s a few milliseconds spread over a frame or two, and it only runs on equip like you planned.

the part that gets you “down to the mask’s actual outline” instead of just geometric coverage: don’t project bare vertices. for each piece vertex, first read its own uv in the piece’s painted mask, carry that value through the projection, and splat the mask value (not just a coverage bit) into the skm uv space buffer. the painted opacity travels with the projection. write each piece’s splat into its own render target (or channel pack 5 layers across two rgba targets), run a small dilation and blur pass over the splat to heal the seams, and the mask outline lands on the skm in the piece’s own handwriting.

subsystem structure: key the cache by loadout, recompute only on equip/unequip, reuse a small pool of render targets. one nice shortcut: if the armor pieces are skinned to the same skeleton as the skm, the mapping barely changes with pose, so you can sample at bind pose and cache per asset instead of per loadout, which makes equip nearly free.

compositing is then exactly what you described: skm master material samples the packed masks and resolves per pixel in layer priority, higher priority wins where masks overlap, and a mid only swaps the mask textures. no topology changes, no per region variants.

gotchas up front: uv islands mean splats can straddle seams, dilate a few texels and accept hard island borders, they read as clean material edges anyway. 1k to 2k texture on the skm uv is plenty for silhouettes. and if you want an artist facing validation pass, the same projection can run at import time in the geometry script editor bake path so bad masks get flagged before they ever reach the runtime compiler.

project zomboid’s system is genuinely the right mental model, it’s this exact splat and composite in 2d pixel space. you’re doing it on a uv unwrapped surface instead.

5

Yeah I wholeheartedly agree with your take.

Option 1: This as a Custom system, granted this is pseudo-code and there are likely small artifacts, fine tuning, and edge-cases dependent upon my execution, and art assets this is a theoretical implementation for what I require but Time/Effort/Energy would be at all time high to create this myself.

Option 2: I just recently discovered Mutable Plugin. From my research on it I could theoretically utilize Clip Mesh with Mesh, and the tools that plugin inherently provides to run in a more performant way than the custom proposed system.

I could mitigate scope by Duplicating the Equipment Mesh itself that’s being imported, Scale up 1-2px, Decimate, and utilize it’s own model as a clipping bounds.

With one major caveat I can save performance by actually combining geometry using this plugin, and immediately utilize that performance saving to then leave the Highest priority layer for Cloth that only visually hides the mesh directly underneath it while leaving Topo for Collision/Structure. (Think Guild Wars Capes).

I’m learning as I go, you likely have far more experience than I do if you were a solo-dev, which route would you go?

How reliable are plugin’s like Mutable to utilize in a large project with the intent to commercialize?

Any extra advice you can provide I’d be extremely appreciative, thanks buddy!

6

your read on mutable is right, and for a 5 layer isometric arpg i’d start there before writing a custom compiler. which route i’d go: mutable first, keep the projection masks in your back pocket.

why: mutable already solves the two expensive problems, mesh combining and texture baking, with an artist facing workflow. your painted opacity masks slot straight into its texture compositing, layer priority is just composite order, and clip mesh with mesh handles the geometry side. your decimated shell idea works too, one refinement: prefer mutable’s built in mesh selections (remove by bone, section, or region) wherever coverage is anatomically predictable, arms, torso, legs. inflated shells are the right tool for freeform pieces where regions don’t cut cleanly, just watch that decimation doesn’t pull the shell surface inside the base mesh at thin spots like cuffs, that reads as clipping holes. keep the shell a bit fatter there, or skip decimation on the shell entirely since it gets discarded after the clip anyway.

the guild wars cape plan is sound, and mutable supports exactly that shape: keep the body mesh full for collision and let the top priority cloth piece own its region visually. two things do the hiding: the composited texture, where the cloth mask bakes over the body texture so nothing looks wrong where they overlap, and where actual geometry would poke through, a mesh selection on the body removes just that region. no per pixel occlusion system needed, which is where the custom route’s cost lives.

commercial reliability, honestly: it’s open source under a permissive license, actively maintained, and has shipped in commercial projects, so licensing and provenance are safe. the real costs are engineering ones: it’s a large native plugin so every engine upgrade waits on a compatible build, or you patch it yourself, which is doable since the source is right there. bakes spike memory at equip, and combine cost scales with triangle count. all of that fits your plan of hiding the work behind the inventory flow. the one thing i’d insist on: prototype one full loadout end to end, helmet, chest, cape, and measure bake time and memory on your target machine before committing the architecture. if those numbers are comfortable you’re done, and if they’re not, the masks you authored work unchanged in a custom compositor later, nothing is wasted.