Major Bugs in the Physics Engine

Unity Engine
1

Hi everyone, I’m new to Unity. I’m in the process of learning it. For background info, so far I’ve looked through all the intro documentation, read the entire User Manual, done most of the 3D Platformer Tutorial, and read the initial scripting reference pages.

Anyway, on to the matter at hand. I’ve found several bugs in the physics engine. Looks like some related issues have been mentioned a few times in the forum but never truly addressed by the Unity team. Here’s the errors:

Bug 1

If you drop a simple rigidbody cube or sphere object with material set to “Bouncy” from rest above a flat collider surface the object will begin bouncing higher and higher with every bounce even though no force or energy is being added to the system.

This is a violation of the Law of Conservation of Momentum, which is quite possibly the most fundamental law of physics, seeing as Newton’s laws are essentially based on the principle. For such a simple case, the fact that this error occurs is very alarming. Even when dropped at small heights of 2 “meters” or so the objects will quickly start gaining height at a rate of about a tenth of a meter per cycle, which is a HUGE error in the context. Yes, engines have numeric errors, but for such a simple system of objects the error is unbelievably high.

Bug 2

Cubes which bounce like in the above scenario also slowly move along the x-axis, even though the collision normal force should be exclusively upwards.

Bug 3

Unity’s simulation of drag for rigidbodies completely ignores the effect of the object’s mass against the drag. In physics, objects with greater mass should have a higher terminal velocity (which is caused by drag) than those with less mass.

For example, when the bouncing objects in the above scenarios have drag values set they will (bizarrely) gradually gain or lose height until they are at equilibrium with a bouncing height related to the terminal velocity of the drag they experience. However, the problem is if you then change the mass of the bouncing object (such as changing it from 1 kg to 999999 kg) then the bouncing height will not re-balance to a new height, which means the terminal velocity isn’t changing either even though the mass has been changed. In other words, Unity’s implementation of drag doesn’t follow even the most basic rules of real world drag, so it seems.

These bugs are all very obvious, and it feels almost as though the Unity physics system was therefore barely tested at all. These are practically the very first things that the people testing the engine should have been looking for, as they are extremely simple and obvious cases to test, which have potentially catastrophic consequences for the game state.

On a different subject:

Unity does not sufficiently document the units of many of it’s components. For example, is the static friction value the coefficient of friction or is it the max force with which the surface can resist friction motion? It appears to be the former (the coefficient of friction) but nonetheless it would be wise to document such things. Many of the most important technical aspects of the unity engine are often left almost completely undocumented, often having only a brief description of the obvious and not the relevant technical facts one needs to properly use it without resorting to excessive testing and guess work to derive the underlying interpretation based on context and effect.

I’ve got some other issues to address as well, but I’ll leave it at that for now for the sake of thread relevance.

2

If you fell that you have found a bug you should submit it as such through the help → report a bug menu in the unity editor. It is always best to be able to submit a project that reproduces the error to us as well.

I can confirm that all three errors do reproduce on my machine. However these may not be errors that we have introduced as we use PhysX so it may be that the bug lies within that system and not ours.

Once you submit a bug for these errors then you will get a reply once a developer is working on it

3

Gravity is a force though. And if you submit values above 1.0 for bounciness, it will add energy to the bounce. That is energy being added to the system.

Also, bounce threshold in physics options will determine if it should equalize at that particular bounce or not. Depending on your other parameters such as mass, or iterations to solve, and penetration depth, you will find that gravity can in some circumstances, push the object into the collider floor, which will also gain energy to escape from, leading to a spring effect, and other undesirables.

I am finding many little quirks which I’m not sure are actually bugs but rather problems with the physics parameters in the performance vs accuracy war. I’m not 100% certain this part is buggy or its just bad parameters.

For bug 2 3, I haven’t anything to add, they sound pretty terrible though. I can confirm it doesn’t happen with spheres. Does it still occur if you fix the cube rigid body so it cannot rotate? I would imagine it would drift due to cube edge being lower on one side over time due to floating point inaccuracies.

From what I have tested and heard, I believe its a lot to do with cubes, and perhaps if their rotation isn’t fixed.

4

The physics system is nVidia’s PhysX, and it’s been tested a lot actually. It’s not intended to be 100% accurate with regards to real-world physics. Some simplifications have to be made for the sake of performance. It’s sufficient for most game physics, like tossing crates around when they’re blown up by a grenade. If you need a more realistic simulation, then it wouldn’t be suitable for you.

–Eric

5

Yeah, I agree that my statement of it not being tested much was perhaps too much, especially considering I even knew it was PhysX and such. I should have worded it less harshly and I apologize for that.

However, I still must stand firm on the point that the bouncing error accumulates way too quickly. Sure, it’s nearly impossible to expect a timesteped simulation with floating point calculations to not drift in either direction eventually. Perfectly balanced floating point computation is extraordinarily difficult after all. Nonetheless, one can still often find clever ways to refresh floating point values using knowledge of the starting conditions, as that is often the easiest way to deal with float drift.

It’s to be expected that drift occurs, but I find the rate at which this drift occurs here to be jawdropping in terms of numeric error. I’m not asking for a perfect physics system, just one that has a more reasonable lifespan before it degenerates from errors. The 20 seconds in this example is not by any means a reasonable stability lifespan, even for a game.

I don’t need a perfect physics engine, and I’m well aware of real-time constraints in game engines. I simply expect a physics system to be capable of modeling various phenomena with a usable degree of accuracy. These errors make the chances for anomalies too high for comfort.

Essentially these errors force me to either programatically fix the issues myself or to apply additional drag in places where I don’t actually want it in order to achieve simulation stability. In other words, the errors constrain the creativity of the designer, a little bit, or at least are an inconvenience at best.

Again, I must reiterate that even when using someone else physics engine, errors of this magnitude are still unreasonably high.

Don’t push it under the rug like has happened before when this has been brought up, at least in terms of it not being handled. I think it should be possible to add attachments to the engine to reduce the amount of numeric error that PhysX makes. In my experience, the most determining factor in a program’s or game’s quality is the developer’s willingness to fix what’s wrong rather than just accepting it as “the way things are” or whatever. The moment you just except a flaw is the moment that part of the system stops improving.

I’m not trying to knock the efforts of the developers or the usefulness of the PhysX engine. Unity seems like a great and user friendly engine and I very much look forward to building things with it. I just think simple fundamental things like this should be more accurate.

By the way, I had already submitted an error report prior to making this thread. I’m posting it here too just to cover mutiple bases, since it seems this issues has been ignored in the past despite it’s fairly high importance.

In any case, back to learning more about the engine and thinking of a simple game concept to make a game for practice with the engine.

Talk to you guys later surely.