I've just released a game on the Play store, "Clamber", which makes use of Unity 2D physics. The player drags the 'hands' of the character around to climb up through the level. This was achieved by setting the velocity of the hand to the frame-to-frame motion of the player's finger, divided by Time.deltatime. In the previous version of Unity, all was silky smooth and perfect. In 4.5, it's garbage. The hand judders and falls behind the player's finger; it doesn't move smoothly at all despite zero code changes from the release build. It's not a frame-rate issue; the screen is still scrolling smoothly. I don't know what the heck has happened but it's utterly ruined the feel of the game and I'm obliged to roll back. Conceivably it's the mouse/touch input rather than the physics that's the problem (which manifests both in the editor and on device), since all other physics based stuff (including the body of the character) seems to move smoothly. Anyone have any ideas? EDIT: All the physics and time settings are the same in both. I've now rolled back to 4.3.4 and the problem has gone away.
Huh. Android, right? I don't see any changes to the touch controls in Android in the release notes. Have you tried using mouse input to distinguish whether it's coming from the input or the physics? My off-hand guess would be that it is a physics thing, since that update broke my game's physics in several seemingly random places (ironically mostly bug fixes).
Add me to the list. I have a fairly simple 2D physics game and 4.5 has apparently changed the laws of physics completely. Firstly, everything is running about 1/3 the speed it was (not framerate, just the physics). All settings are the same as far as I can tell. Objects don't bounce or roll or fall the same way. Being a puzzle game I need to rely on the physics, and I was hoping that 4.5 would fix the issues with 4.3 (a show-stopping bug in Windows Store x86 builds and occasional inconsistent physics behaviour), which seems to be the case...but at the cost of altering the physics so much that the game is massively broken in 4.5.
Hey pumpkinszwan, have you tried messing with Rigidbody2D.inertia? They completely changed how rotational inertia is calculated, and exposed it there.
There is something wrong with the physics in the new version of Unity. Look at the 2d demo project. I recorded a video, that shows errors (vsync ON), the main character jumps quite weird. https://www.youtube.com/watch?v=AHV8y08GEE8 Interesting is a fact, that interpolation works differently for vsync-off and vsync-on. However if you disable an animator, then it works. Now Rigidbody.Interpolate: interpolate causes that main character stutters, but background doesn't. In unity 4.3.3 everything works correctly (free version). You can not work now physics in the original demo 2d? Do you also have a problems with physics in 2d demo project?
Yep, inertia is the key! I think I got the fix from one of your other posts. The only problem is that now I have to figure out the right values for all my items. At least my game is now acting more or less like in 4.3.
Hi!, Would it be possible for you to post a bug report so that I can look at what you're seeing. I certainly don't expect you to have problems as you describe and have not seen any other similar reports during the alpha/beta cycles. If you can do that then post the case number so I can look at it quicker.
Same problem here, had to manually set inertia for all the ragdolls, cables and procedural controlled enemies. MelvMay, The inertia is calculated incorrectly, try making 2 circles of same mass but different radius, they'll have same inertia. Inertia for circle is calculated like this: I = m * r * r / 2 So bigger circle should have bigger inertia. //another observation: inertia always seems to equal (mass + 0.1), regardless of object shape For now i solved it with extra component that sets inertia. I'm porting the box2d inertia calculating algorithm now, so it can calculate the correct inertia automatically. //done: http://forum.unity3d.com/threads/24...ia-fix-InertiaCalculator-component-and-editor
From the release notes: •2D rigid-body rotational inertia no longer scales with collider size but rather with the rigid-body mass. So... They're classifying that as a fix.
This is one of those situations where many users wanted the inertia to stay the same (simplified model) if the mass wasn't changed however others require it to work more naturally. The idea was to allow you to select how this was calculated so we could accommodate both parties but that never happened. I'll make the modification this morning to restore that aspect and we'll get a fix out. Additionally, Unity is focused on setting explicit mass so we have to fudge stuff behind the scenes for Box2D as it wants to work with shape density/area to calculate overall mass. The calculation such as the one you specify is done at the same time the total rigid-body mass is calculated. After that we override the mass therefore the actual rotational inertia is based upon the mass of the fixture which isn't used for the total mass. The idea was to eventual provide an option (drop-down) on the rigid-body that allows you to select how the mass/inertia is calculated. Then we could accommodate everyone with a bunch of settings such as explicit mass, implicit mass (based upon shape density/area) etc. Sorry this has caused you some issues, I'll get it rectified quickly.
This is the first thing I noticed when I updated to 4.5. In my platformer, whenever I set a game object to active for example, my player stutters. It's even more noticeable if you have the main camera set as the child of the player as the whole screen stutters.
Here's the solution for inertia calculation based on explicit mass: http://forum.unity3d.com/threads/24...ia-fix-InertiaCalculator-component-and-editor Inertia is always proportional to mass, so you just need to calculate hypothetical mass and inertia based on hypothetical density, and: explicit_inertia = hypothetic_inertia * explicit_mass / hypothetic mass; My game relies heavily on physics, occasionally with things like this: It relies on complex rigidbody control, exposing inertia property in 4.5 was a real gift, but new inertia calculation algorithm is completely wrong. It might work for simple single-bodied objects, but none of the above is possible with new inertia calculation. My suggestion would be to use Box2D inertia calculation (like in thread above), and add inertia_multiplier property to rigidbodies, so it would be possible to make inertia proportionally higher or lower.
I've already fixed this and I'm looking at getting this out to you quickly along with some other fixes that have been done since the 4.5 release. Sorry for the hassle this has caused you.
No worries, you're within your right to complain if stuff don't work! Your GIFs look awesome! BTW: Whilst I'm confident this fix works, essentially you now have what Box2D calculates again, if there's some test project you can/would submit in a bug-report then I'd appreciate it. If you do manage to do that, provide me with the case and I'll check it immediately.