The primary means to encode standard normal maps, which encode just orientation, is to store unit length vectors. ASTC and other formats (e.g. BC5n) exploit the knowledge that the vector is unit length to store in the texture using just two components. The third can be recovered programmatically in shader code. This has a number of advantages for this use case and should always be the preferred method for storing two component normals:
- Only two non-correlated components (storing 3 non-correlated components is painful).
- Only two endpoint components to store, freeing up bitrate.
However, there are more advanced use cases for normal maps (e.g. see M. Toksvig's paper) where the normal stored is not unit length, because the length can be used to encode other properties (e.g. a normal density function). These normals must be stored directly as three components, as we are no longer have the apriori knowledge to reconstruct Z programmatically. This feature request is to add a three component normal map mode to support these use cases. Primarily this means:
- Add a new command line option for 3 component maps (
-normal3)
- Add a format-aware error function which aims to minimize angular error and vector length error.
- TODO: Do we need a "weight" method to allow the user to configure the trade off between angular error and length error?
Note: Three component normals are difficult to encode as you effectively end up with three non-correlated channels, which ASTC cannot encode directly. Three component maps are therefore expected to be lower quality than two component maps in scenarios where two component maps could have been used.
The primary means to encode standard normal maps, which encode just orientation, is to store unit length vectors. ASTC and other formats (e.g. BC5n) exploit the knowledge that the vector is unit length to store in the texture using just two components. The third can be recovered programmatically in shader code. This has a number of advantages for this use case and should always be the preferred method for storing two component normals:
However, there are more advanced use cases for normal maps (e.g. see M. Toksvig's paper) where the normal stored is not unit length, because the length can be used to encode other properties (e.g. a normal density function). These normals must be stored directly as three components, as we are no longer have the apriori knowledge to reconstruct Z programmatically. This feature request is to add a three component normal map mode to support these use cases. Primarily this means:
-normal3)Note: Three component normals are difficult to encode as you effectively end up with three non-correlated channels, which ASTC cannot encode directly. Three component maps are therefore expected to be lower quality than two component maps in scenarios where two component maps could have been used.