Skip to content

Clarify orthonormalization policy for normals and tangents - #287

Open
jamportz wants to merge 8 commits into
AcademySoftwareFoundation:dev_1.2from
jamportz:clarify_orthonormalization_policy
Open

jamportz wants to merge 8 commits into
AcademySoftwareFoundation:dev_1.2from
jamportz:clarify_orthonormalization_policy

Conversation

@jamportz

@jamportz jamportz commented Dec 9, 2025 •

Copy link
Copy Markdown
Contributor

To address #274, I updated the language in the spec to be more explicit that the input normals and tangents are expected to be made orthonormal (if it is not known that they already are):

image

For a reference to the concept of "2D flow maps", I cited the paper "Water Flow in Portal 2" by Vlachos et. al (2010), as this seems to have the nicest discussion I could find of this.

It also seems to make sense to connect the microfacet discussion with the normal and tangent inputs more explicitly (e.g. the normal inputs are controlling the macronormal [*]):

image
image

[*] Actually, technically the "mesonormal" in Heitz' nomenclature (meaning the center of the micronormal distribution, which does not necessarily coincide with the geometric macronormal, e.g. in LEAN/LEADR mapping), but it seems too technical/academic to use this term here.

Comment thread index.html Outdated

The perturbed normals and tangents will of course be specified by input textures (or possibly procedurally). As noted in the Metadata section, the particular parametrization which maps the contents of the texture to the perturbation of the normal or tangent in the shading frame is not defined in the model itself, as this can be done in multiple ways. It is instead just assumed that the material is packaged with metadata that makes this mapping unambiguous.
It is _not_ required that the resultant input **`geometry_normal`** $\mathbf{N}_B$ and **`geometry_tangent`** $\mathbf{T}_B$ are strictly normalized and orthogonal (and similarly for the coat normal and tangent).
For example reconstruction filtering techniques such as texture filtering may cause the interpolated normal to not be normalized. However, we _do_ require that the implementation should (if not already ensured) ensure orthonormality of the final vertex shading frame of the BSDF, by applying

@jamportz jamportz Feb 4, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to note, this is equivalent to Gram-Schmidt orthogonalization. We might as well state that.

Done in 15bf2e1

@najibna najibna left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Gram-Schmidt policy is the useful part: inputs need not already be orthonormal, but the BSDF shading frame must be.

Nits: “pertubed” should be “perturbed”, and $\mathbf{T}_B \rightarrow \mathrm{normalize}(\mathbf{T}_B - (\mathbf{N}_B\cdot\mathbf{T}_B)\mathbf{N}_B)$ is only correct once $\mathbf{N}_B$ is unit length. Please state the order (normalize N, then project T) and what to do if T is parallel to N.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants