Implementation of glRotate(...) identical to the fixed function variant


In our own math lib we are implementing OpenGLs glRotate(..). It works, but differs slightly (never before the 8th decimal) from the (fixed function) glRotate(..).

I was just curious if "the most true" implementation of glRotate(..) is available. I'm now using the one attached.

I could imagine...
- doubles are used internally to store temporary results.
- sin/cos/sqrt implementations are slightly different.

Kind Regards,
Daniel Dekkers
void Mat4::rotate( float angle_deg, float x, float y, float z)
        float xx, yy, zz, xy, yz, zx, xs, ys, zs, s, c, one_minus_c, scale, angle_rad;
        Mat4 m;
        angle_rad = angle_deg*(M_PI/180.0);
        s = sin(angle_rad);
        c = cos(angle_rad);
        xx = x * x;
        yy = y * y;
        zz = z * z;
        scale = sqrtf(xx + yy + zz);
        if (scale < 1.0e-4)
        scale = 1.0 / scale;
        x *= scale;
        y *= scale;
        z *= scale;
        xy = x * y;
        yz = y * z;
        zx = z * x;
        xs = x * s;
        ys = y * s;
        zs = z * s;
        one_minus_c = 1.0 - c;
        m[0] = (one_minus_c * xx) + c;
        m[1] = (one_minus_c * xy) + zs;
        m[2] = (one_minus_c * zx) - ys;
        m[3] = 0.0;
        m[4] = (one_minus_c * xy) - zs;
        m[5] = (one_minus_c * yy) + c;
        m[6] = (one_minus_c * yz) + xs;
        m[7] = 0.0;
        m[8] = (one_minus_c * zx) + ys;
        m[9] = (one_minus_c * yz) - xs;
        m[10] = (one_minus_c * zz) + c;
        m[11] = 0.0;
        m[12] = 0.0;
        m[13] = 0.0;
        m[14] = 0.0;
        m[15] = 1.0;
        *this = (*this)*m;

Open in new window

Who is Participating?
And with regards to the exact implementation of the glRotate function - that is quite platform dependent. Not only in the source code, but also in the compiled binary, the standard libraries, as well as the hardware. Different platforms will have slightly different results.

But again : that's entirely normal and expected when using floating point types. The trick is to ignore the extra digits, and focus on the first few decimal digits only (keeping in mind that the more calculations you perform, the bigger the accumulated error can become).
32bit IEEE754 float's really only have 7 decimal digits of precision. So anything after that depends entirely on the calculations.

Small changes can have a big effect.

Or in other words : what you observe is normal for floating point types, and can't be avoided.
DoZo1971Author Commented:
Still, it would be nice to for instance, see nVidia's calculation written down.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.