I try to create game for Android and I have problem with high speed objects, they don\'t wanna to collide.
I have Sphere with Sphere Collider and Bouncy material, an
See:
You could also try changing the fixed time step for physics. The smaller this value, the more times Unity calculates the physics of a scene. But be warned, making this value too small, say <= 0.005, will likely result in an unstable game, especially on a portable device.
The script above is best for bullets or small objects. You can manually force rigid body collisions tests:
public class example : MonoBehaviour {
public RaycastHit hit;
void Update() {
if (rigidbody.SweepTest(transform.forward, out hit, 10))
Debug.Log(hit.distance + "mts distance to obstacle");
}
}
I think the main problem is the manipulation of Rigidbody
's velocity
. I would try the following to solve the problem.
IncreaseBallVelocity
and every other manipulation of Rigidbody
is called within FixedUpdate
. Check that there are no other manipulations to Transform.position
.AddForce
or similar methods so the physics engine has a higher chance to calculate all dependencies.Another point I stumbled upon were meshes that are scaled very much. Having a GameObject
with scale <= 0.01 or >= 100 has definitely a negative impact on physics calculation. According to the docs and this Unity forum entry from one of the gurus you should avoid Transform.scale values != 1
Still not happy? OK then the next test is starting with high velocities but no acceleration. At this phase we want to know, if the high velocity itself or the acceleration is to blame for the problem. It would be interesting to know the velocities' values at which the physics engine starts to fail - please post them so that we can compare them.
EDIT: Some more things to investigate
6.7 m/sec does not sound that much so that I guess there is a special reason or a combination of reasons why things go wrong.
Fixed Timestep
. Note that this might kill the frame rate but that can be dfixed later.0.01
FixedTimestep
? This would indicate that the physics engine might be in trouble.Rigidbody
) that are moved around or manipulated otherwise? This would cause heavy recalculations within PhysX.transform.scale
is not to blame for it (I made really bad experience with this).TimeManager.timeScale
from within a script?