- Home /
No bounce after rigidbody collision
I am seeing a common issue: a rigidbody passing through a collider that previously worked perfectly. I've tried many common solutions as well, but now I'm just confused. When I saw the rigidbody triggering an OnCollisionEnter event as it passed through the collider, I pretty much gave up!
Who the f--k said breakout clones were easy? =D
I am trying to understand why this is happening, and how to solve this issue without hackery. I just want the ball to bounce, on and on and on.
Additional data:
The "ball" is a cube. It's a rigidbody. All rotation is disabled. Movement on the Z axis is disabled.
All walls are orthogonally aligned colliders. They are as wide as the ball on the axis they will hit it on.
Both the ball and walls have a physics material with zero friction and a bounciness of 1. (in other words, it should bounce for infinity)
When the ball "escapes," its position has always passed the wall's position, on the axis of intended reflection. The ball's previous position is always on the other side of the wall.
Solutions attempted:
I cranked Fixed Timestep down to 0.01. This just made it take longer for the issue to appear.
I set Maximum Allowed Timestep to 0.05
I used the DontGoThroughThings script on the Wiki (casts a ray using the collision extents from the previous position)
Rigidbody Collision Detection set to Continuous (and everything else at some point)
Solutions I'd like to avoid:
Making walls freaking ginormous (I need the collision to be bulletproof for objects in the actual field of play)
Slowing down the ball (lame)
Who's got the juice?
Wait... holy crap, is it bouncing off the other side of the collider???
Im making a game where the player moves VERY fast and the UNITY collision simply cant handle it (which is pretty unforgivable for a collision system).
I had to use the "dont go through walls" idea by raycasting and moving the character back to last position if it went through the mesh. BUT that sometimes meant the object just got stuck forever at "last Position", if the collision warning occurs for a second frame I subtract 10% the objects last distance travelled in a frame.
Yes it's a bit hacky but it does resolve the problem.
Answer by svenskefan · Sep 12, 2012 at 07:55 AM
Hi! I would try making the colliders wider/thicker.
Sorry, I am looking for a general case solution, not a specific fix for the ball going out of bounds. I have to ensure that collision will work with any reasonably sized object, not just walls that can be relatively infinite in size.
But if I was just concerned about going out of bounds, that would be an ideal, practical fix.
the general case solution is that colliders are meant to be wide enough to be wider than one frame of movement.
that's how they are meant to work.
I think, a number of people have already explained that you just use the layers system to make "invisible" so to speak colliders (all colliders are invisible) so they fit in the scene
you should also note that game engine physics does not work, is not supposed to work, cannot work, and does not work with "bullet like" or "laser like" concepts.
if you have something that zips off the screen in a frame, or is "instant" (like any shooting in any FPS you've ever played) you very simply cast a ray to see what you've hit
(bullets and lasers in video games don't actually fly through the air, they just hit where they are going.)
Answer by standardcombo · Aug 13, 2013 at 07:44 AM
I realize this is a late response, but:
Decreasing Time.fixedDeltaTime was a solid idea. Try to increase the polygon density on your walls. I've seen the engine work better with more triangles. Go figure.
Looking for a general solution is honorable, but each game has specific needs. An engine like Unity is already as generalized as you will get. Fix the problem at hand. Whatever works!
That said.. for a breakout game with orthogonal walls you should write your own physics and guarantee the results while getting much better CPU usage. Using Unity physics is like killing a mosquito with a cannon. Furthermore, relying on a physics engine for core gameplay is not good practice unless it is a pure physics game (e.g. Bad Piggies?). Spinning your own physics empowers your design.