Jump to content

  • Log In with Google      Sign In   
  • Create Account


Utilizing vectors to move entities in 3D space


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Henri Korpela   Members   -  Reputation: 104

Like
0Likes
Like

Posted 14 November 2012 - 04:07 PM

Hi, folks and welcome to the topic!

First of all, I'd like to point out that I'm no math genius, but I really got hooked on vectors seeing their benefits in programming entity movement in virtual 2D and 3D environments.

There are several vector classes written in C/C++ to be found on the Internet. However, as I'm willing to learn more about vectors all the time, I dediced to create my own class template in C++ called Vector3.

As far as I know, vector consists of a direction and a magnitude. Direction can be represents with the help of other vectors or by an angle. Magnitude on the hand, is simply the line segment from one point to another. Sounds reasonably simple.

Now, I'm also willing to create a class called Entity. In this class I'd like to have a Vector3-class instance as a member. Via member function called "move" I'd like to use the vector to move some entity, like this:

Entity bob("Bob");
bob.move(30, 0, 1); // '30' and '0' are both angles, '1' represents velocity, which is in meters per second.

Now, if I know both the direction given in angles and the magnitude, not to mention the vector start point in 3D space, how is it possible to calculate the vector end point or do I need to calculate the vector end point in order to move the entity? For me, it makes sense that the movement of an entity happens from one point to another, but how is this movement usually implemented by vectors?

Sponsor:

#2 Kyall   Members   -  Reputation: 287

Like
6Likes
Like

Posted 14 November 2012 - 06:27 PM

Usually when we use vectors in math/physics/game development we use them as a 3-scalar value ( for 3D ) where each represents a magnitude along each axis.

[source lang="cpp"]class Vector { float x, y, z; Vector(float _x,float _y, float _z);}[/source]

If we create a vector that has value Vector( 1, 0, 0 ) we are saying that this vector is 1 along the x axis and 0 along the y and z. You've probably noticed that this vector describes a position in 3-point space just as well as it does a direction and a magnitude. Which means if you have your position of an object stored as a Vector( x, y, z ) and you have the velocity stored as a Vector( x, y, z ) then you add the two vectors together with the equation

result = Vector( x1 + x2, y1 + y2, z1 + z2 )

You have now calculated the result of moving that position by the other vector's magnitude and direction.

But why a 3-scalar to describe direction and magnitude, rather than a series of angles and a magnitude value ?

Mostly for mathematical reasons. A 3 scalar of direction and magnitude is more powerful and easier to use than an angle + magnitude representation of the same value. A magnitude and direction from angles/magnitude can be calculated as:

result.x = cos( direction.x ) * magnitude - sin( direction.y ) * magnitude
result.y = sin( direction.x ) * magnitude + cos( direction.y ) * magnitude


I've tried writing more to this post. But the simple fact of the matter is that an introduction to vectors and linear geometry would end up being 10 pages long. Basically, don't use angles/magnitude to represent vectors. That is not what a vector is.

A vector has as many values as there are axis in the system, and each of those values corresponds to the magnitude of the vector along that axis. A vector is x, y, z where x represents magnitude of the vector along x-axis, y represents magnitude of the vector along y-axis and so on. 2D/3D/4D doesn't matter. Magnitude along an axis however is an internal magnitude. The concept of magnitude itself is a representation that is not of the internal components, but of the sum of their parts.

So where do direction and magnitude come from ? These are a description of the two basic properties that you can derive from that internal representation; direction and magnitude are not the components of a vector, they are properties of it.

The magnitude is obtained with
magnitude = sqrt ( x * x + y * y + z * z )

And the direction is obtained with
direction = Vector( x / magnitude, y / magnitude, z / magnitude )

Notice that the direction is also a vector. It's just a normalized vector. A directional vector has the property that it's magnitude is equal to one.

I'm not sure on what books are good for learning linear geometry. Which is what this is. I'm going to throw that out to the outfielder.
I say Code! You say Build! Code! Build! Code! Build! Can I get a woop-woop? Woop! Woop!

#3 Henri Korpela   Members   -  Reputation: 104

Like
0Likes
Like

Posted 15 November 2012 - 02:48 AM

Thanks, Kyall, for such a useful post! Now I see what are the benefits of using plain coordinates instead of angles to represent direction of where to go to. There's no need to recalculate direction when you can just sum it up to already existing coordinates in order to move requested entity. Simple yet satisfying.

Anyway, could somebody still prove why this is true to deepen my understanding (and possibly the other's following this topic):
[source lang="c++"]result.x = cos( direction.x ) * magnitude - sin( direction.y ) * magnituderesult.y = sin( direction.x ) * magnitude + cos( direction.y ) * magnitude[/source]

#4 Bacterius   Crossbones+   -  Reputation: 8318

Like
1Likes
Like

Posted 15 November 2012 - 08:32 AM

I think Kyall got mixed up somewhere - the equations he gives look like those to rotate a 2D vector by some angle (which can be represented as another 2D vector, but with magnitude 1, i.e. a unit vector). I think what he meant was:

result.x = cos(angle) * magnitude
result.y = sin(angle) * magnitude

Which is true by the very definition of the angle and the trigonometric angles cosine and sine. Think back to the unit circle (circle of radius 1) - for any angle, the cosine of the angle gives the x-coordinate of the point at which a line starting from the origin and going at said angle would intersect the circle. Similarly, the sine will give the y-coordinate of the point of intersection. So the point at which the line intersects the circle is:

(cos(angle), sin(angle))

Since this is in relation to the origin, this point can be represented as a vector (more accurately, a position vector, which means the vector of the movement required to get from the origin to that point). Now, the length of this segment (from the origin to the point) is going to be:

sqrt(cos(angle)^2 + sin(angle)^2)

And we know that cos(angle)^2 + sin(angle)^2 = 1, so the length of the segment is sqrt(1) = 1. This could also be deduced by noting that the point of intersection of the line with the unit circle is, by definition, located on the circle, which has radius 1, so the length to the origin must be 1.

So we just need to multiply this position vector by the magnitude, which is the length of the desired vector, to obtain the final vector:

(cos(angle), sin(angle)) * magnitude

Which is the same as:

(cos(angle) * magnitude, sin(angle) * magnitude)

Which is, in cartesian coordinates:
x = cos(angle) * magnitude
y = sin(angle) * magnitude

----

I find it very difficult to completely and intuitively explain vectors in a single post. If you really want to get a grip on it, I suggest following some sort of linear algebra course, which is basically all about vectors and matrices. It really does help.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS