Codesnippets > 3D-snippets

Quaternion Based 6DOF Camera Lib

<< < (2/6) > >>

codegit:
8) 8) 8) 8) 8) 8) 8)

Hemlos:
Love it man...love it.  :nw:

Curious, how do we attach an object to the camera rotated orientations?
ie a cockpit for a plane.

Is there a way to convert the quats to glbasic rotations?
Correct me if im wrong here, but i think glbasic is eulers.
A shot in the dark, i think we need some kind of conversion i imagine.

edit:

Really i appreciate you sharing quaternion math with us.
I think i have the hang of it now.

:nw:

bigsofty:
No problem buddy my pleasure.

Hurt my back yesterday lifting a new washing machine... real silly... so I'm not on my computer much today :sick:

There is still room to make this a more fully fledged quaternion library. No SLERP implementation yet, matrix<->quat routines etc... but its a start. I'm kinda busy with a 2D game for now though.

Hemlos:

AHHHHH
Quaternions have an issue, the math fails.
It is a well known fact, as ive researched this math issue on the web.
So many people have issues with it.

I figgured out why it fails, on my own, through testing(damn im good):

It fails because the magnitude of the identity matrix changing....this is why speeds change, and ultimately crash a program.
The internal direction vectors, forward,right,up (quaternion object identity matrix) are always being altered, due to the imperfection of computers number limits!
You see, numbers can only be so precise(right hand precision), and this is where the problem starts.

And i have been working on a real solution..........and if i get this right, im going to publish a book on 3d quaternion math LOL :)

So the solution would seem to be to limit the "smallness" of the numbers.
And so, the numbers need to be rounded, which i have done.
Solution, maybe, well this is true, but only partially.
Because of the nature of quaternion math, the math must be precise, or we get an explosion in the identity magnitude.

So, rounding the small numbers will change the magnitude of the identity matrix, to spread out still!

WOW, this is why the math will fail........ again.

Ive seen a "solution" on the web, they said to normalize the quat every now and then.
But if you designate the object to have forward right and up magnitudes spread out, it increases the magnitude of motion, which is cool because you can regulate speed.

If you do this, then normalizing is not the solution, because it crunches your internal vectors, messing up your original identity.

I have been studying the math....and testing.
And the real solution is going to be pretty complex....
What needs to be done, is the quaternion math functions internally, needs to be given a tolerance, of changes in magnitude of the quaternions.
The functions must be able to regulate the magnitude spread, keeping it very close to the original identity.
This will be complicated...im not even sure if i can do this type of algorithm.

I will be back this week to let you know if i was successful in creating this "regulator".

Hemlos:
Im sSO sorry buddy.......i didnt mean to delete your post.
I will place your response at the bottom of this message........

--- Quote ---I never noticed any cumulative errors but a quaternion normalization function already exists, try this(another alternative is just to normalise the camera vectors in TCamera)...
--- End quote ---
The culmative error occur when you scale the identity up.
ie. cam.l, cam.u, cam.r, each are 1.0, but this naturally changes as time goes on because of rounding.
for instance, if you set these 3 values to 2.0, then you will move twice as fast.
If you move around in 3d at a scale of 2.0, as a max/min speed scalar, then it should never go above or under that, and normalizing doesnt solve it.

--- Quote ---Code:
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
If this solves your problem, I'll add it to the above lib.
--- End quote ---

The error causes unproportional scalars as a result, this is the problem with quaternions.
No matter what scalar values you set in your identity, not even 1.0, you can not regulate the original scalar by normalizing.
Here is why, if you have the real number quaternion vector with these errored values,
(Where, all 3 identity original speed scalars were all equal to one):
.l=1.0
.u=1.0
.r=4.0 //this is the culmulating scalar in this case, for whatever reason, not important here.

If those were your output values, and you try to normalize all 3 at once, you end up with something like this:
.l=0.25
.u=0.25
.r=0.888

Obviously this is an error, these 3 scalars MUST all go back to 1.0 speed scale, or something close to it.

You can not normalize all 3 scalars back to the original identity scalar if they are not proportional, can you?

This is what people all over the world dont understand, is the solution is in regulating the the current vector scalar, to match the original identity scalar size.
Normalizing the current output, causes unproportioinal output....and this causes unproportional vector velocity speed outputs.

Im no mathematician, however, i do now have a solid understanding of quaternion math because i spent a few hours analyzing the inputs versus the output values of every single value within the algorithms.

I deleted the last post from softy by accident, here is the original message:

--- Quote ---I never noticed any cumulative errors but a quaternion normalization function already exists, try this(another alternative is just to normalise the camera vectors in TCamera)...

Code:
W = quaternion_normalize(W)
each time the W (notice its a Capital) is calculated.

so...

Code:
W = quaternion_mult(W2,W1)
becomes...

Code:
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
If this solves your problem, I'll add it to the above lib.

--- End quote ---