Normal matrices are overrated
Conversation
Replying to
... wow, a lot of people enjoy math!
If you're looking for an intuitive explanation for why normals need to be transformed by scale^-1 (IMO that's more important than inverse-transpose formulation as it's easier to understand and apply widely!), here's one way to do it:
1
24
Replying to
In instancing context this means you only need one matrix, not two, so it's a memory vs ALU tradeoff. As a side note, if you have decomposed transform (e.g. quaternion rotation + vector scale), you don't even need to do this - just `rotate(normal / scale)` works as shown above.
1
5
Show replies
Replying to
It seems the length of transformedNormal doesn't matter, only the direction, so couldn't we scale everything with dot(RX, RX)*dot(RY,RY)*dot(RZ,RZ) and
do *=vec3(dot(RY, RY)*dot(RZ, RZ),dot(RX, RX)*dot(RZ, RZ),dot(RX, RX)*dot(RY, RY)) instead of the divisions? -3 rcp, +3mul.
1
12
Replying to
Yup - that's ~equivalent! Probably a touch faster.
Also handles scale=0 better unless the entire vector is 0.
Good call :)
2
Replying to
That’s a very neat trick, haven’t seen it before!
1
Replying to
interesting...
since advent of normal mapping, we've always omitted normals from vertices and stored both tangents instead.
transform/interpolate as ordinary vectors without special matrices, reconstruct normal in pixel shader.
(supports any kind of transform, e.g. shearing)
1
2
3
Replying to
It worked great so far but today is a sad day. I've got a matrix with a shear transform...