UV, PBR and AI-assisted Texturing

A beautiful material can still lack acceptance evidence

A Blender prop has an AI-assisted surface concept that looks convincing under one HDRI. That first impression is not the production decision. The mesh contains accidental UV overlaps, the roughness image has been interpreted with the wrong color-space assumption, the normal convention has never been checked, and nobody can trace which regions came from supplied references versus generated material. A clean render can hide every one of those failures.

This lesson turns that ambiguity into one inspectable artifact: UV-PBR Texture Set and Provenance Ledger v1. You will declare the UV set and overlap intent, define a target-specific texel-density policy, bind PBR texture roles to a named material model, record color-space and normal conventions, preserve AI/source/rights/edit history, inspect the material under changed lighting, and test the result against an explicit interoperability target before choosing a bounded state.

Blender supports explicit UV maps and a mesh can carry multiple UV maps; that capability does not decide which seams, overlaps, or density are correct for your asset. glTF 2.0 defines a metallic-roughness material model and texture-coordinate semantics that bind textures to TEXCOORD_n sets; those format facts still do not prove that your UVs are low-distortion or that your material is production-ready. [BLENDERUV] [BLENDERUVUSE] [GLTFSPEC] [GLTFPBR]

Lesson artifact: UV-PBR Texture Set and Provenance Ledger v1 with visible evidence and one of these bounded states: ACCEPT, TARGET_SPECIFIC, REWORK_REQUIRED, HOLD, EVIDENCE_INCOMPLETE, PROVENANCE_UNKNOWN, or METHOD_UNSUITABLE.

Planned active time: 60 minutes.

Scope boundary: D3D-002 owns UV intent, PBR channel semantics, color-space/normal validation, AI-assisted texture provenance, changed-lighting checks, and target-bounded interoperability evidence. It does not absorb the production-modeling outcome of D3D-001, the reconstruction-method outcome of D3D-003, commercial publishing, rights ownership, or downstream release authority.

HARD prerequisite — D3D-001

Before entering this lesson, you should be able to state the relevant boundary carried forward from D3D-001. Carry forward only the evidence D3D-002 actually needs; do not absorb the D3D-001 outcome. If that boundary is fragile or equivalent evidence is unavailable, use a bounded bridge or equivalent evidence path before continuing; do not invent completion.

Choose the route that matches your evidence, not your confidence

Answer these four questions before you begin:

1. If a texture looks correct in the viewport, does that prove the UV overlap policy and texel density are correct for the target?
2. Should Base Color and Roughness be treated as the same kind of color data merely because both are stored in image files?
3. If an AI-assisted patch looks plausible but its source and rights status are unknown, can the texture set still receive a positive production state?
4. If a second realtime target intentionally mirrors UVs and asks for packed ORM data, should you copy the first asset's unique-UV/separate-map decision unchanged?

4/4 → Fast Path. 2–3/4 → Repair Path. 0–1/4 → Foundation Path. The route changes support, not the evidence bar.

Route self-check: Q1 should separate visual appearance from UV evidence; Q2 should distinguish color data from scalar/material data; Q3 should preserve unresolved provenance as a blocker rather than invent permission; Q4 should recompute from the new target instead of treating the baseline as an oracle.

Mental model: target first, evidence next, verdict last

Use this sequence:

UV intent → distortion/density check → PBR channel contract → color-space/normal validation → AI source/provenance log → lighting variation test → interoperable material check → ACCEPT / REWORK / HOLD

The important separation is between capability, asset evidence, and acceptance policy.

A successful export is only evidence that an export operation completed. A beauty render is only evidence that one view under one setup looked a certain way. Neither substitutes for the ledger.

Shared foundations

1. A UV map is a coordinate decision, not a quality certificate

Blender's UV workflow maps image coordinates to mesh faces and supports multiple UV maps on a mesh. That means a material can be bound to a specific UV set, but the mere existence of UVMap does not prove good seams, acceptable distortion, consistent density, or an intentional overlap policy. [BLENDERUV] [BLENDERUVUSE]

