MRGI SURFACE / WORKFLOW FIELD GUIDE
Prepare a ceramic material for an interactive scene
Make the target assumptions explicit and distinguish material appearance from package validity.
01 / FROM INPUT TO HANDOFF
Follow the decisions.
This walkthrough describes the intended MRGI product behavior. The browser demo illustrates a small part of the workflow; it does not run the complete application.
- 01
Define the material
- Start with
- An original sphere and local material parameters.
- Work through
- Inspect roughness, metalness, and lighting behavior.
- Result
- A candidate material appearance.
- 02
Select the target
- Start with
- A named destination recipe.
- Work through
- Specify channel packing, color spaces, and expected map dimensions.
- Result
- A documented export contract.
- 03
Validate the package
- Start with
- The material and exported map set.
- Work through
- Check structure, then inspect appearance in the actual destination.
- Result
- Structural findings and a visual review.
- 04
Handoff a version
- Start with
- The reviewed package and recipe.
- Work through
- Record source versions and known target limitations.
- Result
- A reproducible material release.
02 / INPUTS & INTERCHANGE
What travels with the work.
These are foundation formats and intended handoff contracts. Support and fidelity must be confirmed for each released build.
| Artifact | Role | Review consideration |
|---|---|---|
| PBR maps | Material input/output | Channels, color spaces, and normal conventions must be explicit. |
| Target recipe | Engine-specific export rules | Recipes need validation against the actual engine and importer. |
| QA record | Handoff evidence | State exactly which structural and visual checks ran. |
A deliberate cross-app boundary
Pair materials with Construct asset references and include validation reports in an Evidence packet.
The intended handoff should identify the selected resource, its version, the destination, and the user’s authorization. A linked application should not inherit unrestricted file access.
Explore the connected applications ↗03 / BOUNDARIES & READINESS
Know what this example establishes.
- The WebGL scene is not proof of appearance in another engine.
- No texture painting, baking, or file import is offered here.
- A metallic preview without a production environment map is only an illustration.
Development status
The source foundation is imported. Validation adapters and game-engine/WebXR acceptance testing are planned; target compatibility is not yet guaranteed.
Before a production release
Validate real-file behavior and platform support, implement the stated authorization and review rules, and document the tested acceptance scope. The interactive website is a product demonstration, not a release candidate for the application.
04 / PRODUCT QUESTIONS
The details that matter.
Why does the material change under different lighting?
Lighting and surface parameters jointly affect appearance. The preview lets you inspect those relationships before considering a target-specific handoff.
Will these settings export to a game engine?
The lab displays parameters only. A production export adapter would need a defined material contract and destination validation.
Open-source foundation
Layered PBR painting, GPU baking, and packed engine export templates exist in TextureCraft. Reproducible QA evidence is the proposed MRGI extension. Read the credits and foundation mapping.
Keep exploring Surface.
Return to the product breakdown or try the local interactive example.