Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Move towards 3D coordinates

Author
Message
Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Apr 2013 21:47
Do anybody know an efficient, purely mathematical way of determining the new position when moving from A(x1, y1, z1) towards B(x2, y2, z2) at a certain speed?
I'd prefer it if it was possible without slow operations such as square roots (distance formula) etc.

As said above I'm looking for the mathematical way to do this, so solutions that make use of point / move object are unfortunately not adequate.


Thanks for any hints


"Why do programmers get Halloween and Christmas mixed up?"
Flamertor
13
Years of Service
User Offline
Joined: 12th Oct 2011
Location:
Posted: 14th Apr 2013 01:30 Edited at: 14th Apr 2013 01:32
Sorry I just relized you didn't want the point command
Quel
16
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 14th Apr 2013 02:41 Edited at: 14th Apr 2013 02:43
Well then you need two angle checks using atanfull() between the current coordinates and the target coordinates on the X and Y axes, then put the results each in a Sin(), multiplied by the moving speed, and so you get the X movement and Y movement. And i just realized Z is missing... sorry it is 2am here, something similar, i need some sleep...
Andrew_Neale
15
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 14th Apr 2013 02:49 Edited at: 14th Apr 2013 02:57
This isn't possible. You need the distance and direction to move from one point to another. The speed will be a distance over time, so you need the distance and you'd need to know when you've reached the end. You could do it by creating a unit vector of the target point minus the start point and multiply this by the speed. Whilst this avoids you doing any distance checks though, the normalizing of the vector does the distance check behind the scenes. Why are you trying to avoid it? It is perhaps slow when compared to an addition operation but in real terms on modern hardware it is pretty much negligible. Well, I suppose you could avoid specifically distance and square roots by using some trigonometry to get the angle instead but sin/cos/tan are considerably slower to use than square roots and you would have no way of knowing when you'd reached your target without some kind of distance check anyway, even if a much simpler one. If you just calculate and store once the unit vector and the distance for the movement then you've done one still tiny calculation as a one off and will also know how many steps will be moved before the target is reached without any further distance or bounds checks.

[Edit]
Hastily cobbled together example for you. Hope it helps!



[/Edit]


Previously TEH_CODERER.
basjak
15
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 14th Apr 2013 15:36 Edited at: 15th Apr 2013 01:38
moving one object from one point in space to another is better to be independent from object rotation or local direction and must reach its distance with 100% accuracy.

here is a simple code where moving an object is relying on time/speed values.



Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Apr 2013 03:16 Edited at: 15th Apr 2013 03:16
Quote: "This isn't possible."

Could've guessed as much but still, thought I'd better ask

Anyhow, thanks for your help Andrew and basjak; got it working and it seems to be running fast and accurately enough


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 15th Apr 2013 11:12
Lee created a way, it's a cos/sine shortcut and uses what Quel recommended; you should wrap the two parts into a function similar to what I did:





basjak
15
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 15th Apr 2013 21:10 Edited at: 15th Apr 2013 21:15
thank chris for sharing this. much better than my way in getting for to distances.

Andrew_Neale
15
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 15th Apr 2013 21:21 Edited at: 16th Apr 2013 01:40
The problem with using the NewXValue and NewZValue commands is that they don't take the x angle into account. If you're moving a distance of 1 unit and looking straight forward then you would move forward 1 unit. If you were looking 45 degrees up then you would move 1 unit forward as well as ~0.7 units up making the total distance covered more than the distance you were trying to move at. To handle this properly you would have to do this:

inc x#, sin(AngleY#) * cos(AngleX#) * Distance#
inc y#, sin(AngleX#) * -Distance#
inc z#, cos(AngleY#) * cos(AngleX#) * Distance#


Previously TEH_CODERER.
Indicium
16
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 15th Apr 2013 21:58
Sorry I might be missing the point here, but this is incredibly simple.

First you work out the direction vector: B-A
Now normalize the vector so it's magnitude becomes one.
Now multiply this vector by the speed and multiply the vector by the time since leaving the initial position to find the total displacement, then add it to the original to find the new position.