For this lesson, write the intent down before judging it. UNIQUE_REQUIRED, MIRROR_ALLOWED, and other target-specific policies are design declarations. They are not universal laws of UV layout.

2. PBR roles must be bound to a named material model

glTF 2.0's core PBR model uses metallic-roughness semantics. Base Color, metallic/roughness, normal, occlusion, and emissive information have defined material roles. In the glTF metallic-roughness texture, roughness uses the green channel and metallic uses the blue channel. Base Color RGB uses an sRGB transfer function, while metallic and roughness values are non-color material data. [GLTFSPEC] [GLTFPBR]

That does not mean every authoring tool or runtime uses one universal packed image layout. Your ledger must name the target convention instead of assuming it.

3. UV-set selection travels with material behavior

glTF texture information can reference a texture-coordinate set through texCoord, corresponding to TEXCOORD_n data on the primitive. A valid reference answers “which coordinates does this texture use?” It does not answer “are those coordinates good enough?” [GLTFSPEC]

4. AI assistance and material quality are two separate evidence questions

MAKNOW treats AI-assisted texturing as a provenance-bearing workflow. Record the assist method, the supplied/source asset reference, rights/provenance reference, and manual edit history. Then evaluate the resulting material with the same UV/PBR/lighting/interoperability checks used for any other texture set. A generated appearance does not repair unknown provenance; verified provenance does not repair a broken roughness map. This is MAKNOW design authority, not a claim that Blender or glTF supplies a rights decision.

Build the UV-PBR Texture Set and Provenance Ledger

Step 1 — name the asset and the target before touching texture quality

Start with asset_id and interoperability_target. A prop for a named realtime runtime can legitimately have different UV and packing requirements from a film-oriented asset or a source-authoring scene. If the target is not declared, “correct” becomes a moving goalpost.

Keep target scope explicit. Use STANDARD_DECLARED_TARGET only when the evidence applies to the declared standard target without a special named constraint. Use CONSTRAINED_NAMED_TARGET_ONLY when acceptance depends on a narrower runtime convention. The lesson never turns that target-specific result into a universal claim.

Step 2 — declare UV intent before measuring UV quality

Record uv_set, seam intent, and uv_overlap_policy. Then evaluate visible overlap and distortion against that declared intent. An accidental overlap is not the same thing as an intentional mirrored island. Conversely, intentional mirroring is not automatically acceptable: if the target requires unique baked detail, the same mirror can violate the contract.

The key diagnostic question is: does the observed layout match the declared target policy? Not: “is mirroring good or bad in general?”

Step 3 — make stretch and texel density target-specific

uv_stretch_check records whether the asset passed the distortion rule you declared for this exercise or project. texel_density_policy records how density will be kept coherent where coherence matters. Do not invent a universal number. A hero prop, modular environment kit, and small realtime prop can have different constraints. The evidence must state the policy and the observation that was checked against it.

Step 4 — enumerate the channel map

For each material role, record at least:

• role (base_color, metallic, roughness, normal, occlusion; emissive when used),
• image/map reference,
• UV set,
• color/data transfer interpretation,
• texture resolution,
• packing location if packed,
• evidence reference.

This prevents “the textures are there” from standing in for a material contract.

Step 5 — treat color-space interpretation as semantics

For the declared glTF metallic-roughness target, Base Color RGB is color data using sRGB transfer, while metallic and roughness values are linear material parameters. [GLTFSPEC] A roughness image interpreted as sRGB is not merely a display preference: it changes the numeric data reaching the material.

In the lab, normal and occlusion maps are also handled as non-color/linear evidence under the declared target contract. The checker reports a contradiction if a positive state depends on incompatible declared interpretation. It does not “fix” the image or guess the intended state.

Step 6 — declare the normal convention

Write normal_convention and do not rely on “it looks okay from this angle.” Tangent-space normal interpretation can differ between pipelines, and a convention mismatch often reveals itself as inverted-looking relief or inconsistent shading after transfer. The ledger's job is to make the assumption reviewable.

