I do not see why float matricies in shaders would not result in pixel precise rotations. What do you mean by pixel precise rotation and why you think you are not having it?

This is generally not possible with any representation, for the simple reason that 0.1° ? 0.0062831853, which is not representable using IEEE 754 math. Also, its cosine is not representable. Therefore, error must occur, and error must accumulate.

Quaternion multiplication has fewer operations, and quaternions have fewer components, so there is less opportunity for error to accumulate, but still they cannot be "perfectly accurate" if you combine a thousand of them. But even if you only keep adding very small values to a single float, and convert the accumulated value, you will see error accumulation.

The most accurate solution to your specific problem (doing 1000 little rotations around the y axis, or some axis) would be to use fixed point math to store the intermediate angles of rotation around a vector (in that case [0,1,0]), and convert these to either matrix or quaternion at ever frame just for the purpose of doing the model transform when rendering. Adding up the integer 1 a thousand times gives exactly 1,000 (with very few, entirely irrelevant exceptions!), and doing 1,000 or 100,000 little rotations will be "pixel perfect", except for unavoidable rounding errors.
The unavoidable rounding errors are the ones occuring during the calculation of the cosine and due to the cosine usually not being exactly representable as float, and rounding errors that occur while the GPU does the transform, on which you have little or no influence.

cool. thats the info i needed. thanks!

saved me some time messing with quats for improved accuracy.

i've been doing games on and off for over 20 years. it sucks that after all that time you still have to worry about numerical precision and use stuff like fixed point. the more things change, the more they stay the same...

shifted bit fixed point, i feel like i'm back tuning assembly code blitters for sprite based 3d engines (a la wing commander 2).

You're still going to get rounding error if you use fixed point and rotate around local axes... it's the same as using a quaternion and quantising your orientation really... and fixed point is slower than floating point these days...

If you are only using pitch and yaw fixed point would be exact (but again not as efficient). And you get the nasty singularities looking straight up or down.

I challenge you to turn your car around exactly 360.0000 degrees though, and that's just with one axis of rotation.

You're still going to get rounding error if you use fixed point and rotate around local axes... it's the same as using a quaternion and quantising your orientation really... and fixed point is slower than floating point these days...

yes, i just thought of that in this related thread (which inspired this thread)...

http://www.gamedev.net/topic/640230-how-to-re-orthogonalise-vectors/

If you are only using pitch and yaw fixed point would be exact (but again not as efficient). And you get the nasty singularities looking straight up or down.

Yes, i remember that technique from "Building a flight simulator in C".

I challenge you to turn your car around exactly 360.0000 degrees though, and that's just with one axis of rotation.

this is what i'm counting on - that the drift and inaccuracy won't be too bad. while you may be a few pixels high or low after doing a 360 in your X-wing, odds are you'll have better things to do than notice. and as long as the drift is small, the player can still "know" the target is 120 degrees left (around local y) from situational awareness, turn 120 left, and shoot, without going "how'd it get up there / down there? it should be right in front of me!".

by situational awareness, i mean the way that every good fighter jock carries around a local coordinate system in their head, and they track (or estimate) targets in it, even when out of view. so when i see my opponent fly past me over my left shoulder, based on his angle and speed and time elapsed, i can track him (estimate his position) in my mental coordinate system (my mental picture of the battlefield space) despite his not being in view. that how i "know" he's about 120 degrees left. if the drift from "turning blind" like that is too great, then the player's mental representation of the battlespace and the simulation's representation will no longer match up sufficiently, because physics works perfectly in the player's mind, but the simlation's physics suffer from numerical inaccuracy when turning. this disconnect between the two, if too great, can ruin a flight sim.

As soon as you use the term "he's about 120 degrees left" you admit innacuracy.

It's not worth the pain of fixed point (I know, I used to do PS1 games) for a performance drop and no overall gain in accuracy.

If fixed point was a panacea it would be implemented in hardware as standard.

Yeah, in maths libraries perhaps. My point was can you do it in the real world...