During 2017.2 beta, @PhilSA found a regression that rigidbody interpolation now has hiccups:
The issue has been marked as won’t fix:
I guess marking this as won’t fix is a mistake? If it’s not, an explanation why it’s not going to be fixed would be appreciated.
I am hoping that the “Won’t Fix” just means that they won’t fix it in its current state, because it’ll get fixed either way when they’ll integrate PhysX 3.4 in 2018.X. Or maybe when they jobify physics.
…or something like that
fingers crossed
I don’t know. If it gets fixed at a later time, I suppose they would have used “Postponed” rather than “Won’t fix”. “Won’t fix” sounds rather explicit to me, normally not much room for speculation.
But that’s part of why I was asking, to understand the reason behind that. I don’t believe they leave it in a broken state on purpose, that would be absurd. Which is why I asked if it has been marked as “Won’t fix” by mistake.
More context in this regard would help to put things into perspective.
Won’t fix, in my experience, usually means that the QA team misunderstood the problem and it needs to be escalated.
I asked the physics team to take another look at the issue and to communicate here if they have questions.
Hi folks,
Sorry for the confusion as well as the delayed post in here.
So yes, we had to close the original case as Won’t Fix since, unfortunately, I couldn’t see a way to approach it. Let me clarify something though.
The original case was classified as a regression in 2017.2, however, I managed to reproduce exactly the same using 5.6.
Additionally, it was discovered that the case had some framerate-dependent code, and behaved differently in editor and players since forever. At that point, even though it seemed there was no obvious reason for it to behave like it behaved, it showed some signs of a partially invalid report anyways. This is how it got closed after spending some time on it.
Now, there were other reports about interpolation affecting user’s projects in an unexpected way. The most recent went in as an iOS-only issue, but has been proven to be a cross-platform issue since then. It’s in the queue to be looked at. I’m sure there will be an update soon.
Finally, an upgrade to PhysX 3.4 is actually being worked on and there are early signs it improves things significantly indeed.
Anthony
R&D Physics
Thanks for the response Yant. Really looking forward to PhysX 3.4!
However, just a quick comment on this:
I realize that the project attached to the issue (and linked in the first post of the original thread) had a camera moving around on Update(), which unneccessarily complicated the diagnostic of the problem. However, I made a second project (second post of the original thread) that takes away all of that uncertainty. It shows just a simple cube that rotates on FixedUpdate() and pretty much nothing else
either way I guess we can wait and see what’s what once PhysX 3.4 is here
Thanks yant!