Step 7 — treat packing as a target contract

Separate maps make role boundaries explicit in this lesson's ledger. Packed textures combine several declared roles into one target-specific resource and therefore couple those roles to the target packing convention. Treat performance, storage, or fetch effects as target-specific measurements rather than assumptions.

For the transfer fixture, the named runtime explicitly declares ORM as R=Occlusion, G=Roughness, B=Metallic. That convention is part of the fixture's runtime contract. Do not rewrite it as “glTF always requires ORM.” glTF's metallic-roughness semantics define the metallic/roughness channel roles; sharing images or adding occlusion to the same image remains a target/authoring decision that must be declared. [GLTFSPEC]

Step 8 — write the AI/source/provenance chain

Record:

• ai_assist_method: what AI did (concept, patch generation, variation, cleanup suggestion, etc.),
• source_asset_ref: the supplied or synthetic source used by the exercise,
• rights_provenance_ref: where the rights status is evidenced,
• manual_edit_log: what the human changed after assistance.

Do not turn “probably generated from nothing” into provenance. If the rights/provenance field cannot be resolved from supplied evidence, preserve PROVENANCE_UNKNOWN or another non-success state.

Step 9 — change the light before trusting the appearance

One HDRI can hide roughness, normal, or value-balance problems. Test under at least two declared lighting conditions in the lab and write observations. The goal is not to guarantee renderer parity; it is to make material behavior less dependent on one flattering setup.

A changed-lighting test remains bounded evidence. It does not prove the asset will match every renderer, camera response, tone mapper, or display.

Step 10 — perform an interoperability check that is stronger than “export succeeded”

Confirm the target material model, UV-set bindings, channel semantics, packing convention, and normal convention as visible evidence. If the file exports but the target reads the roughness from the wrong channel or uses a different UV set, export success has not demonstrated correct material behavior.

Step 11 — choose a state no stronger than the evidence

Use a positive state only when all decisive evidence required by the declared target is present and consistent.

• ACCEPT: evidence satisfies the standard declared target.
• TARGET_SPECIFIC: evidence is sufficient only under a named constrained target.
• REWORK_REQUIRED: the path is viable but a repair is required before a positive state.
• HOLD: a governing target/decision or decisive review must wait.
• EVIDENCE_INCOMPLETE: required evidence is missing.
• PROVENANCE_UNKNOWN: source/rights provenance remains unresolved.
• METHOD_UNSUITABLE: the selected texturing/material path does not fit the declared target.

Every decision names at least one applicable future condition for review, migration, escalation, stop, or pivot. Do not fill all five categories mechanically. Where the exercise specifically requires a stop or pivot condition, name that condition explicitly.

Worked example: a separate synthetic tool-case, not the lab answer

Consider SYNTH-TOOLCASE-WEX-01, a small hard-surface case used only for demonstration. Its declared target is a standard glTF 2.0 metallic-roughness material with unique UVs. The ledger records one UV set, no unintended overlaps, a declared stretch/density check, separate Base Color/Metallic/Roughness/Normal/Occlusion maps, a resolved synthetic provenance record, two lighting observations, and a material-binding check.

The important part is not a prefilled verdict; it is the trace:

Now change one thing: set the Roughness image interpretation to SRGB while keeping the target contract unchanged. That mutation invalidates the color/data interpretation evidence. A learner who keeps a positive state without addressing the contradiction is no longer making a bounded decision.

Change a different thing: replace the unique layout with intentional mirrored islands. That is not automatically wrong. It forces a target question: does the declared target permit the mirror for the affected detail? If the old target still says UNIQUE_REQUIRED, the evidence and policy conflict. If the target is changed to a named runtime that allows mirroring, the decision must be rebuilt under that target rather than copied.

The executable lab uses a different fixture and never contains its final state.

Failure modes that create false confidence

1. “It looks realistic, so the UVs must be fine”

A flattering view does not expose every overlap or density problem. Repair: compare observed UV evidence to a written overlap/density policy.

