Should I use a Cartesian (x and y) or polar (angle and magnitude) coordinate system to represent velocity?

I'm programming a physics game. It seems I can use 2 systems for storing a character's movement data:

A) x & y components (Cartesian coordinates) B) speed and direction components (polar coordinates)

It seems I need to ultimately decide on one of these 2 systems because:

A) They both represent the same information about a vector B) It seems redundant and inefficient to maintain both

Most game programming resources I've found use Cartesian. To my understanding, all transformations like friction, rotation, acceleration, etc are combined into each vector via multiplication, division, etc. But to me, polar feels more modular and, therefore, more malleable because each vector is comprised of and can be broken down into its two elements (direction and magnitude). If I want to modify one of these independently, I can set its value without needing to deconstruct it into separate parts.

I'm guessing that different models are suitable fo开发者_开发百科r different types of games. But...

What trade-offs affect the decision to use Cartesian versus polar?

When does one model become cumbersome or verbose?

Or am I way off?

The premise of your question is a bit odd. Magnitude plus angle and sum of 2 basis components are both ways to specify a vector in 2-space. In either case, you record 2 scalars (i.e. you do not have a separate variable to represent the x unit vector). The choice of rectangular vs polar coordinates doesn't change the nature of something from a vector to a scalar or vice versa.

However, different representations certainly have their uses. As you mention, breaking down into orthogonal components has a ready advantage for addition of two vectors and other operations. In addition, most displays use a x-y coordinate system, so rendering is easier because you don't have to do a coordinate transform.

If your game was based on a polar coordinate system (say a ship that always faces the center of a circle), you might actually want to represent it using polar coordinates. Other than that, rectangular coordinates are generally easier to use.

Either way, sin and cos will probably become your friend. Just remember that most graphical coordinate systems have y-down as positive.

You are confused about the difference between vectors and scalars.

The speed along the x-axis is a scalar.

The speed along the y-axis is also a scalar.

When you combine those two numbers into a single mathematical object, that object is the velocity vector. Think of it like a 2-element array: [x, y]

Similarly,

Thrust is a scalar.

Angle is a scalar.

The combination of these two numbers is a different kind of velocity vector [thrust, angle].

Any velocity that is expressable in your [x, y] system can be also expressed in your [thrust, angle] system.

You might be getting confused with "basis vectors." In your first coordinate system, a basis vector is a vector that is one unit long and which points along the x or y axis. So [1, 0] would be a basis vector that is one-unit along the x axis, and [0, 1] would be a basis vector that is one unit along the y axis. The thing that is interesting about basis vectors is that any vector at all can be expressed as a linear combination of basis vectors.

So if i = [1, 0], and j = [0, 1] then

(34.5 i + -4.45 j) is a vector,

(4.65 i + 23.3 j) is a vector,

etc. (if you're not familiar with vector addition, just google it, it's easy)

Now you might think that when take your 2-dimensional space and you use a different coordinate system (like polar coordinates, which is really what your thrust/angle coordinates are) you are getting away from basis vectors, but in fact you are not. So, for your thrust and angle coordinate system, your basis vectors are:

i = 1 unit of positive thrust, or radius

and

j = 1 degree (or radian) of positive angle

Any possible velocity is still a combination of i and j, your basis vectors.

The two representations are mathematically equivalent. Additionally, converting one to the other is a simple O(1) operation. So be aware that it's probably not a make-or-break decision. That said, in terms of ease-of-use:

You're probably right that it depends on the circumstance as to which is more appropriate, so whichever you can foresee yourself using more often, then go with that, and convert to the other form when necessary.

Use language features to help you abstract the specific type of implementation. E.g. If you're using Java, have a IPoint interface with the relevant methods. That way you can choose an implementation, or even more, to suit the needs. You can even choose certain parts of the program to work with one implementation, and other parts with other types. Proper architecture will make these things seemless.

Depending on certain calculations you might prefer to use ones that will provide you with more accuracy. If you're doing floating point arithmetic with vastly different magnitudes you might suffer precision loss. In that case it may, for example, be easier to use the angle and length representation, because angles will have persistent accuracy, and lengths might be of similar magnitude, whereas there is no guarantee of such in the x and y representation. Although granted that this is a slightly less pressing issue if you're values will be reasonable and calculations nominal.

What you're calling "scalar quantities" is really just a polar vector, right? So your question isn't so much about vectors vc scalars as it is about cartesian vs polar coordinate systems. [x,y] and [theta,r] are both vectors.

I haven't done a whole lot of physics programming, but the last time I did and it started to get complicated (modeling fish swimming in a three-dimensional space), I was much more comfortable dealing with polar coordinates. I was working from scratch implementing a boids-like algorithm, and I found it much more straightforward to think in terms of polar vectors, especially when working in 3 dimensions. I also found using trigonometric functions (acos(), asin(), etc.) cleaner than using the pythagorean formulae you'd use in a cartesian system.

But are you actually coding things from such a low level?

The dynamics of a system are usually easier to describe in the (point, velocity) framework. Indeed, the "fundamental" ODE is usually described in this system:

d (mv) / dt = force(x)

and hence are also easier to plug into a black box Runge Kutta solver.

However, any system will do, thanks to canonical transformations.