We're working on "phase one" of a game/simulation physics engine - the phase that accumulates forces and torques, then turns them into linear and angular acceleration/velocity/position. We already have "phase two" finished and working well (except a few unusual cases we want to handle more efficiently), and we'll get to "phase three" (collision response) when we get there.

We have functions written to compute native (local-coordinates) inverse inertia tensors when necessary (at object creation and after [non-linear] scaling), and the time has arrived to:

#1: accumulate forces and torques for each object.

#2: convert them into linear and angular acceleration for each object.

#3: compute new linear and angular velocity and position for each object.

At this point, to perform step #1 (accumulate force & torque), two basic formula seem popular:

force = force + newforce;

torque = torque + (point x newforce);

The accumulated force and newforce and torque and point are all in local-coordinates with the origin at the center-of-mass of the object, mostly because that is most convenient in our engine. In the moderately rare case a point or newforce is more naturally available in world-coordinates, we simply multiply by our world-to-local matrix to get the point or vector in local-coordinates.

Though our engine can load conventional objects, our engine is designed and optimized for "procedurally generated content". So most game objects are tweaks and fiddles of our ~40 fundamental shapes, and/or assemblies of any number of these fundamental shapes permanently "bonded" together, or attached together (and able to articulate). The inertia tensors of every fundamental shape is a "diagonal matrix". As such, every element of the matrix is zero, except the m00, m11, m22 diagonal elements, and the "inverse" is simply the matrix itself with a unary negative before each of the diagonal elements. Simple! Though yes, life will become a bit less simple whenever we bond or attach these fundamental shape objects together with some objects in crazy orientations relative to others (to deal with "manana").

So, now for some questions...

#1: Not all, but seemingly a majority of physics and game engines transform whichever forces and points (where forces are applied) that happen to be in local-coordinates into world-coordinates. Then they execute those force and torque accumulation equations noted above, and thus accumulate their total force and torque in world-coordinates.

