From what I understand, this is quite a mess!

• it can be used in dotProduct with PrimLightDirection in computeSpotFactor
  but then, the cosAngle dotProduct is negated (after negation, it is expected positive, > minCos)
• it can be used in dotProduct with PrimVtxNormal in shadeVertex for diffuse part
  again, the cosAngle dotProduct is expected to be positive,
• after being copied to l2vSpecDir and transformed into specular direction, it is also used for specular part
  again, the cosAngle dotProduct is expected to be positive,

The light direction (pointed by PrimLightDirection offset) is used as parameter GL_SPOT_DIRECTION for the glLightfv function.
>From what I understand, it sets the main direction of propagation of light (from light source which is at top of the cone, to center of enlighted surface which is a circular section of the cone).

Thus, the 1st usage suggests that the l2vDirection is vertex to light and not light to vertex as the name does NOT tell!
The 2nd and 3rd usage confirm this - if ever the normal of vertex is oriented outside the visible face...

This would explain the -1*scale...

But for source at infinite distance, (lightFlags anyMask: FlagDirectional), the light to vertex direction is constant and equal to the PrimLightDirection, so that's what is simply copied in computeDirection...
I perfectly understand that, EXCEPT THIS, there is no -1 scale in this branch???

So I definitely understand nothing to this code, this is highly contradictory.
Maybe it only works for (vbFlags bitAnd: VBTwoSidedLighting) which enables a cosAngle of opposite sign?

Despite knowing that the code is incorrect, it's very hard to modify a code that one does not understand, there is a high risk of breaking the fragile edifice.

What is required is test cases of some sort for non regression. Des that only exist?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.