Calculating the future position of an object with 6dof

Game Mechanics Artificial Intelligence
#1

Hi

I have objects that have 6 degrees of freedom. Give a start position, a time the object was at the position, a vector describing it’s current translational movement and 3 angles describing it’s rotation in degrees per second, what is the best way to calculate it’s position in say 3256 milliseconds?

All the time there is only a few tens of ms then an approximation is ok, I did this by creating a matrix3f from the eular angles and multiplying the original location’s rotation matrix with that one. Then I took the translation vector, scaled it so that it was 1/100 of the lenth for a 10ms movement, multiplied it by the new rotation matrix and added it to the original translation.

This is fine for small increments, but I am now potentially having to catch up by maybe as much as a few seconds, and this shows up the difference badly.

I have thought about just doing the calculation a few hundred times in 10ms increments to catch up, but I figure there must be some horendously complicated mathmatical way of doing it properly :).

I’ve had a quick hunt around on google and not found anything that I can relate to the problem.

Anyone have any ideas how to do this properly, not just bodge it? :slight_smile:

Cheers

Endolf

#2

Is the rotation thats being described a world rotation or a local rotation? Because local rotations simply have no net effect on the position…

Would that equate to speed? If so, you could verlet integrate to get final position given a delta time, then multiply by the rotation if in world space. With euler angles, you can just verlet integrate over the angular momentum to obtain the new angle given delta time.

In short, verlet integrate each euler angle to obtain new angles, store in mat3x3. Verlet integrate position, multiply position by mat3x3.

That should work i think :slight_smile:

Edit: heres a good article about verlet integration: http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml

DP

#3

That looks like a good article, and is great for systems where the acceleration is 0. But I have potentially thrust in 3 axis, so I end up back having to do a large number of small steps.

Image a space ship sat at 0,0,0 facing +Z with local +Y being world +Y, ie, rotations are the identity matrix.

Currently I have the object with a rotation about the x axis, and a velocity in the object local +Z axis. The rotation is set to do 1 complete rotation in 1 minute and the local +Z velocity is say 6m/s.

After 1 minute, the ships should have done a complete circle, loop the looping, ending up back where it started having completed a circle with a radius of 360 meters.

Using either my original technique, or the one you pointed out, I would have to do a large number of small iterations to get even close to ending up where it started after 1 minute. I was just wondering if there was a nice way of calculating the new position for an abritrarily long period of time, and in all 3 axis.

Unless I missed something.

Endolf

#4

The verlet integration, you can use dt as the 1 minute and it would give you the new position. There is no need to small step. Same thing with angular velocity…

What you need to remember is that verlet works on the 1st derivative of position over time, not the 2nd. Thus accleration has no meaning in this context (thats partly the reason why its so stable)…

#5

Ok, I’m going to give it a go and see what happens :slight_smile:

My current consern is gimble lock, the only time I used to use them was for converting controls into rotational degrees per second components, which I then converted to a 3x3 matrix and mulitplied my original transform by. Using this method, I need to store the 3 euler angles current values, and their previous values. Does this not lead to the potential of gimble lock again?

I’m asuming I’ve missed something, this part of the maths has never been my strong point :slight_smile:

Endolf

#6

when you record 3 positions in verlet integration, instead of 2, you have enough information to handle acceleration as well.

#7

Describing rotation over a period of time is tricky business. I am theorizing that you could replace the euler angles that are required in angular verlet integration with 1 quaternion in the verlet integrator and the result would be the same as if you would have used 3 correct, non-gimbal locked euler angles. This would turn out to be more effecient infact since your only integrating once and not 3 times…

HTH, DP

#8

Having found this article that discribes RK4 integration algorithm, I think I can apply the concepts I gleaned from it to Verlet.

They all rely on time stepping through the changes, which is exactly what I was trying to avoid :slight_smile:

Somewhere I found a link to a time corrected Verlet integration algo, that didn’t require it, but I think I’ll just stick to time stepping through. The client will just have to like it :slight_smile:

Thanks for the info

Endolf

#9

You can’t get around stepping, but you can really reduce the amount of steps you need to take by adaptively changing the step size according to an estimate of error. This also means you have a parameter for tolerable error to tweak:-
I found this tutorial quite legible:-
http://www.cs.cmu.edu/~baraff/sigcourse/notesb.pdf

#10

PS this thread caused me to ad RK4 intergration to JOODE. Is implemented now, only problem is that it is incompatable with how joints error reduction works so I am busy at the moment changing how that works. Anyway if you want RK4 code you can take look at JOODE. For your problem it should work quite well.