gltfpack: Introduce optional floating-point normal quantization #634
Conversation
This file contains 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
Usually normalized integer storage is optimal for normals; however, morph target deltas require a [-2, 2] storage range. During quantization we clamp them to [-1, 1] which ends up usually working fine, however there are some use cases where this doesn't work well when the normal deformation is extreme. This can be solved by scaling normals by 0.5, so we'll use [-0.5, 0.5] range for base normal and [-1, 1] range for normal deltas. This usually works fine with any glTF renderers as they normalize the normal (which is more or less required for handling non-uniform scale transforms). However, the validator treats files like this as invalid. Validator doesn't process files with -c/cc so technically we could fix this when compression is enabled, but that would result in an odd mismatch where compression *improves* quality instead of degrading it... For now we introduce an option to use floating point normals, quantized using reduced mantissa and stored, when compression is enabled, using exponential filter. Similarly to -vtf, this isn't normally the recommended mode but there might be cases where it's a desireable tradeoff.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Usually normalized integer storage is optimal for normals; however, morph target deltas require a [-2, 2] storage range. During quantization we clamp them to [-1, 1] which ends up usually working fine, however there are some use cases where this doesn't work well when the normal deformation is extreme.
This can be solved by scaling normals by 0.5, so we'll use [-0.5, 0.5] range for base normal and [-1, 1] range for normal deltas. This usually works fine with any glTF renderers as they normalize the normal (which is more or less required for handling non-uniform scale transforms).
However, the validator treats files like this as invalid. Validator doesn't process files with -c/cc so technically we could fix this when compression is enabled, but that would result in an odd mismatch where compression improves quality instead of degrading it...
For now we introduce an option to use floating point normals, quantized using reduced mantissa and stored, when compression is enabled, using exponential filter. Similarly to -vtf, this isn't normally the recommended mode but there might be cases where it's a desireable tradeoff.
Fixes #632.