koobas.hobune.stream
Calculating tangential velocity with radius and planet angular velocity,Obtaining tangential velocity of a particle given planet angular velocity and radius
I am currently trying to create a physics game. Newtonian gravity is in effect, I am rotating planets with addTorque, everything is set up based upon realistic physics models. I am trying to, given the distance between the planet and the player (i have this) and the angular velocity of the planet (I also have this), find the tangential velocity of the player, so they can stay grounded on the rotating planet.
I essentially need to apply some sort of acceleration, I just don't know where to get this acceleration.
What equation should I be using? Are there any useful functions for this purpose? I have looked into the docs, but I do not know where to start.
Thank you, and If code is needed, I will post it, though I do not believe it should be needed.
P.S. I am using a vector3 to define the rotational direction of the planet, addTorque then uses this to rotate it.
For a planet that's rotating at angular speed A [rad/s], a stationary point on it's surface will travel a distance in one second:
dist = A * r
Thus... giving you the linear speed value.
Note:
rdoesn't mean distance to planet center here but distance to rotation axis (so at the polesris zero).
To convert this linear speed into a 3d vector you must know rotation direction vector. It can be calculated, for example, as:
direction_vector = Vector3.Cross( planet_rotation_axis.normalized , (point - planet_center).normalized )
tangential_velocity = direction_vector * dist
where planet_rotation_axis is angular momentum vector
for left-handed coordinate system
.
I make this point because UnityEngine.Vector3.Cross is "left-handed" where most physics books prefere "right-handed" convention. To convert between right-handed and left-handed vectors you just flip them by negating this vector-vec.
This is exactly what I needed! I was using the distance to the center of the planet, not the distance to rotational axis. Thank you!
Also you need to know that most in-game simulations do not calculate velocities for stationary objects (stationary in planet's reference frame). This is because it's nearly impossible to get rid of all kinds of numerical drifts, race conditions or just tiny randomness that accumulates and makes these objects jitter or even shake violently. If you need that objects come in and come out of planets reference frame, like rockets landing and taking off, it may be better to have 2 kinds of velocities - absolute and relative - and convert between those only on events of transition (rocket escaping a planet's gravity well will inherit it's velocity).
I just like to add that mathematically the cross product does not have any "handiness". If you use it in a right handed system you get the right handed result, if you use it in a left handed system you get the left handed result. The cross product is always calculated the same. A simple way is to remember it is to use the rule of Sarrus. Since the difference between right handed and left handed is basically that one axis is flipped, when the input space is flipped, the output space is as well.
While it's possible to switch between right and left handed system (if done correctly) I would highly recommend you stay in one system. To invert the result of a cross product you can either invert the result as you said, or just swap the two vectors around.
ps: When you need a normalized vector It's slightly more efficient to first calculate the cross product on the non-normalized vectors and just normalize the result once.
Oh dear, I have certainly tested this in the past but forgot about it and the totally wrong conclusion remained. As always, thank you @Bunny83 for clarifying! You're the best.
What I was really pointing toward there was that when translating physics equations from textbooks to Unity like, for example, this one:
Will make you swap the axes with each other (Z and Y, most often). This single change will produce an inverted h vector. And, as you said, it's not because Unity's cross product is different, but because Unity's coordinate system differs from the one that given textbook uses.
