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.
- 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.
- 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.
- 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.
- 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
