hi everyone.
I am developing a ball game, and i noticed a strange behaviour of the ball when it hits the edge of the game area.
depending on the velocity of the ball it bounes or it sticks to this edge.
basically for velocity above 150 it bounces, below 150 it stick to the edge.
i have already tried almost every conceivable parameter, friction=0, restitution=1, mass, density, whathever, no changes.
Is there a hidden parameter that allows me to reduce this threshold?
actually i have solved the problem applying an impulse if the contact impulse is less or equal than 150 (this value is correlated to the current size of my scene which is 1136*640)
if the contact impulse is less or equal than 150 i simply apply the same impulse to the ball with the contact normal applied to the center of the ball.
this is a workaround, but i strongly suggest to have a parameter that can handle the threshold that create this strange behaviour.
i strongly suspect, as a matter of fact, that below certain value the physic engine of spritekit set the ball as stopped, to optimize the calculation needed. Probably this behaviour is determined by velocity, impulse, size, timing and it will be an optimal thing to have some sort of control on this one.
Sprite Kit has had this problem ever since the beginning, and I haven't seen any explanation of it. My theory (FWIW) is that when the contact is made with a slowly-moving object, so that the position change between frames would be very small, the object (the object's physics body, I mean) gets entangled in the physics simulation's overlap detection/removal. That is, perhaps in part because of rounding errors or iterative approximations in the physics calculation, the object is detected as overlapping, and a small adjustment is applied to "free" it from the overlap. If this happens in successive frames, the object appears to stick or to slowly slide along the edges.
That's pure speculation, of course, and I don't know of a way around it. One possibility that I haven't tried is to adjust the absolute units of your scene. For example, if you create your scene at double the size (and let its overall scaling bring it down to intended apparent size), you could have double the velocities for all moving objects. That might reduce the relative errors, at least in the cases you care about.
As usual, you should submit a bug report in order to "vote" for a solution to the problem. Other than that, if your workaround gives you the behavior you want, then I'd say to stick with it. 🙂
Quincey, you're totally right about the frame-overlap thing. That's a normal side effect of the default collision-detection algorithm, which is quite efficient but fails to catch small, fast-moving objects. There is, however, an alternate collision-detection algorithm that is a little less efficient but catches everything. To enable it, just set the usesPreciseCollisionDetection property of your SKPhysicsBody to true.
This raises a good question, what is the translation scale from sprites to the physics world. Does 1 pixel = 1 meter inside the simulation? Is there an easy way to change the simulation scale?
One of the first things I learned about Box2d (the physics engine under the hood) is always separate rendering from simulation scale.
i have used precise collision detection but the weird behaviour still exists
applying the impulse at the right time it's the only solution for me (so far)
Hi QuinceyMorris,
The scale does matter as you point out. That is why we recommend camera adjustments be made on a SKCameraNode if possible as that leaves you in control of how much you want the world scaled according to physics units.
If movement is too slow there may be a clamp to prevent oscillation, to avoid this scale your world and objects to match. You can also use SKPhysicsWorld.speed to adjust the units allowing you larger velocities whilst maintaining visuals.
As you mention, please file radars if you get stuck or none of the points above helped.
Cheers
