Yes sorry, I edited my post because the problem wasn't actually occuring in TV, not because it was occuring in Blitz3d. It doesn't occur in either if I don't use quaternions, nor if I don't use Euler, only if I use both. But SEPARATELY.
Yes, of course you get errors if you start actually transforming the entity, but I'm NOT transforming anything. I just leave it at 0,0,0 which is 1,0,0,0 in Quaternion orientation. Both 1 and 0 can be realized correctly in floating point math, so there is nothing to be incorrectly rounded by floating point inaccuracy. I should be setting and getting it at 0,0,0 and 1,0,0,0 over and over.
Furthermore, I'm not converting between the two though, am I? I'm getting Euler, setting Euler, and separately getting Quat, setting Quat. And again, the only values they should ever have are 1.0 and 0.0 which can both be expressed as floating point numbers.
And further proof for those who doubt me ( even though the fact that all other axes hold the same values but are unaffected should be proof enough ) here's an interesting tidbit. If I create a mesh in TV3D and don't set it's rotation, orientation or matrix, guess what? It isn't at 0,0,0 at all.. it's at 0.01978234,0,0 and guess what the first value is when the bug occurs in my above example? Yes, that's right, it's 0.01978234
Now I don't know about you, but it seems a little bit coincidental to me that all meshes are initially rotated to exactly the same floating point value ( to 8 decimal places, no less ) when you don't do anything as they are with the above code.
That's what? A one in 10,000,000 chance? 30,000,000 if you consider that it could have happened on two other axes, I guess. It just happens to be on the x coordinate.
Yes, of course you get errors if you start actually transforming the entity, but I'm NOT transforming anything. I just leave it at 0,0,0 which is 1,0,0,0 in Quaternion orientation. Both 1 and 0 can be realized correctly in floating point math, so there is nothing to be incorrectly rounded by floating point inaccuracy. I should be setting and getting it at 0,0,0 and 1,0,0,0 over and over.
Furthermore, I'm not converting between the two though, am I? I'm getting Euler, setting Euler, and separately getting Quat, setting Quat. And again, the only values they should ever have are 1.0 and 0.0 which can both be expressed as floating point numbers.
And further proof for those who doubt me ( even though the fact that all other axes hold the same values but are unaffected should be proof enough ) here's an interesting tidbit. If I create a mesh in TV3D and don't set it's rotation, orientation or matrix, guess what? It isn't at 0,0,0 at all.. it's at 0.01978234,0,0 and guess what the first value is when the bug occurs in my above example? Yes, that's right, it's 0.01978234
Now I don't know about you, but it seems a little bit coincidental to me that all meshes are initially rotated to exactly the same floating point value ( to 8 decimal places, no less ) when you don't do anything as they are with the above code.
That's what? A one in 10,000,000 chance? 30,000,000 if you consider that it could have happened on two other axes, I guess. It just happens to be on the x coordinate.