2. “Every texture image is color”

Base Color and Roughness may both be images, but they carry different semantics. Repair: record the interpretation per role and verify it against the target material model. [GLTFSPEC]

3. “The AI made it, so there is no source to document”

Generation does not erase source inputs, reference assets, rights questions, or human edits. Repair: preserve the supplied provenance chain; if it cannot be resolved, do not infer it.

4. “Normal-map orientation is a cosmetic detail”

A convention mismatch can invert or distort perceived surface relief after transfer. Repair: make the convention a named field and verify it in the target pipeline.

5. “Packed ORM is always more correct”

Packing is a resource/layout decision, not a universal quality ranking. Repair: bind packing to a named runtime contract and keep channels explicit.

6. “The exporter produced a file, so interoperability is proven”

A file can export with wrong UV bindings, wrong transfer interpretation, or wrong channel mapping. Repair: validate the material contract in the target representation.

7. “The baseline passed, so the transfer case should pass”

The transfer case changes overlap and packing assumptions. Repair: hide the baseline verdict and recompute from the changed evidence.

Experienced bridge: treat texture authoring as a versioned material contract

Experienced artists usually do not need another list of UV editor buttons. The higher-value practice is keeping the authoring scene and downstream material contract synchronized without pretending they are identical.

A compact production pattern is:

1. version asset_id, geometry revision, UV-set identity, and material target together;
2. keep source texture/provenance lineage separate from generated derivatives;
3. bind each texture role to a color/data interpretation explicitly;
4. keep packing as a target-specific adapter, not as the canonical semantic meaning of a texture;
5. run one changed-lighting check before approval;
6. re-run the ledger whenever UVs, target runtime, packing, normal convention, or source provenance changes.

This makes a material portable in the important sense: not “identical everywhere,” but auditable enough to know what must be revalidated when it moves.

Alternatives and trade-offs without a universal winner

Unique UVs vs intentional mirroring. Unique UVs keep per-area texture coordinates distinct; intentional mirroring reuses coordinates for declared regions. Choose between them from documented target detail, baking, asymmetry, and runtime constraints. Do not infer a universal performance benefit from either choice; the evidence requirement is to declare intent and detect accidental overlap.

Separate maps vs packed maps. Separate maps are transparent and easy to debug. Packed maps can reduce resource bindings but couple channel conventions to the target. A packed map without a visible channel contract is fragile.

Manual-only vs AI-assisted authoring. Manual work can have clear lineage or poor lineage; AI-assisted work can have clear lineage or poor lineage. MAKNOW does not score quality by tool label. It requires source/provenance, rights status, edit history, and independent material checks when AI assistance is used.

Blender authoring view vs glTF interoperability target. Blender supports multiple UV maps; glTF 2.0 defines a bounded interoperable material representation. Keep authoring capability and interchange contract distinct, and do not infer renderer parity or a universal authoring workflow from either one. [BLENDERUV] [GLTFSPEC] [GLTFPBR]

Higher resolution vs controlled density. More pixels do not repair a poor UV layout or guarantee consistent detail. Resolution must be read together with target, density policy, memory/performance budget, and visible quality evidence.

Guided and independent practice

Guided practice — build the baseline evidence pack

Open lab://D3D-002/D3D-002-LAB1. Copy learner/evidence/evidence_pack.template.json to your own working filename, then inspect fixtures/baseline_fixture.json. Transfer only visible evidence. Do not search for a hidden answer; there is none.

Fill the decision last. Include a rationale plus at least one applicable named trigger condition from review, migration, escalation, stop, or pivot; add an explicit stop/pivot condition when the case requires it. Run:

python run_checks.py evidence/my_pack.json

The checker returns contradictions against CHECK_RULES.json. CONSISTENT means only that the pack is internally consistent with visible rules; it is not approval.

Mutation A — intentional mirroring

Apply mutation_mirrored_uvs.json. Identify exactly which field or target policy must be reconsidered. Do not say “mirroring is always invalid.”

