I have a sphere with bounciness set to 1
The ball has no drag and uses gravity
It hits a platform, which has bounciness set to 1 and no friction
Yet, the ball bounces higher on every bounce, going to infinity. How is such a thing possible, when I have not given it any extra momentum?
The issue comes from the fact that physics in games happens in discrete frames, and that a moving object will be "inside" another at the frame where there is a collision. The physics engine then has to separate the objects before the next frame, and figure out how much energy to "bounce" with.
One of the steps to do this involves figuring out how much the objects overlap, and that's where this phantom extra energy is comin from. Less error in the overlap equals less error in the energy.
Don't fiddle with the bounciness; those are naive solutions, not to mention they sidestep the issue rather than solving it.
What you should do is to fix what's wrong with your collisions. That can be done a number of ways, the most appropriate/performant of which depends on each specific game:
Increase your physics frame rate (decrease fixed delta time). This reduces overlaps and makes physics frames "smoother". It doesn't really solve phantom energy though; only makes it's causes and effects smaller (maybe so small they become unnoticeable, which is all you need).
Set your sphere's collision detection method to Continuous Dynamic,
and set your ground to static. If you need the sphere to collide with
other stuff, those other stuff present similar issues, and those need
to be non-static, set their rigidbodies' collision detection method
to Continuous. (This is the method I most often find to be the best, but I've had projects where others were better for various reasons)
Increase your Default Solver Velocity Iterations
Change your solver type to Temporal Gauss Seidel
I have had a similar issue with javascript/html/css canvas animations. I have no explanation for this. Use a number like 0.99999 or 0.969399 and that should do the trick. I do get what you mean though it's weird. Just get close to 1. That's all I can say. I hope this helps anyway.
Related
I have this simple domino scene where you can click a domino and apply a force to knock it.
At first I had this dominoes in a scale of (x=0.1), (y=0.6), (z=0.3) 1 is supposed to be 1 meter, they fell without a problem but too slow. According to unity documentation on Rigidbody this made total sense.
Use the right size.
The size of the your GameObject’s mesh is much more important than the mass of the Rigidbody. If you find that your Rigidbody is not behaving exactly how you expect - it moves slowly, floats, or doesn’t collide correctly - consider adjusting the scale of your mesh asset. Unity’s default unit scale is 1 unit = 1 meter, so the scale of your imported mesh is maintained, and applied to physics calculations. For example, a crumbling skyscraper is going to fall apart very differently than a tower made of toy blocks, so objects of different sizes should be modeled to accurate scale.
So I just re sized the dominoes to (x=0.01), (y=0.06), (z=0.03), this time they fell to the desired speed but for some reason they stop falling and don't knock the next domino.
example GIF
I don't know why this is happening but i can guess that this is because at the time of calculating physics the engine doesn't waste so much resources in calculating small objects that are probably not even going to be seen by the user.
Modifying mass doesn't seem to do anything, also draw and angular draw are both 0 and already tried every collision detection mode.
Is there any solution or workaround for this?
In my experience, Unity physics doesn't like too small objects since it introduces rounding errors. A game simulation usually does not need the same accuracy as when you try to land on Mars. Therefore, I usually avoid scales less than 0.1f.
In your case, I would keep the scales at 1.0f and instead experiment with either increasing the world gravitation, changing it from the default -9.81f to -98.1f (Edit - Project Settings - Physics). Or changing the default Time Scale from 1f to 5f (Edit - Project Settings - Time).
Try not to make too big changes in the beginning since it might introduce strange effects on other parts of the gameplay.
As usual, the documentation lacking some information we have to gather somewhere else: Physics.defaultContactOffset.
Physics.defaultContactOffset is used by the collision detection system to predictively enforce the contact constraint.
Unity explains you should use 1 unit = 1 meter for physic simulation.
I needed a lot of small spheres and cubes: 10cm width. Thus 0,1 "unit".
What they dont say is that when you're working on a small scale (I'm using objects of 0,1m width = 10cm) you have to change Physics.defaultContactOffset to a smaller value than the default one.
Hence my question: is Physics.defaultContactOffset important for calculations, i.e. if I change this to a very small value, does it have a negative impact on performance?
I have to change it from 0.001 to 0.00001 to get an acceptable collision detection system and I'm worried about a negative impact on performance.
From Unity3D documentation on Default Contact Offset:
Use this to set the distance the collision detection system uses to
generate collision contacts. The value must be positive, and if set
too close to zero, it can cause jitter. This is set to 0.01 by
default. Colliders only generate collision contacts if their distance
is less than the sum of their contact offset values.
So we can assume the physics engine is calculating distances between colliders and checking if the distance counts as a collision or not. I don't think it matters so much for performance as the calculation is done anyway.
With all this being said, Unity3d physics engine doesn't really do well with tiny objects, so it's better if you scale the spheres up to 1 unit, and scale everything else to compensate. You will most likely run into issues with these tiny colliders.
Here is what happens when I copy&paste a few thin boxes, and then vertex-snap them to the ground and each other:
Pressing "Play" leads to the stack toppling.
I tried reducing the BoxCollider y to 0.99 and 0.95. No luck still.
Does anyone have recommendations to easily get a stacked wall to just stay up (until a real force is applied)? Maybe there is some sort of "glue" component to prevent two faces separating until a force exceeds some threshold?
Try setting their positions manually so that they are right under each other.
You shouldn't expect to be able to make a stack of 20-30 box colliders stacked on their smaller faces because of physics simulation inaccuracies, floating point errors and so on. If that's your intention and/or the above doesn't work, try using Fixed Joints with a manually set Break Force and/or Break Torque.
You can also try increasing the Solver Iteration Count to something like 10 or 15 (which should do the trick in most cases), but it won't be good for performance in scenes with 1000s of objects.
Increasing the Sleep Threshold will also help in this specific case, but can cause problems like small objects sleeping when they have small (but not infinitesimal) velocities.
EDIT:
A similar thing happens with my own custom physics engine. Another workaround you can do is to align the bodies and set them to sleep in Start. That way they'll stay upright (not moving rather) and topple when something collides with them.
I'm trying to create a chain in unity3d. A player should be capable of grabing one side of it and pull it to different location. So i created some grids and connect them together. It all works fine, the problem is only when user pulls a bit faster, then I got some spaces bettwen seperate grids. Is there anyway to set max distance on that?
Btw. I'm doing these in 2d so i have 2d Rigidbody and 2d Hinge joint.
Thanks!
The solverIterationCount of rigidbodies affects the smoothness of physics when they are moving fast. You should try increasing it or dynamically adjusting it according to the speed of the rigidbodies to increase stabilty
http://docs.unity3d.com/Documentation/ScriptReference/Physics-solverIterationCount.html
There a number of ways to tackle this issue, all with the up sides and down sides:
increasing accuracy:: this is usually the first place new game designers go, and crank up accuracy to the max. But then end up playing the price later when performance plummets. So be gentle, try to find a good balance, and if it does not cut it make up the rest with other tricks.
The main ways to increase accuracy are, increasing fixed times interval, and increasing ridged body Iteration count
.
Increasing restrictions::This often requires the most time, but cutting corners allows for smoother more predictable physics and can increase performance
small example:: the top link of the chain only needs to simulate rotation on the ridged body
.
Cheating:: find any way to make things easier, fake it
for example:: does the image really need to match the physics? Why not make sure the sprites stick together, but alow the physics to have small gaps
playing with the same concept more or less this week, experimented some with 2D Unity joints, I think the issue you are having is identical to one I had yesterday, the force you are applying 'breaks' joints for some frames, hence that almost 'spring' joint effect, make sure the mass and/or force applied are not too heavy, also maybe increase the chain parts mass, makes the joints more solid too.
In Editor, Hinge Joint -> Use Spring = true; Spring/Damper/Target Position = 0.
In Unity I noticed that the collision boxes of two moving objects are intersecting and entering each other physically. Is this a normal behaviour?
Also, changing the collision detection to Continuous has little to no effect.
Yes.
http://docs.unity3d.com/Documentation/Components/class-PhysicsManager.html
Min Penetration For Penalty How deep in meters are two objects allowed
to penetrate before the collision solver pushes them apart. A higher
value will make objects penetrate more but reduces jitter.