Keep a transformed normal perpendicular to the transformed surface

State the relationship that must survive

Physically Based Rendering explains why surface normals require the inverse transpose of a nonsingular transform rather than ordinary vector transformation. The reason is preservation of perpendicularity to transformed surface tangents.

Ask the asset owner which coordinate spaces the supplied values connect. A plausible-looking column of numbers is not useful without its source and destination. Keep the intended geometry, viewing setup and material treatment unchanged while investigating the relationship. Otherwise, a visually attractive revision could hide the calculation error rather than explain it.

Choose a safe synthetic surface before diagnosing a real product. Record the intended surface directions and the proposed change explicitly. The purpose is to create a known-answer check that a technical reviewer can repeat, not to decide whether the product should be wider, thinner or smoother. Those are separate creative and product decisions.

Compare two calculations on the same surface

Use tangents t₁ = (1, 1, 0), t₂ = (0, 0, 1), and normal n = (1, −1, 0). Both original dot products are zero. Scale with A = diag(2, 1, 1): transformed tangents are (2, 1, 0) and (0, 0, 1). Applying A directly to n gives (2, −1, 0), whose dot product with the first tangent is 3.

Applying A⁻ᵀ instead gives (0.5, −1, 0), perpendicular to both transformed tangents. Its unit direction is (1, −2, 0) / √5. Normalizing the wrong candidate gives (2, −1, 0) / √5, still not perpendicular: its first dot product is 3 / √5.

Keep the failed candidate beside the successful one. A record that shows only the correct formula can be copied without revealing the misunderstanding that caused the incident. The paired calculation explains why an apparently reasonable repair, making the vector length one, does not resolve the actual discrepancy.

The executed Python checks evaluate both tangents, both candidate directions and their lengths. A second derivation uses the plane equation before and after scaling. This is mathematical evidence about the invented surface, not a rendered lighting comparison. It does not identify the cause of a real image until the receiving implementation is examined.

Keep singular handling separate from the ordinary case

The inspected three.js Matrix3 source constructs its normal matrix from the upper-left 3×3 block, then inverts and transposes it. Its inversion routine returns a zero matrix when the determinant is zero. This is documented implementation behavior, not a valid inverse for a collapsed transform.

For a separate fixture, diag(2, 0, 1) is singular. The review gate rejects it before applying the inverse-based rule. A zero fallback cannot supply a unit normal. No three.js runtime or renderer was executed; the local test checks the singular gate and the nonsingular arithmetic independently.

Ask the receiving owner what the actual application does in this condition and whether that behavior is intentional. Do not replace a failed calculation with a convenient constant and call the asset accepted. Preserve the problematic input and describe the blocked operation so the owner can decide whether the intended construction or its implementation must change.

Use the failure case to define a stop condition, not a universal recovery policy. A legitimate special-purpose representation may require a different analysis, but that does not make the current inverse-based result valid. Keep an unresolved exception visible rather than quietly treating a numerical placeholder as physical evidence.

Close with the correct receiving evidence

Prepare a compact record containing the original surface, transformation, candidate outputs, dot-product checks and failure disposition. Keep the coordinate-space labels attached to every vector. The reviewer should be able to identify which step disagrees without guessing whether the values came from an authoring tool, an exporter or a later viewer.

Request a controlled receiving comparison only after the mathematical contract is clear. The technical owner should retain the same geometry and approved appearance settings while inspecting the affected path. If the result still differs, preserve that observation and continue diagnosis instead of asserting that the fixture proved the whole pipeline correct.

Have the responsible product and creative owners judge the actual delivered representation. Perpendicularity is a specific calculation property, not proof of physical accuracy, suitable lighting or a faithful material. A final acceptance record must distinguish that narrow check from the wider production decision and name any untested receiving route.

Retain the failed normalization example when the transformation code or export configuration changes. It gives future reviews a precise regression question. This exercise changes no mesh, source file or application setting and supplies no blanket visual approval; it makes a hidden coordinate relationship inspectable.

Make the reasoning concrete.

A fictional product-viewer team changes an object’s proportions for a diagnostic copy and sees an unexpected highlight. Someone proposes normalizing all supplied directions and approving the most attractive preview.

The team requests the bounded calculation evidence and keeps the actual production asset unchanged.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Spaces

   Which source and destination spaces label the values?

2. Surface

   What independently known directions define the fixture?

3. Candidates

   What exactly differs between the compared calculations?

4. Failure

   What input must stop the inverse-based procedure?

5. Receiver

   Which actual viewing evidence remains untested?

Watch for the wrong conclusion.

• Combining several appearance changes during diagnosis.
• Treating a numerical placeholder as a valid result.
• Claiming product accuracy from a mathematical fixture.

Sources & scope

Original synthetic vectors and production-review procedure. Named sources support the transformation and implementation distinctions. Only local numerical checks are executed; no renderer, real product alteration or visual acceptance is claimed.

• Physically Based Rendering: Applying Transformations →Primary rendering textbook · Supports: Supports the perpendicularity-preserving normal transform.
• three.js: Matrix3 implementation →Primary implementation source, inspected 7 November 2026 · Supports: Supports normal-matrix construction and explicit singular fallback behavior.