physics question, centripetal force

Unity Engine
1

Hello ppl,

I know Unity is not an accurate physics simulation tool but I would like to find out whether this is a limitation of the physics engine or something I have calculated wrong. Any help is appreciated.

I am trying to simulate electron movement in electromagnetic field. The B is constant, positive and parallel to y ( B= (0,1,0) ). Thus its movement is like the one demonstrated here:

In the fixedUpdate of the particle I am adding the following force:

rigidbody.AddForce( Vector3.Cross(rigidbody.velocity, Vector3.up)); (dF = uxB, q not needed)

Thus in each frame I add a force vertical to its velocity. Assuming that Uy=0, the expected trace is a circle(as shown in the video in youtube but flat). However, in Unity, the radius of the circle slowly increases like this:

I have m=1, drag=0, angular drag = 0, use gravity =0, is kinematic =0, no constraints and no interpolation.

Is this something related to floating point errors or something related to the force mode?

I added *deltatime but this does not change anything

2

addforce isn’t a constant, it will cause the object accelerate based on the mass of the object, could this be why?

Set iterations to 100 for testing and set fixedupdate to 100 for testing too, to see it it’s a physics resolution problem.

Try setting the velocity manually in some cases for testing.

3

hmm,

I meant perpendicular. The term vertical must be wrong. Anyway.

The force would be perpendicular to the velocity of the object so it shouldn’t change the magnitude of the velocity, only it’s direction. This means that although the object is “accelerated” it shouldn’t move faster.

However it seems you are right. What actually is happening is that the magnitude of the velocity slowly increases, thus increasing the radius of the movement. If I decrease the mass the velocity and the radius increases faster which makes sense. Less mass, more speed.

However when force is perpendicular, this shouldn’t happen at all. The velocity magnitude should be constant.

Any idea how to work around this?

4

it shouldn’t happen yes.
But from the description it sounds more like its related to physics code in the wrong place (“each frame”)

Physics.XXX and Rigidbody.XXX are functions that are not meant to be used outside of FixedUpdate (so not each frame, only each physics update), because they will otherwise cause major anti-physical behavior and become frame rate dependent. in such a case it would actually accelerate even when perpendicular accelerated, unless you use the constant force component and change the force on that as that does not “apply a new force on each change” like AddForce does, it only changes a present force that does not have an impact until the next fixedupdate

5

You can cap the maximum speed with rb.velocity = Vector3.ClampMagnitude(rb.velocity, maximum); each frame, or set up damping, otherwise in theory it can probably accelerate forever, or at least slowly until it finally reaches your intended force. This can take quite a while.

To fix, I recommend a decent amount of addforce (you can also set the initial velocity to that of the force to begin) and then clamp it with Vector3.ClampMagnitude each frame for fine control.

6

@dreamora,

Useful info about constant force, didn’t know about that. My code is in fixedupdate, and the only related addforce is the one in my first post.

Here is a simply code to use to see the problem, you don’t need anything else, just copy it to a script, assign it to a sphere and press fire once:

7

I cannot understand why in theory it would accelerate forever :frowning:

Also, where should I clamp the mangitude? in fixed update or in update?

8

Instead of mass = 1 you can use mass = 0.2 or 0.3. It will make it obvious,

It reaches |u|=10.000.000 in less than a minute.

9

I don’t mean forever, I mean that it can take up to forever depending on your physics settings, to accelerate to the perfect value you need.

Clamp in fixed after all your other stuff.

10

hm, clamp would work if I could clamp only x and z and keep y the same.

The new problem is that clamp affects uy too, slowing decreasing its speed, so the particle only moves up to a height and then stops ascending even though it should continue moving upwards for ever. The mathematical errors in xz in combination with magnitude clamping result in gradual loss of the uy component

since:

ux^2+uy^2+uz^2 = const = u

=>

ux^2 + uy^2 = u-uz^2

It seems i want to clamp x^2+y^2 to u - z^2, without affecting uz at all.

mouble mouble …