koobas.hobune.stream
Can someone explain how unity calculates forces because this just doesn't make sense.
Even with all units being generic, forces should still be calculated using the proper formulas, but unity seems to just throw logic out the window and use made up crap to calculate forces.
with a gravity of -10, I took a box (call it boxA) of mass 1 attached with a fixed joint to a box (call it boxB) fixed in space, i set the break force to 10, and slowly increased the mass of boxA until the joint broke. oddly enough a mass of ~16.0802 was needed to break to joint, to add to the strangeness, the reported breakforce (via onjointbreak) was an insane number in the billions (something like 1.065353E+09). This just doesn't make sense, unless that huge number is measured in microns or something it just doesn't make sense...
I know my physics, and this is just ... wtf?
The reason for the late break is the forcemode, which is ForceMode.Force. This means the rigidbody gets accellerated over time rather than instantly. The joint breaks are made for explosion like forces rather than gradual ones.
I tested it myself and I was able to increase the mass to about 50, which matches my physics frame rate. When I applied forces via script using AddForce(*, ForceMode.Impulse) it worked like you would expect it.
In real life physics the force is mass time change of velocity over time. You calculate it for an infinitesial small time step. In computer physics however this is generally impossible. The smalles fraction of time we could deal with in unity is one (physics) frame. However it seems like the joints have been tweaked for a timestep of one second. Else the joint break was framerate dependant which is to avoid whenever possible.
For the debug message: I got the same thing even if I applied a force of 14 manually. I suggest you file a bug report for this one.
While I appreciate the strong and informative answer, It doesn't satisfy my question see as I'm not using AddForce. I've run this test by setting the mass, pressing play, and then stopping, changing the mass, and starting the scene again. It has nothing to do with ti$$anonymous$$g.
Gravity works a bit different from AddForce. For example: gravity won't wake a rigidbody up. The first test of $$anonymous$$e was using gravity too. I guess I should have made this more clear.
I had a rigidbody of mass increasing and a fixed joint with a break force of 10 and the default gravity of 9.81. According to my previous explanation, you need to apply a force which causes a change of velocity from 0 to 10 in one second. But this force must be applied in one physics frame.
In my first go, I had the default fixed timestep of 0.02 or 50 physics frames per second. Which means a per frame force of mass*gravity/50. Thus the break mass was about 50 which matched my experiment.
To double check I have set the fixed timestep to 1 which means one physics frame per second. This resulted in a per frame force of mass*gravity. As predicted the break mass was now slightly above 1. The experiment matched my predictions. If you want to repeat this you must keep in $$anonymous$$d that the physics framerate is only 1 and thus the rigidbody will only move once a second. So don't change the mass too quickly.
And yes, this means the joint break caused by gravity is dependant on the physics frame rate. However since the physics frame rate is fixed, this is a bit less of a problem than beeing regular frame rate dependant.
How strange. I mean, It makes sense, given that acceleration is distance/time^2 (m/s^2)and timestep is 0.02s/1s... mmm, In my $$anonymous$$d I'm thinking of real word physics, and that's probably why It seems so odd. I realize there's a reason for the calculation to take that into account, I just wish it used a double standard because why you want a timestep around 0.02 for smothness, calculations should be made with respect to real world time while behaving in game time... bleh, i'll just have to calculate all my numbers to match scale.
