Relativistic friction (and "bounciness," and "drag")
Closed this issue · 8 comments
Unity gives the option of a 1 or 2 dimensional Coulomb friction model, or else a "patch" model that is similar but tends to converge in fewer PhysX solver iterations.
By the Coulomb model, the energy dissipated by friction is proportional to the distance over which it acts, (in addition to friction's proportion to normal force). We assume, for relativistic purposes, that frictional dissipation of energy should be invariant over proper distance of an object's path. That is, holding the proper length of a path integral fixed, all observers should agree on the total frictional dissipation. (Though, I'm not yet decided on whether effective "baseline" coefficient of friction over a proper length also depends on relative velocity between the surfaces. The Coulomb model might not adapt to relativistic physics, otherwise.)
Just letting PhysX handle friction as we have it, I think the above assumption will not be satisfied. Rather, I think we need to dynamically vary a PhysicsMaterial coefficient of friction, to satisfy our assumption of invariant frictional dissipation over proper length. This is possible, and I will implement it.
(In other words, the coefficient of friction should carry an inverse length contraction factor, commonly called "gamma," as in the Lorentz transform.)
Let me disambiguate, as I think about it. Say we have a Rigidbody, "A," and a surface it contacts, "B." We have two pertinent (relative) velocities:
- ...The velocity of "A" (or "B") relative to the player, upon which friction should not at all depend. (Hopefully, the lack of dependence should be self-evident, here. In other words, the frictional dissipation should not directly depend on my relative velocity as I fly by a system undergoing friction, as I do not participate in the friction mechanics as a distant observer.)
- ... The velocity of "A" relative to "B," which might carry some dependence for "effective, basline" coefficient of friction, as due to length contraction between "A" and "B."
Primarily, I want to correct for the fact that our current implementation does not respect the invariance of velocity type 1. However, 2 might also factor in. 2 is not the difference between nominal "static" and "dynamic" coefficients of friction in the Coloumb model, though 2 self-consistently could not affect the "static" coefficient, since "static coefficient of friction" implies that "type 2 velocity," relative between "A" and "B," starts out as 0.
I think, as we correct with a type 1 inverse length contraction factor, we correct with a type 2 length contraction factor, not inverse, different factors as defined.
Whether I care about quantity "gamma" or its reciprocal in either case, the point is that we need intervention to avoid a "default" that fails to agree with the assumption behind type 1, whereas we introduce a new, exotic effect for type 2.
However, I think we just drop type 2, if it exists, because we'd need a different PhysicsMaterial for every contact surface in an engine where we can have an arbitrary number of different contact surfaces at once in a PhysX FixedUpdate() frame, whereas an object has only one specific PhysicsMaterial during internal physics update.
("I'm still pondering, Pinkie," and we might actually get "type 2" "by default," actually, if we actively correct for "type 1.")
I'll have to research further, but I think "drag" effects might be time domain, whereas these friction equations I'm describing are distance domain. In that case, drag might already be correctly calculated, as it is.
Without thinking about it too hard, "bounciness," or "coefficient of restitution," also should not depend on "type 1" velocity of the non-interacting player relative a "bouncing" system of "A" and "B."
Therefore, it happens, all numerical parameters of PhysicsMaterial need this same correction, including "bounciness."
What about "drag," after all?
Via a quick "googling," a number of speculative internet discussions surmise via their own experiments, for sake of my anecdote, that Unity calculates "drag" something like this:
velocity = velocity * (1 - drag * Time.deltaTime);
Frankly, this is just a bad physical model of pneumatic drag. However, let's accept it at face value.
If we want relativistic Unity "physics" to reproduce intrinsic drag as we expect for Unity, then the phenomenon specifically should not at all depend on the "type 1" velocity, as defined above, of the player perspective relative to the system. Self-consistently, this drag formula should replace the "game world" time with the relativistic proper time.
That's it. I'll have it in a minute.