Clarify orthonormalization policy for normals and tangents#287
Open
portsmouth wants to merge 8 commits intoAcademySoftwareFoundation:dev_1.2from
Open
Clarify orthonormalization policy for normals and tangents#287portsmouth wants to merge 8 commits intoAcademySoftwareFoundation:dev_1.2from
portsmouth wants to merge 8 commits intoAcademySoftwareFoundation:dev_1.2from
Conversation
portsmouth
commented
Feb 4, 2026
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 |
Contributor
Author
There was a problem hiding this comment.
Just to note, this is equivalent to Gram-Schmidt orthogonalization. We might as well state that.
Done in 15bf2e1
…malization_policy
…m/portsmouth/OpenPBR into clarify_orthonormalization_policy
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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):
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 [*]):
[*] 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.