我应该使用笛卡尔（x 和 y）坐标系还是极坐标（角度和幅度）坐标系来表示速度？
我正在编写一个物理游戏。看来我可以使用两个系统来存储角色的移动数据：
A) x & y 分量（笛卡尔坐标） B) 速度和方向分量（极坐标）
看来我最终需要决定这两个系统之一，因为：
A) 它们都代表向量的相同信息 B) 维护这两者似乎是多余且低效的
。我发现大多数游戏编程资源都使用笛卡尔。据我的理解，所有的变换，如摩擦、旋转、加速度等，都通过乘法、除法等组合成每个向量。但对我来说，极地感觉更模块化，因此更具可塑性，因为每个向量都是组成的分解为两个元素（方向和幅度）。如果我想独立修改其中一个，我可以设置它的值，而无需将其解构为单独的部分。
我猜不同的模型适合不同类型的游戏。但是...
哪些权衡会影响使用笛卡尔坐标还是极坐标的决定？
一个模型什么时候会变得繁琐或冗长？
或者我离题了？
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 for 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你的问题的前提有点奇怪。幅度加角度以及 2 个基分量之和都是在 2 空间中指定向量的方法。无论哪种情况，您都会记录 2 个标量（即您没有单独的变量来表示 x 单位向量）。直角坐标与极坐标的选择不会将某些东西的性质从向量改变为标量，反之亦然。
然而，不同的表示当然有其用途。正如您所提到的，分解为正交分量对于两个向量的加法和其他操作具有现成的优势。此外，大多数显示器使用 xy 坐标系，因此渲染更容易，因为您不必执行坐标变换。
如果您的游戏基于极坐标系（例如一艘始终面向圆心的船），您实际上可能希望使用极坐标来表示它。除此之外，直角坐标通常更容易使用。
不管怎样，正弦和余弦可能会成为你的朋友。请记住，大多数图形坐标系将 y-down 设为正值。
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.
您对向量和标量之间的区别感到困惑。
沿 x 轴的速度是标量。
沿 y 轴的速度也是一个标量。
当您将这两个数字组合成一个数学对象时，该对象就是速度矢量。将其视为一个 2 元素数组：[x, y]
类似地，
Thrust 是一个标量。
角度是一个标量。
这两个数字的组合是一种不同类型的速度矢量[推力，角度]。
任何可以在 [x, y] 系统中表达的速度也可以在 [推力，角度] 系统中表达。
您可能会对“基本向量”感到困惑。在第一个坐标系中，基向量是一个单位长且沿 x 或 y 轴指向的向量。因此，[1, 0] 是沿 x 轴为 1 个单位的基向量，[0, 1] 为沿 y 轴为 1 个单位的基向量。基向量的有趣之处在于，任何向量都可以表示为基向量的线性组合。
因此，如果 i = [1, 0]，且 j = [0, 1]，则
(34.5 i + -4.45 j) 是一个向量，
(4.65 i + 23.3 j) 是一个向量，
依此类推（如果你不是熟悉向量加法，只需谷歌一下，很容易）
现在您可能会认为，当采用二维空间并使用不同的坐标系（例如极坐标，这实际上就是您的推力/角度坐标）时，您会得到远离基向量，但事实上你不是。因此，对于推力和角度坐标系，基本向量为：
i = 1 单位的正推力或半径
，
j = 1 度（或弧度）的正角度
任何可能的速度仍然是 i 和 j 的组合，您的基向量。
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.
这两种表示在数学上是等价的。此外，将一种转换为另一种是一个简单的 O(1) 操作。因此请注意，这可能不是一个决定成败的决定。也就是说，就易用性而言：
您可能是对的，这取决于哪种情况更合适，因此无论您能预见到自己会更频繁地使用哪个，然后就采用它，并转换为另一个必要时形成。
使用语言功能来帮助您抽象特定类型的实现。例如，如果您使用 Java，请拥有一个带有相关方法的
IPoint接口。这样您就可以选择一个甚至更多的实现来满足需求。您甚至可以选择程序的某些部分与一种实现一起使用，而其他部分与其他类型一起使用。正确的架构将使这些事情变得看起来。根据某些计算，您可能更喜欢使用更准确的计算。如果您正在进行大小差异很大的浮点算术，您可能会遭受精度损失。在这种情况下，例如，使用角度和长度表示可能会更容易，因为角度将具有持久的精度，并且长度可能具有相似的大小，而在 x 和 y 表示中不能保证这一点。尽管如果您的值合理并且计算名义上的话，那么这是一个稍微不那么紧迫的问题。
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
IPointinterface 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.
你所说的“标量”实际上只是一个极向量，对吧？因此，您的问题与其说是关于向量 vc 标量，不如说是关于笛卡尔坐标系与极坐标系。 [x,y] 和 [theta,r] 都是向量。
我没有做过很多物理编程，但上次我做了并且它开始变得复杂（模拟在三维空间中游泳的鱼），我更喜欢处理极坐标。我从头开始实现一个类似 boids 的算法，我发现它更容易思考就极向量而言，尤其是在 3 维中工作时。我还发现使用三角函数（acos()、asin() 等）比使用笛卡尔系统中使用的毕达哥拉斯公式更清晰。
但你真的是从这么低的层次开始编码的吗？
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?
系统的动力学通常在（点，速度）框架中更容易描述。事实上，“基本”ODE 通常在该系统中描述：
因此也更容易插入黑盒龙格库塔求解器。
然而，任何系统都可以，这要归功于规范转换。
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:
and hence are also easier to plug into a black box Runge Kutta solver.
However, any system will do, thanks to canonical transformations.