The original implementation had the same mistakes than the ray-sphere
intersection.
Added two new 'out' parameters to return both intersection ponits.
Changed the implementation to the geomethric method.
Changed the original analytic method to a geometrical.
The errors in the original intersection calculation:
The function has a sphere center parameter, but ignores it and assumes
that the sphere is in the origo.
It calculates the length of the ray direction vector, but later on uses
this vector as a unit vector.
The position calculation is simply wrong. It multiplies the direction
vector with the radius of the sphere instead of the calculated
intersection distance.
The quadratic equation solving could be improved too:
There should be an early exit for negative discriminant.
The naive implementation sould be changed to a floating-point
specialized one.
NB: glm::detail::tmat2x2::_inverse() incorrectly swaps all components instead of only main diagonals:
A = ⌈a b⌉
⌊c d⌋
(using standard representation). _inverse() on A incorrectly gives the order
⌈ d -c⌉
⌊-b a⌋
(swaps both diagonals) where it should be
⌈ d -b⌉
⌊-c a⌋
(I am leaving out division by the determinate for clarity).
Also, glm::inverse() in `glm/core/func_matrix.inl` is correct for 2x2 matrices and shows the mistake of _inverse().
The unit tests do not appear to test division of a mat2 by a mat2 (where this could arise).
The previous fix only worked correctly for values where
the most significant enabled bit was the only enabled bit.
This change changes the implementation back to using clz,
but so that the result is changed with additional arithmetics.
There is still at least one known limitation with regards
to acceptable input types, but this is documented in the code.
Before this fix, the GCC specific MSB function returned the number
of leading zero bits in the parameter value. With this change,
the number of trailing zero bits is returned instead.
I am not entirely sure if this fix is correct, because I could not
find a clear reference about what findMSB in GLSL is really
supposed to return with some concrete input value.
At least the result is now consistent with the GLM_ARCH_PURE
implementation of glm::findMSB.
This pretty much reverts the fix done in commit
1ed0e3865b
This temporarily breaks log2 for GCC in cases where GLM_FORCE_PURE
is not defined. The workaround introduced in commit
1ed0e3865b seems to rely
on getting invalid results from the nlz function.
Broken nlz is caused by a broken findMSB function for GCC.
A fix for the findMSB function should be available in a nearby
separate commit.
