The green column on the left is rotation-constrained and is resting on the white platform. The red column on the right is a clone of the column on the left, but with the Y constraint ticked. Notice what happens when the identical green boxes fall onto each.
Also:
Gravity is zeroed on the red column, but it doesn’t make any difference if it’s non-zero.
It doesn’t make any difference if you move the white platform from underneath the red column.
If you freeze X as well, it seems to behave itself better.
Removing the rotation constraint has no meaningful effect.
So far as I can tell, no combination of interpolation/discrete/continuous solves the problem.
As things are, constraining Y doesn’t seem to be a usable option, as anything dropped on top of it will misbehave or even fall straight through.
You really need to post a simple project that contains the physics settings, version etc. A raw scene is likely to be a waste of time. Delete the Library/Obj/Logs folders and it’ll be tiny.
Constraints are super solid so this would surprise me a lot. Indeed, they were improved a while back and are pretty much perfect so I’d like to see this happening.
Project/physics settings were vanilla. No scripts, no packages, no assets. I just created a new 2D project, dropped a few ‘square’ sprites into the scene, added box collider2D and RigidBody2D as needed, and then ticked the Y constraint of the red box.
If you really need the project, gimme a few and I’ll sort it out for you.
Well that is surprising because it’s not changed and as you can see in the video, they are extremely stable because that is a Dynamic body with both X and Y position constraints on and it actually doesn’t move at all.
If anything I would say report it as a bug and send me the case number because if there is an edge-case you’ve found then it can be moved forward with a fix.
I just tried loading it up again after deleting those folders, and interestingly enough, the behaviour was slightly different. Still broken, but not the same as it had (reliably) been yesterday. Different order of collider processing, maybe?
So this is just the solver not knowing what to do because this is a non-physical situation it finds itself in.
If you stop the red block from rotating (constrain Z) then in theory this should reduce/stop it. The problem is that you have two contact points almost at the same position so when it impacts, the block cannot move down but it can shift sideways and also rotate. While in theory it shouldn’t rotate, tiny differences in the contact points between them will indicate a torque and at that point with it slightly rotated, those contacts are overlapping and the solver will quickly separate the two. In what I just saw, it moves it the shortest distance which is sideways.
Unfortunately there are edge-cases like this throughout the physics system and it’s a stability issue where the solver just focuses on solving the overlap but ends-up overshooting the response. You normally see this with more complex joint set-ups where they explode. Here it’s a relative simple method to set-up as you’ve shown.
To be clear, I’ll continue to look at this but it’ll be in the morning because it’s getting late here. I’ll see if there’s anything that can be done to solve this instability.
Oddly, you are right that locking rotation eliminates the bad behaviour - but it definitely didn’t yesterday: as I mentioned in the OP, I tried toggling the other constraints and only X had an effect. I’m assuming that’s some further wrinkle with collider processing order that’s been affected by restarting Unity or deleting the library folders.
Anyway, it can be worked around by manually pushing the platform back to its Y position rather than relying on the constraint.
I only found this edge case because I was working on an extension plugin for the 2D physics that supports transmission and transformation of forces between rigidbodies, so that you can create the illusion of platforms etc being mechanically connected behind the scenes:
Deleting the library folder wouldn’t have any effect on physics nor processing order… It makes no difference to this whatsoever even if it did process them in a different order. The contacts are all calculated before anything is moved/modified.
Note that I cannot see any videos above. It just says “This video is unavailable”.
Doink. Had left the videos as ‘Private’, so of course I can see them and thought they had worked…
Yes. It’s a niche case, but a platform that can tilt or rotate so the player has to balance it, and one where rotating it also pushes it sideways to cross a gap, are things I wanted for my current project.
I just wanted to take the time to reassure you that this is being looked at and I’ve identified the issue. We’re doing a bunch of testing however because the changes here are very difficult to cover with unit-tests due to the dynamic nature of it.
FYI, I had another instance today where a rigidbody2D that was frozen in both Y and Rotation was misbehaving in a similar manner to that seen in the videos (objects on top pushing it sideways or falling through entirely)
After not being able to replicate it last week, I thought I had been mistaken, but it can definitely happen. The wheels are off my project at the moment, but as soon as I have something stable to parcel up, I can submit another bug report so you can check your fix, if you would like.
No, please don’t submit another bug report as it’ll likely be the same thing. If you want to host a project that demonstrates it then that would be better. If you need me to set-up a place to host it too, I can do that if you DM me with your email.
I’ve pushed the fix to our repo so it’s in the hands of QA right now so if you do have another edge-case then I’d love to check that before it goes further.
