q_math: do tracing in id Software/J.M.P. van Waveren's QuatFromMatrix() implementation like Martin John Baker's one did, fix model distortion with GCC 14

[illwieckz]

Do tracing in id Software/J.M.P. van Waveren's QuatFromMatrix() implementation like the one we have by Martin John Baker's did, fix model distortion with GCC 14.

Fix #1527:

• Model distortion bug with GCC 14 #1527

It adds +1 to the first trace

Fix Unvanquished/Unvanquished#3140:

• Visual bug on Granger Maze map - Unvanquished 0.55 Unvanquished/Unvanquished#3140

What's curious is that the Martin John Baker's page says they also removed the +1:

// I removed + 1.0f; see discussion with Ethan

But it also says (but we didn't use any epsilon):

// I changed M_EPSILON to 0

The said “discussion with Ethan Tira-Thompson” says:

Hi Martin,

I was looking at the matrixToQuaternion page, and I think the "Better code" and "C++ code" sections may have a problem with numerical stability as Tr + 1 may approach 0 in some cases. The test for greater-than-epsilon helps, but a better solution may be found in the implementation from the Wild Magic package by Dave Eberly:
http://www.geometrictools.com/LibFoundation/Mathematics/Wm4Quaternion.inl
(See "FromRotationMatrix" function)

There, they compare Tr > 0 (instead of Tr+1 > 0) for the initial conditional, thus avoiding getting close to 0 in the 0.5 / sqrt(Tr + 1) which follows it.

Do you have any thoughts, does this make sense to you? The implications of falling into the 'else' clause are the main concern here, but that seems safe, and appears to work in practice.

Thanks!

Then follows a lengthy discussion about “danger of division by zero or square root of a negative number” and “danger of division by zero or square root of a negative number”, maybe it was safe to rule out those concerns with no fast math but we need to take care of this with fast math?

Actually using that +1 means one compute is twice the same, so it may even be faster.

On a side note, the document by id Software/J.M.P. van Waveren mentions this:

The above routine also uses a fast reciprocal square root approximation, referencing works like the Chris Lomont one I quoted there when improving Q_rsqrt():

• Some improvements around Q_rsqrt() #1458

So I made the code also use Q_rsqrt().

[illwieckz]

It's also worth noting that the id Software document also provides some SSE implementations, it may be interesting to look at them.

[illwieckz]

So it looks like the same bug was affecting different binaries:

• native cgame (model bug)
• native engine (portal bug)

[illwieckz]

So, with grangermaze map on -176 204 203 -44 38 viewpos and a native GCC 14 engine and game build, I can reproduce both bugs:

• Model distortion bug with GCC 14 #1527
• Visual bug on Granger Maze map - Unvanquished 0.55 Unvanquished/Unvanquished#3140

Before:

After:

[slipher]

LGTM

I won't dive into the math here since there is really no need to be using the QuatFromMatrix function in either case... For the cgame model rotation we should just use only matrices (without the pointless round trips matrix -> quat -> matrix). The other caller, QuatFromAngles, ought to be constructing the quat directly (there is a commented-out implementation for that) instead of constructing a matrix and converting from a matrix.