Mutation B — Roughness interpreted as sRGB

Apply mutation_roughness_srgb.json. Trace the failure from image interpretation to material semantics, then state the minimum repair and revalidation step.

Mutation C — provenance becomes unresolved

Apply mutation_unknown_ai_provenance.json. Preserve the missing evidence as a typed non-success state; do not invent a source or permission.

Independent transfer — mirrored UVs plus packed ORM

Use transfer/transfer_fixture.json and transfer/transfer_evidence_pack.template.json. The new named realtime runtime allows intentional mirroring for the declared region and defines ORM as R=Occlusion, G=Roughness, B=Metallic. Recompute overlap, packing, and interpretation from that target. The baseline verdict is irrelevant.

Verification: another reviewer must be able to rebuild your decision

Before submitting, ask whether the pack contains enough visible evidence for a reviewer who did not watch you work.

A strong pack answers all of these:

• Which asset_id and UV set are under review?
• What overlap policy was declared, and what overlap was observed?
• What stretch and texel-density policy was checked?
• Which PBR material model is the target?
• Which map supplies each required material role?
• How is each map interpreted as color or data?
• What normal convention and packing convention are declared?
• What did AI assistance do, what source did it use, what rights/provenance evidence exists, and what did the human edit?
• What changed under at least two lighting conditions?
• What exact interoperability target was checked?
• Which evidence is missing or disputed?
• Why is the final state no stronger than that evidence?
• What future condition triggers review, migration, escalation, stop, or pivot?

The checker can catch rule contradictions. It cannot verify ownership, invent provenance, judge unrecorded visual quality, or grant release approval. Those remain human responsibilities.

Assessment and transfer

S1 — retrieval: protect the boundary

Explain what D3D-002 owns and name one adjacent outcome it does not own. Your answer must distinguish external tool/format facts from MAKNOW design authority.

S2 — application: baseline artifact

Build a complete UV-PBR Texture Set and Provenance Ledger v1 from the synthetic baseline fixture. A positive state is not required; an evidence-bounded state is. Missing decisive fields and unsupported success are blocking failures.

S3 — diagnosis: unique to mirrored

Diagnose the mutation that changes the UV layout from unique to intentional mirroring. Identify the invalidated assumption, its consequence, and the smallest target/evidence change required before a new state can be justified.

S4 — transfer: realtime packed ORM target

For the second asset, recompute the decision under the named runtime that intentionally uses mirrored UVs and packed ORM. Show the channel binding, color/data interpretation, UV policy, provenance, lighting, and interoperability evidence. Copying the baseline state is a blocking failure.

All routes are graded against the same dimensions: identity/contract, exact evidence binding, negative evidence, bounded decision, and transfer. A beautiful screenshot cannot compensate for missing decisive evidence.

References, freshness, and claim boundaries

The external sources in this lesson are intentionally narrow:

• [BLENDERUV] Blender 5.2 LTS manual, UVs & Texture Space — supports the fact that meshes can use explicit/multiple UV maps. It does not define the correct production seam/overlap/density policy.
• [BLENDERUVUSE] Blender 5.2 LTS manual, UV Map Node — supports selecting a specific UV map for material texture coordinates in Blender. It does not prove UV quality.
• [GLTFSPEC] Khronos glTF 2.0 Specification (2.0.1) — supports metallic-roughness material roles, texture-coordinate-set binding, and core transfer/channel semantics. It does not guarantee renderer parity or production approval.
• [GLTFPBR] Khronos glTF PBR overview — supports the bounded interoperable PBR model context. It does not define MAKNOW evidence thresholds.

These official sources were rechecked on 2026-09-06. Their cited technical semantics remain within the lesson's stated claim boundaries. The next scheduled review is 2026-10-18, or earlier if the cited Blender/glTF semantics materially change.

Everything about required provenance fields, state vocabulary, review triggers, and acceptance logic is explicitly MAKNOW DESIGN authority. Keep that distinction visible whenever a source is cited.