Java-Gaming.org
 Featured games (81) games approved by the League of Dukes Games in Showcase (497) Games in Android Showcase (114) games submitted by our members Games in WIP (563) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1]
 ignore  |  Print
 Calculating the future position of an object with 6dof  (Read 5395 times) 0 Members and 1 Guest are viewing this topic.
endolf

JGO Coder

Medals: 7

Current project release date: sometime in 3003

 « Posted 2007-03-03 15:23:46 »

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 .

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

Cheers

Endolf

darkprophet

Senior Member

 « Reply #1 - Posted 2007-03-03 16:15:56 »

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

Quote
a vector describing it's current translational movement
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

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

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
endolf

JGO Coder

Medals: 7

Current project release date: sometime in 3003

 « Reply #2 - Posted 2007-03-03 17:31:09 »

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

darkprophet

Senior Member

 « Reply #3 - Posted 2007-03-04 04:44:59 »

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)...

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
endolf

JGO Coder

Medals: 7

Current project release date: sometime in 3003

 « Reply #4 - Posted 2007-03-04 09:24:58 »

Ok, I'm going to give it a go and see what happens

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

Endolf

Riven
« League of Dukes »

JGO Overlord

Medals: 799
Projects: 4
Exp: 16 years

 « Reply #5 - Posted 2007-03-04 10:11:38 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
darkprophet

Senior Member

 « Reply #6 - Posted 2007-03-04 15:15:58 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
endolf

JGO Coder

Medals: 7

Current project release date: sometime in 3003

 « Reply #7 - Posted 2007-03-04 16:58:17 »

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

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

Thanks for the info

Endolf

t_larkworthy

Senior Member

Medals: 1
Projects: 1

 « Reply #8 - Posted 2007-03-05 12:01:22 »

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

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
t_larkworthy

Senior Member

Medals: 1
Projects: 1

 « Reply #9 - Posted 2007-03-26 16:06:15 »

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Pages: [1]
 ignore  |  Print

You cannot reply to this message, because it is very, very old.

 Add your game by posting it in the WIP section, or publish it in Showcase. The first screenshot will be displayed as a thumbnail.
 BurntPizza (22 views) 2014-09-19 03:14:18 Dwinin (37 views) 2014-09-12 09:08:26 Norakomi (65 views) 2014-09-10 13:57:51 TehJavaDev (91 views) 2014-09-10 06:39:09 Tekkerue (45 views) 2014-09-09 02:24:56 mitcheeb (66 views) 2014-09-08 06:06:29 BurntPizza (49 views) 2014-09-07 01:13:42 Longarmx (36 views) 2014-09-07 01:12:14 Longarmx (42 views) 2014-09-07 01:11:22 Longarmx (38 views) 2014-09-07 01:10:19
 BurntPizza 37x Riven 18x Rayvolution 18x basil_ 16x ags1 16x princec 16x KevinWorkman 15x LiquidNitrogen 12x kevglass 12x nsigma 11x theagentd 11x deathpat 10x HeroesGraveDev 9x The Lion King 7x Gibbo3771 6x cylab 6x
 List of Learning Resources2014-08-16 10:40:00List of Learning Resources2014-08-05 19:33:27Resources for WIP games2014-08-01 16:20:17Resources for WIP games2014-08-01 16:19:50List of Learning Resources2014-07-31 16:29:50List of Learning Resources2014-07-31 16:26:06List of Learning Resources2014-07-31 11:54:12HotSpot Optionsby dleskov2014-07-08 01:59:08
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org