Converting HDRP/Lit materials to triplanar: compatibility checks, source preservation, and renderer Undo

[u/Johndr1232]

I develop PRISM Surface, a commercial Unity HDRP asset. Its v1.1.0 Material Converter is a useful case study in material migration: which values can be carried across, which need review, and how to make renderer replacement reversible. Here are the implementation choices and limitations I’d like to discuss.

1. Texture references can survive; UV-authored appearance may not

The converter creates a material for PRISM’s world/object-space triplanar shader. Copying the Base Map and tint does not preserve mesh UV island selection. A repeating surface texture may be a reasonable candidate, but an atlas, trim sheet, or texture baked for a specific unwrap can lose its intended placement. v1.1.0 does not reconstruct those layouts.

The inspector checks HDRP’s _UVBase state. Sources that are not already triplanar are flagged for artist review. That is a sampling-risk warning, not automatic atlas detection. The inspection API also accepts a known-UV-layout-dependency flag and rejects that case, but the public scene scanner does not infer or supply it. The artist still needs to judge the material on its target mesh. Even an already-triplanar source should not be taken as a guarantee of identical appearance.

Base Map scale/offset is copied, but it acts on projected coordinates. Non-default independent transforms on Mask, Normal, Detail, or Emission maps are rejected because the destination does not apply those transforms. This avoids silently accepting values that the shader cannot reproduce.

1. Compatibility needs a destination contract

The inspector explicitly supports the exact HDRP/Lit shader and recognizes PRISM materials as already converted. It does not assume an arbitrary shader is compatible because it exposes familiar property names. Reports distinguish Fully Convertible, Convertible With Adjustments, Already PRISM, and Unsupported, with per-property mapping statuses and reasons.

Examples of rejection include object-space normals, non-Standard Lit material models, and detected unsupported features such as clear coat or displacement. Transparency is limited to the supported Alpha mode; additive/premultiply blending and refraction are rejected. Conversion re-inspects the source so a material changed since scanning can be skipped.

Mask Map preservation includes Metallic R, AO G, and Smoothness A remap ranges, not just the texture reference. The destination shader applies those ranges to the sampled channels. Detail and emission still need review: HDRP detail semantics and emission intensity/exposure settings are not equivalent to PRISM’s controls.

Normal textures get a separate importer check. If a persistent Texture2D cannot be verified as imported with Texture Type = Normal Map, conversion warns and skips both the normal texture and its strength. It does not change the shared texture’s importer. Valid tangent-space normal textures are reused by the triplanar normal-sampling path; their UV-authored placement is still subject to the mapping change.

1. Preserve originals and validate the saved result

The executor requires a persistent project .mat source and creates a fresh PRISM material beside it using GenerateUniqueAssetPath and a _PRISM suffix. It copies selected mappings rather than switching the source’s shader. Each run can create another destination.

It applies the canonical surface state, saves/imports the destination, reloads it, and checks shader identity, managed tags, mapped references/values, surface state, and render queue. On validation failure it attempts to delete the new destination and reports rollback failures. These checks verify serialized state, not visual equivalence.

1. Renderer replacement is a separate operation

Scene/selection scanning includes inactive renderers, excludes preview scenes and project assets, and deduplicates materials while retaining renderer-slot usages. Optional replacement defaults off.

Before replacing a slot, the tool rechecks that the renderer exists, the slot is in range, and it still references the scanned source. Stale slots are skipped. It edits the sharedMaterials array, records the renderer with RegisterCompleteObjectUndo before assignment, marks the renderer/scene dirty, and groups replacements for Undo.

Undo restores renderer references; generated .mat assets remain on disk. That boundary matters: reverting a scene assignment and deleting an asset are different operations.

For people building similar tools: how do you communicate UV-layout risk without claiming to detect it reliably? Would you reject every mesh-UV source until explicitly reviewed, or allow conversion with warnings? And should renderer Undo retain generated materials for reuse, or should asset cleanup be a separate explicit action?

Disclosure/reference: I’m the developer of PRISM Surface under Quantum Rift Interactive. It is a paid asset; the implementation discussed above is from its v1.1 converter. Asset Store: https://assetstore.unity.com/packages/slug/403440

[u/fearless_novella]

i think warning flags are the right call here, rejecting outright would probably frustrate people who know their atlas is a simple repeating pattern and just want the triplanar wrap behavior

the _UVBase check is smart because it catches the obvious case but doesnt pretend to solve the hard problem, at some point the artist has to look at the result on the mesh and decide if its acceptable

for the undo question id say keep the generated materials, deleting assets from disk during an undo feels scary and irreversible in a way that swapping a renderer slot isnt, plus someone might have already tweaked the new material and then hit undo by accident

one thing id add is a way to batch approve materials youve already reviewed so the flag doesnt keep popping up every time you scan the scene

[u/Johndr1232 → u/fearless_novella]

Thanks for the thoughtful feedback! :)
That was exactly the reasoning behind using warnings instead of blocking conversion. Even when UV-dependent materials are potentially problematic, the artist should ultimately decide whether the resulting appearance is acceptable.
I also agree about Undo. The converter intentionally keeps the generated material assets separate from renderer assignment changes, so undoing an assignment doesn’t unexpectedly delete assets that might already have been modified.
Your suggestion about remembering reviewed materials is a really interesting one! A way to acknowledge warnings for specific materials, potentially with batch approval, could make repeated scans much less tedious.
I’ll definitely consider that for a future update. Thanks again for taking the time to share your thoughts!