Physics Behaving Differently After Updating Project

I have a scene with several cannons firing their cannonball projectiles at targets. They fire continuously every few seconds. The targets are funnels that aren't much bigger than the balls, so the cannon's trajectory and force has to be set pretty precisely for the ball to hit its target.

I can adjust cannon 1 to hit its target, and it will hit its target every time as long as the camera is looking at cannon 1. But if I change the view so the camera is looking at cannon 2 (cannon 1 still visible in the background), cannon 1 will slightly overshoot its target every time. If I go back to the camera 1 view, it goes back to hitting the target every time. In general, how any particular cannon fires depends on where the camera is at the time. I've quantified the effect by putting triggers in front of the cannons that record the ball's velocity as it leaves the cannon. Velocity varies with camera position even though the force applied to the balls remains the same. When the ball overshoots a target, its velocity is a bit higher than when it hits the target.

I have a particle effect in this scene that was giving me some trouble with frame rate, but I've fixed that problem, and there's no longer any noticeable affect on fps. Also, it makes no difference if the particles are in view or not, nor if they are disabled. The cannon balls touch nothing but air, so there's no friction effect. Camera position is the only variable I've found that effects the way the cannons fire.

This problem is new since updating the project to Unity 2017.2 (I skipped 2017.1). Way back when I started this project in Unity 4.x, and in various 5.x versions, the cannons all fired exactly the same every time with virtually no variability at all, no matter where the camera was or what else was going on in the scene.

 

Probably your best bet is to file a bug report. There are a lot of issues with 2017.2 and physics is one of the big ones. See this thread for an example of what can go wrong:
https://forum.unity.com/threads/2017-2-physics-broken.499886/#post-3296655

 

Thanks. I've also noticed the difference in forces that was mentioned in that thread. In some cases, I've had to change a fixed force applied to an object to get the same effect after updating to 2017.2.

 

If you are applying the forces in fixed update, I didn't think framerate should have much effect.
I'm sure it does but theroretically fixed update should be called the same number of times.
Unless your fixed update is taking too long or your physics sim is doing too much.

But it could easily be bugs too. I have seen the collider bug, which I think might be fixed now in the latest 2027.2 patch.

 

I'm not applying the force in a fixed update or update. I apply a relative force just once, ForceMode.Impulse, to launch a ball. Other than the cannons firing, there's no other physics in the scene. Frame rate should not be an issue, it's now consistently around 60 fps on iOS and higher in the editor.

 

Are you applying the impulse from Update or FixedUpdate? Given the reported issues in 2017.2, I think that the safest bet is using FixedUpdate.

 

The force is applied in neither a FixedUpdate nor Update. When the previous ball lands, it hits a trigger that launches the next one. The force is applied in a function called from OnCollisionEnter. Does it make a difference where/when an impulse force is applied?

 

OnCollisionEnter is called right after the internal physics update, while FixedUpdate is invoked right before it. It should be the same effect, but given the issues in 2017.2 I wouldn't be surprised if something gets changed somehow between OnCollisionEnter and the next internal physics update.

I'd try to applying the impulse from FixedUpdate and see if that makes some difference. You may set some flag to true in OnCollisionEnter, then check for it in FixedUpdate and apply the impulse if necessary.

 

I tried as you suggested, calling the function that applies the force from FixedUpdate, and it makes no difference.

 

I think the best you can do is isolating the situation to a single scene and some test script(s), so the issue can be seen in 2017.2 but not in previous versions. Then submit a bug with it.

 

After not touching this project for a few days, when I ran it this morning it works perfectly again – exact same velocity regardless of where the camera is. I've done nothing to this project since switching the force to FixedUpdate (I left that change in). I've run the scene several times now, by itself, I've navigated back and forth from the main menu, and it's working every time. I had a few other things I'd thought of to try, but now I'm not sure what to do. I'm afraid tomorrow the problem's going to be back, or worse, it'll show up in the build when I submit it for testing.

 

Hmm, it could be a race condition. If you have objects placed in the scene it may be that Unity decided to deserialize and load them in a different order from the last time you ran the project. Bit of a stretch but I've been bitten by this before.

Another possibility is that you previously had your editor up and running for too long and entered play mode too many times without restarting Unity. This is known in 2017.x to cause significant degradation in performance and memory leaks (especially when UIs are involved). Have you tried testing these results in an actual build rather than in the editor? That drop in performance might be affecting things enough to give inaccurate results when performing such precise calculations.

One other thing to consider - though I doubt it actually is affecting anything. If you migrated your project from an earlier version of Unity then you might be unaware that in your physics settings 'Auto Sync Transforms' is likely turned on for backward compatibility. Try turning this off as it might give more consistent results and will certainly improve performance.

Again, these are all stretches and it very likely might be that you are genuinely seeing a bug in Unity. It's best to simply submit a report. At the very least, if it is related to another issue already found they'll tell you it is a duplicate issue and you can track its progress without wasting your time trying to solve a problem that you can't.

 

I built and tested the app on iPad, and it looks like it's working correctly. I'm at least somewhat hopeful now that it will work consistently for our beta testers.

Even so, this is still a problem with the Editor. It's hit or miss in the Editor, sometimes it works, sometimes not. It's not good if the Editor behaves differently than the app.