They see me coding, they hating. http://indi-indicium.blogspot.co.uk/
basjak
15
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 15th Apr 2013 23:36
simply use my way if you're doing engineering projects such as what I do but, in computer games, accurate distances can be ignored and chris (or lee's) way is good to handle because you could do more with it.

TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 16th Apr 2013 00:43
Sorry, but how is this more accurate?



The inaccuracy of floating point values are ADDED TOGETHER in your while loop, making it far more inaccurate than this:



TheComet


Level 91 Forumer - 9600 health, 666'666 keystroke power (*2 coffee)
Abilities: sophisticated troll, rage
Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 16th Apr 2013 00:53
Quote: "Sorry I might be missing the point here, but this is incredibly simple."

I suppose it was, I don't use vectors very often though (most code I have that do use those are wrapped up in utility functions that I just call when needed) so yeah. Curiously none (of the first few at least) of the google results I got when searching for seemingly descriptive phrases of the problem suggested that either, the closest I got was something based on trigonometry that was only good for one angle.


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Apr 2013 01:27 Edited at: 16th Apr 2013 01:32
Quote: "The problem with using the NewXValue and NewZValue commands is that they don't take the x angle into account."


Why don't you think the New value commands wouldn't consider the X angle?



Quote: "To handle this properly you would have to do this:

inc x#, sin(AngleY#) * cos(AngleX#) * Distance#
inc y#, sin(AngleY#) * -Distance#
inc z#, cos(AngleY#) * cos(AngleX#) * Distance#"


How would this work? You can't use the Y angle to influence the Y axis; unless you use the third angle dimension (Z); meaning the object would have to roll in order for its Y rotation to affect anything other than the X and Z axis. But then... there is no object, just two coordinates.

Perhaps there is a typo... In the code snippet all that happens is the Y velocity uses the reverse of the Z velocity. Or perhaps I am missing something. Why doesn't it work?


Quote: "this is incredibly simple.

First you work out the direction vector: B-A
Now normalize the vector so it's magnitude becomes one.
Now multiply this vector by the speed and multiply the vector by the time since leaving the initial position to find the total displacement, then add it to the original to find the new position."


Hehe, that wouldn't sound simple to a learner.

Andrew_Neale
15
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 16th Apr 2013 01:42
Quote: "
First you work out the direction vector: B-A
Now normalize the vector so it's magnitude becomes one.
Now multiply this vector by the speed and multiply the vector by the time since leaving the initial position to find the total displacement, then add it to the original to find the new position.
"


Indeed, that is exactly what I did in my first post.

Quote: "Why don't you think the New value commands wouldn't consider the X angle?"


Because the x angle is never supplied to those commands.

Quote: "Perhaps there is a typo..."


Yep, sorry, fixed. Other than that though it was correct. With an adjust version of your code:



The first option gives the correct values and the second option is incorrect as the total distance moved is more than the specified distance because of the x angle not being taken into consideration.


Previously TEH_CODERER.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 16th Apr 2013 10:13
Quote: "I suppose it was, I don't use vectors very often though"

Time to start using them!

D = B - A
D = normalize(D)
A = A + D*speed

The square root would only be used once when normalizing the vector, which you only need to calculate when the direction changes (if B moves before you reach it).

"You're all wrong. You're all idiots." ~Fluffy Rabbit
Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Apr 2013 13:26
Quote: "Because the x angle is never supplied to those commands."


OK got it now; got lost there. Here is a demo that shows how Andrew is right; the distance in the second method is accurate because the X angle is not being considered.



basjak
15
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 16th Apr 2013 14:28
@The commet:

sorry, I didn't understand your question !!!.
it seems that there are different ways, if we comeback to the top question, rdolpho is looking to control the seed#. my formula (i don't think i invented it ) will give high point reaching accurancy based on adding floting points together.

however, am open to all solution and chris suggestion is amazing.

Login to post a reply

Server time is: 2025-05-17 23:49:25
Your offset time is: 2025-05-17 23:49:25