Why? So far at least, most forces and points of application are naturally in local-coordinates. For example, every thrust-producing rocket is attached to a spacecraft or space-station or mothership. And thus the position of the thruster is automatically known in local-coordinates, as is the thrust-direction (almost always entirely in x or y or z in local-coordinates). While gravity in our application is not really in any major coordinate system (the force vectors are between whatever massive objects are nearby (stars, planets, moons, etc) or very nearby (motherships, space-stations, spacecraft, etc), to compute the gravity vector in local-coordinates is trivial and fast (plus, gravity doesn't generate torque, so the torque equation isn't even executed).

#2: Not all, but seemingly a majority of physics and game engines transform the inertia tensor and/or inverse inertia tensor from its natural "local-coordinates form" to decidely not-natural "world-coordinates form". Presumably they do this because they transformed every force-vector and position into world-coordinates during the force and torque accumulation phase (for some odd (to us) reason). As a result, the output of their computation is linear and angular acceleration in world-coordinates.

While world-coordinates are convenient for translation (moving the center of mass of game objects), rotation is more natural in local-coordinates. I'm not suggesting this is because we prefer to apply rotation as object-relative "yaw, pitch, roll", but because even rotation via axis-angle or quaternion (also an axis-angle approach) is more natural in local-coordinates. Yes, I do recognize this part is a "wash" when it comes to compute cycles, because rotation around object-axes versus world-axes is simply the difference in operand order in one multiply.

Nonetheless, from the perspective of someone in the spacecraft (or other vehicle), the control of the orientation of that spacecraft is vastly more natural in local-coordinates. And to some degree (but less overwhelmingly), the control of translation of that spacecraft is more natural in local-coordinates ("go straight ahead" or "turn/bank right" versus ("continue in direction <+0.2365439352, -0.113554354, +0.523433959, +0.035442342> or <however one would figure out what "turn/bank right" means> in axis-angle form).

#3: Thus the combined question is: why convert lots of natively local-coordinate forces and positions into world-coordinates, then transform a natively simple inverted inertia tensor with only three non-zero elements... into world-coordinate forces and positions, and a totally scrambled world-coordinate version of the inverted inertia tensor? And then (perhaps) convert the angular velocity and orientation back to local-coordinates at the end (or else have to convert all subsequent intuitively local-coordinate course-coorections into totally non-intuitive world-coordinate alternatives)?

I do suppose a game that takes place in flatland (the surface of a huge planet) would have somewhat more world-coordinate forces and positions than a space, airplane, submarine or other freeform game, but still not an overwhelming majority. After all, I would imagine any force applied to an object would need to be known in local-coordinates too, to complete other processes and computations.

PS: As an aside, a routine to transform with an inverse inertia tensor that only contains the diagonal elements is much shorter and quicker than a full-blown transformation by an inverse inertia tensor that has been transformed to world-coordinates. So not only do we not need to transform the inverse inertia tensor, but also every time we compute a torque with the inverse inertia tensor, that operation is much quicker too.

-----

Now, onto a different question, albeit somewhat related.

I can't even figure out what in practice is meant by "apply a force in direction dx,dy,dz at point px,py,pz for duration t seconds". Now, on the surface, I admit this sounds like "crazy talk"... doesn't this moron know what vectors and points are?

Well, I guess it feels a bit humbling after creating a whole working 3D graphics engine to say "not really"! But I'm serious. When you get finished laughing at me (which is okay, do enjoy yourself), let me create a very simple example and ask what is meant by that phase --- which we need to understand to perform these simple steps!

Okay, let's take a very simple case. For example, a 1 meter radius sphere or disk that starts out floating (not moving) in deep space (between galaxies). For purposes of our first simple example, we will only apply force along the z-axis (towards higher values of z as time passes), directly towards a neighboring galaxy 3 million light years away.

If you imagine the disk instead of the sphere (which might help later on), assume the symmetry axis of the disk is the y-axis. So if the disk ever rotates, it will have to rotate around the y-axis. The positive end of the x-axis extends rightward from the sphere or disk, at right angles to both y-axis and z-axis.

Okay, so now we want to apply a 1000 gram force to the rightmost edge of the sphere or disk for 1 second. Now, 1 second is a rather long frame time, but hey, not much is happening out here between galaxies, and this moderately longer frame time helps make my stupidity easier for smarter folks to understand.

Now, here are some questions this example raises in my puny brain:

#1: Every source I've read claims the full 1000 gram newforce in direction <0, 0, 1> applied at point <1, 0, 0> tangent to the sphere or disk gets directly summed into the force accumulator variable force without regard for what point on the object that force is applied. In other words, the full 1000 grams of newforce in the z-direction is accumulated, exactly as much and in the same direction as if that force had been applied through the center of mass (at the center of the sphere or disk). Is this really right? Yes, I know. Every source says so... but this is quite non-intutive if you ask me! My intuition wants to believe some of that newforce is consumed to add some torque (around the y-axis) to that object. Yeah, I know, I know, intuition isn't math, and intuition isn't physics either! But conservation of energy has to mean something around here, doesn't it? Trick question?

#2: Indeed, every source I've read claims this 1000 gram newforce in direction <0, 0, 1> applied at point <1, 0, 0> tangent to the sphere or disk does in fact add torque around the y-axis of the object, which will cause the object to start rotating counterclockwise when looking up the positive y-axis from the origin. But if someone at rest was to capture the sphere or disk, and convert the linear motion to energy with 100% efficiency, and convert the rotational motion to energy with 100% efficiency... would they not end up extracting more energy than they would have if we had continually applied the same 1000 grams of force through the center of mass? Why is this not a perpetual motion machine that we all should take advantage of?

But now I want to ask even simpler (and dumber) questions!

#3: Like, what does it even mean to "apply 1000 grams of newforce in direction <0, 0, 1> to the point at <1, 0, 0> for 1 second"? No, I'm not kidding, and I'm not asking in jest, I'm asking seriously. I guess there may be two versions of this question (believe it or not), so I'll ask them separately to avoid causing any more confusion than I already suffer.

#3A: The local-coordinates version of question #3. Let's assume we paint a tiny black dot on our sphere or disk at that point at <0, 0, 1> in local-coordinates AKA object-coordinates. Okay, now, what do we mean by "apply 1000 grams of newforce in direction <0, 0, 1> to that point at <1, 0, 0> for 1 second"? Seriously? I mean, during that 1 second, that black dot we painted at that point we specified at <1, 0, 0> starts to move around in a circle (relative to the object), and in some kind of string with loopy cycles (relative to the world).

And so, my stupid (yet completely sincere) question is this. Do we keep that 1000 grams of force applied:

1: To that exact same point in 3D world coordinate space that we initially applied the force, even as the object wanders away due to our application of force? If so, how the yonk can we apply force to an object at a point that is not physically part-of or attached-to the object?

2: To the point on the very rightmost periphery of the sphere or disk, meaning that point on the sphere or disk with the greatest x-coordinate, no matter how the sphere or disk moves or rotates? If so, how can we apply force to an object at constantly varying points as the object moves and rotates? Do we need to put some little paddle-wheels on the periphery of the sphere or disk, then fly some very fancy, very responsive servo-controlled air-nozzle along a strange spiral path in order to keep applying a force in direction <0, 0, 1> exactly on the little rotating paddlewheels that happen to be at the greatest x coordinate on the object at every moment?

3: To that little black dot we painted on the sphere or disk that was at <1, 0, 0> at the start of this 1 second duration, even as that dot wanders around in circles (relative to the disk) and spiral loops (relative to world-coordinates)? What kind of physical contraption could even apply a force in a constant <0, 0, 1> direction as that dot spiraled around in circles?

4: How are we to even unambiguously understand what is meant by "apply force in a given direction to a specific point for some duration"?

5, 6, 7, 8: All these same questions (1, 2, 3, 4 just above) if the force-direction and point are given in world-coordinates instead of local-coordinates?

9: And how can we answer all these very practical questions for any specific physical devices, situations and configurations we ever encounter in the future?

Buckeye: You have to decide where the force is applied. If the source of the force is stationary in world space (gravity), then the force must be applied with respect to that reference frame. If the source of the force travels with the object, then the force is applied locally. Your general statement above assumes something about "the force" that's not general.

maxgpgpu: Well, I don't want to be newton or euler (at least not in this field, and not now). I'm just trying to figure out which equations to put into my engine to produce the correct result (objects do what they would do in reality, as close as possible). And that's the problem. What I read in the game physics books ("game physics engine development" and elsewhere), and in PDF slides downloaded from the internet, are the two simple equations in my original post. They do say they can be applied in local-coordinates or global-coordinates, then procede to adopt global-coordinates.

However, they do not indicate what kind of physical systems and applications of force correspond to those equations, and which do not. And so, I ask, what use are those equations if the authors has no idea what kind of physical contraption and configuration would satisfy those equations, and none of their readers (except me) bother to ask the question?

Do the equations only apply to some kind of fictitious idealized situations and contraptions, or to something useful (real life devices operating in real life ways)? I can't tell.

The fact is, gravity is a bit of a cheat example. First, it always (for practical purposes) applies its force through the center-of-mass of all objects, no matter where they are in the universe, and no matter how far. Plus, unless we're discussing black-hole encounters of the third kind, the gravitation force doesn't change enough in any short time-frame (1/30 second or 1 second) to worry about changes in distance during the duration of the computation.

However, other real sources of force are not so obvious and not so uniform... to put it mildly. But ALL authors I've read say NOTHING about the kind of real situations, real devices and real configurations we will encounter in real life (except maybe a simple spring example).

And so, I have to ask "what physical systems and configurations do those equations I wrote in my original post assume and work properly for?".

To take just the simplest example, how about a flying saucer in the shape of that idealized disk in my previous example. Let's say that flying saucer disk has a rocket output nozzle on the exact periphery of the disk, pointing exactly tangent to the flying saucer disk. Okay?

What equations apply to that case?

My first general, intuitive observation is the following. This rocket thruster is indeed firmly and permanently attached to the exact same local-coordinates... forever (during force generation (thrust) and when shut down). In my example, the local-coordinates of that thrust are <1, 0, 0>, and they STAY at <1, 0, 0> for all eternity. Which makes this example vastly simpler than many other practical examples we (game developers) should discuss.

Also, in the local-coordinates of the object, the thrust vector (and therefore the applied force vector) is also constant at <0, 0, 1> (though the magnitude of that force might be anything (often a huge number)).

Now, since the force is applied at a single point at a single fixed coordinate <1, 0, 0>, I have to assume those equations I quoted should apply. Also, since the force is eternally applied in a single direction, I have to further assume those equations I quoted should apply. Of course, presumably they only apply in local-coordinates, so we still need to figure out how these local-coordinates related to world-coordinates at some point (namely, every frame time, so we can update the object orientation quaternion or matrix, and the object position in world-coordinates every frame (for many purposes, including collision-detection and collision-response)). That's easy for orientation, since orientation is pretty much always help in local-coordinates (in a manner of speaking, that is, relative to the starting orientation which is co-aligned with world-coordinates).

But what about other physical configurations? Say, the force of an air nozzle fixed in world-coordinates? Or many other configurations where the quantity of force changes during the frame, the position the force is applied during the frame changes (as the object rotates and moves), and the direction of the force changes (at least relative to local-coordinates)?

All these source make it sound like there is one situation and one set of equations. Obviously not so! But nobody (I can see) talks about this, which sure makes my life difficult, and anyone else writing a game or physics engine.

Well, I'm almost afraid to ask the questions, because maybe the answers are even more basic and fundamental than any question like that (a specific scenario) implies. What do I mean? Well, for one thing, how does the duration argument/variable fit into these equations? What I mean is this. If we apply a force through the center of mass of an object, I get the impression these force -> acceleration -> velocity -> [delta]-position equations are reasonably precise and representative of what might happen in reality. To be sure, I don't expect to be able to model the orbit of a planet around the sun, or a spacecraft around the earth with just four applications of force per orbit, but at least in free space (far from stars and planets), I would imagine that linear force, acceleration, velocity and change of position may be described reasonably well by the equations even if the duration is moderately large (every few seconds or perhaps even every few minutes given a long journey, with no need to recompute every 1/30 second or 1/1,000 second or 1/1,000,000 second to get fairly realistic results).

However, the situation doesn't "feel right" when it comes to torque, angular acceleration, angular velocity and angular change of orientation. Why? Well, partly because the object could be rotating several times during one "duration". Now, in some very selective cases, perhaps including the one I mentioned in my last post, even angular quantities might be computed reasonably well. That's because that case was contrived to put the rocket thruster exactly at the periphery of the sphere or disk shape spacecraft, and the thrust was precisely tangent to the outside surface of that sphere or disk.

In this specific very contrived and unusual situation, the rocket thrust at every moment remains AT the exact same point on the object in local-coordinates, and remains thrusting AT the exact same direction relative to the local-coordinates of the object. And so, I infer that maybe if we compute everything in local-coordinates, we might get a reasonable result even if the "duration" is relatively long in relation to how long the object takes to rotate around the axis perpendicular to its thrust.

But even this highly contrived case (contrived to be easy to deal with) may be problematic, because I can imagine the trajectory of that flying sphere/disk spacecraft would be rather like a looping spiral in world-coordinates, and this is presumably different than a fully local-coordinates solution. By definition, in local-coordinates, an object NEVER MOVES LINEARLY. Why? Because the center of mass is the origin of those local-coordinate system, and the center of mass will always remain the origin of that local-coordinate system, and so the object will NEVER MOVE in local-coordinates.

Unless what is meant by "local-coordinates" isn't actually the "local-coordinates" permanently attached to the object, but some kind of pseudo-imaginary inertial coordinate system that is, was, and forever shall-be the unaccelerated (but possibly moving) position the object was at when we turned on the rocket thruster, and not the local-coordinate system we think of in 3D graphics (the origin of which is always at the center of mass, and whose directions of the axes are fixed to certain fixed solid features on the rigid body (even if just little red, green, blue dots of paint on the surface so we can see and track them).

Frankly, I don't feel I should be telling you what frame of reference I want the equations to compute. Why? Because likely some frame of reference leads to vastly simpler equations, and that is likely the frame of reference I want. And if I need to convert from one frame of reference to another, I'll just have to find a way to do so. I already have matrices that convert from local-coordinates to world-coordinates and also the reverse, so depending on what is the most natural frame of reference to compute in, I will likely be able to accept that. Though it could, I suppose, lead to a further question... how to convert from some new and very strange (to me) frame-of-reference to one I am familiar with. We shall see.

So I'm tempted to say, how about that rocket thruster case for a starter?

I'm not concerned with gravity forces, I understand how to deal with them (and maybe all forces that always pass through the center-of-mass of all objects).

I was going to say "drag", but I'm guessing symmetric drag is easy, and asymmetric drag may be equivalent to attaching a few small rocket thrusters to various locations on an object and powering them up to whatever power-level generates a force equal to the drag.

So I'll stop here, except to add one more comment that also leads me to confusion.

In "game physics engine development" they have two functions to compute force, one that takes local-coordinates and other that takes world-coordinates. In the one that takes local-coordinates, they simply transform to world-coordinates and continue. Which implies, all this "frame-of-reference stuff" is merely a matter of multiplying a position or direction vector by a transformation matrix to get the force in the frame-of-reference you want, and then just procede as if the different frame has no other bearing.

However, think about what that means... or seems to mean to me... in the case of that simple example I started out with. If that force applied to the periphery of the sphere or disk shape flying saucer is in local-coordinates, then presumably the force rotates around in circles (in terms of world-coordinates) even as the position and direction of that force stays fixed in local-coordinates! However, if the force remained fixed in world-coordinates, well, the object would move away from the point where the force was applied (a fixed world-coordinate position)... AND... the direction of the force would not rotate with the object, but would remain pointing in the same direction (in world-coordinates) as it started.

Which means... no way could the result be the same, and this "easy technique" of transforming the force direction and position of application from one coordinate system to another could not possibly be as simple as this book implies. This book (and the other books and slides on the same topic that I've encountered) simply never discuss the questions I am asking. They just assume "everyone knows and understands the underlying assumptions we are making". Well, no we don't, certainly not everyone!

And so, I'll leave you with this one example, but also a statement that "several paragraphs or pages are missing" in all these sources to help us understand exactly what is assumed, and how to deal with situations that do not fit the assumptions. And I don't think it should be up to the "learner" to know what all the cases are... that should be explained by the authors who claim to understand the topic, or so I believe.

PS: If you know some sources that are more practical, that explain (as much as practical) the whole range of possible physical situations and configurations and how to fiddle the equations to account for them, I'd appreciate the references. I suppose I could ask questions one by one, but I don't even know yet whether that would require I ask questions about 5 situations and configurations, or 25, or 255.

"Simulation" is the key word. As I'm sure you know, due to practical constraints (memory, speed, etc.), a better goal would be "as close as is practical." And, rather than "correct results .. in reality..," a better approach is "produce results similar to how real-world objects behave."

This says it all really. Your questions are interesting and well informed, but I think you have come to the wrong place for the answers. Game developers frequently (and need to) fudge the physics to get something that works at a reasonable frame rate. The techniques used are often ad-hoc and found empirically.

Your objective appears to be different to this, you want a correct and accurate simulation. For that, you will benefit by looking at more appropriate forums that deal with physics and simulation explicitly. One simulation technique that would be relevant to your line of questioning would be the Discrete Element Method, that's a good place to start. Once you understand the most accurate techniques, how to fudge them will be much more obvious.

Well, for one thing, how does the duration argument/variable fit into these equations?

Computer simulations break time into steps. The smallest duration that we bother representing is that step. Let's say you want to give a very small burst of acceleration. The smallest burst you can give lasts however long your frame lasts. If you have a framerate of 60 fps, a one-frame burst of acceleration lasts 1/60th of a second. We typically do not bother with more accurate equations, but they exist if you wish to use them.

However, the situation doesn't "feel right" when it comes to torque, angular acceleration, angular velocity and angular change of orientation. Why? Well, partly because the object could be rotating several times during one "duration".

Correct. The way we simulate things can VERY quickly diverge from an "exact" equation. The easiest solution is to use smaller slices of time if you need more accuracy.

I can imagine the trajectory of that flying sphere/disk spacecraft would be rather like a looping spiral in world-coordinates

Yes...

and this is presumably different than a fully local-coordinates solution. By definition, in local-coordinates, an object NEVER MOVES LINEARLY.

I think this is where all of the confusion is coming from. Position and Orientation are *transforms* from local space to world space. They don't mean anything in local space. Like you say, the object never moves or rotates in local space.

Think of it this way: You *could* implement a 3D physics and rendering engine where NOTHING is in local space - everything is in world space, and there are no transforms between the two. Here's the reason why this is bad:

Every object would need to have its own copy of its mesh. Every object's vertices would need to be updated any time they move - you couldn't simply manipulate the object's position and orientation, because they no longer exist - only the positions of individual vertices. The physics engine would have to compute the force, velocity, and position of every single vertex separately. Angular equivalents are horrendously more complicated to deal with because you must simulate some kind of intra-body force propagation. The rendering engine would have to upload the full mesh to the GPU every frame, instead of just updating the 16 variables that represent the transform matrix. In short: You CAN do this, but it would take a LOT more steps of calculation, and more steps of calculation means the simulation would have lower performance - lower framerate.

Representing certain things in local space, or as transforms between local space and world space are used when they can reduce the number of calculations you need to make. That's all.

Buckeye: You apparently understood the rocket thruster configuration. Great. So, what series of steps (algebra equations or pseudo-code) compute the linear and angular acceleration, velocity, position and orientation for successive frames for that configuration given I know the object mass, thrust in grams, position of thrust in local-coordinates, direction of thrust in world-coordinates, object inverse inertia tensor, and duration of each frame?

Is that short enough?