koobas.hobune.stream
How do I solve the Box Collider (3D) Edge / Corner Collisions problem?
I posted a similar question in the unity forums 10 days ago and haven't had any responses at this point.
In short my level is made up of box colliders (3D). My player (and other objects) are using non-rotating Box Colliders (3D). I'm not sure how to solve my issue with Unity Physics when the player or other objects hit the 'edge' of a Box Collider, even though it is next to another box collider and needs to act as if it's 1 object.
I am already combining as many Box Colliders together as possible into 1, but there are instances I cannot avoid where this will still occur.
I'd prefer to use Unity to detect collisions as from what I've read PhysX is extremely optimized. Is it possible or will I have to check for collisions using Ray Casts every FixedUpdate() on my moving GameObjects and reflect their velocities appropriately, thus not benefitting from PhysX?
Are there other options / solutions I can look at?
I've never faced this particular dilemma, but I know a teeny bit about the physics system's many quirks. Unfortunately, the issue(s) you seem to be describing are inherent nuances of the physics sim. Someone correct me if I'm wrong. Just as floating point precision is finite, so too is the simulation accuracy.
I'm confused by your stated requirements, such as the non-rotating box collider for the player. Using a non-rotating sphere collider of the same diameter might (probably would!) mitigate these issues a great deal. Also, proper masses, forces, frictions, and bounce factors go a long way to polishing the sim.
It's perfectly fine, by the way, to blend your behaviors among raycasting, triggers, and actual collision reactions. Any quality, robust simulation has some extra sensors and actuators working unbeknownst to the player! As long as your physics equations are sound and your various sensors and actuators are sufficiently competent, it can all work really well.
Thanks for the response.
I'm using a non-rotating Box Collider ins$$anonymous$$d of a sphere because I need to emulate the same collisions as the old game client I'm recreating, and it used box colliders. For testing purposes I did try with a Sphere and do encounter the edge bounce back issue even with a sphere unfortunately. :/
As far as the extra ray-casts, I'm assu$$anonymous$$g the best place for these is in FixedUpdate(), even though it means a $$anonymous$$imum of 6 rays per FixedUpdate to check for collisions?
Well, my suggestion wasn't to replace collisions with raycasts; rather to use raycasts as sensors to drive an avoidance behavior or force adjustment. (If wall is N units to left, reduce applied force in -X direction). This may or may not produce results you desire. Physics-driven games are super finicky and require a lot of tinkering to nail down.
Yes, having 6 raycasts per-actor per-frame represents a slight performance drain, but only if you have a ton of actors, and/or are targeting mobile. But as the saying goes, first make it work, then make it work well.
Note that many factors can impact physics performance, and knowing which quirk is responsible for your troubles is a matter of testing and familiarity with the physics sim. Friction and bounce are very important for "sliding" behavior, for instance.
Ultimately, you may need to go so far as to generate a mesh collider which encompasses each of your "islands" or obstacles. Been there, done that. $$anonymous$$ajor headache, but it can be done and made performant.
I recall a situation where my actors were spheres and my obstacles were cubes, and I could get "perfect" sliding behavior along these walls-of-cubes. I don't recall there being a specific problem to overcome (as you describe) - just a lot of tinkering and dialing in the right combination of factors.
The next thing that comes to $$anonymous$$d is, perhaps the simulation is reacting this way because your cuboid actor cannot turn. When it hits these problem areas, perhaps an imperceptible change in rotation would occur, but since it can't, a perceptible hiccup in position occurs ins$$anonymous$$d.
$$anonymous$$y best advice involves changing the properties of your physical objects. You could also try reducing the physics timestep and "skin depth" or whatever Unity calls it for increased accuracy, or changing the scale of the whole project (bigger if it's small, smaller if it's big) such that your physics objects are of a size the physics sim is designed to handle well.
For perspective, in a FPS, a human should be around 2 units high. In a space game, an average ship should probably be around 2 units long, to retain the "accuracy by volume" the simulation was designed around.
Someone correct me if I'm wrong about any of this.
"$$anonymous$$in Penetration For Penalty" is the "skin depth" thing I mentioned. If your cube objects are so close that they're visibly touching, the skins of two adjacent colliders may overlap. Colliding with this overlap may cause this issue. That might be the source of your problem right there. Try fiddling with this value (in project's physics settings). Or, try setting your colliders to be slightly smaller than 1x1x1.
Thanks for the suggestions. I had already messed with the physics time step and the $$anonymous$$ penetration option. I'll try slightly adjusting that one a bit to see what I can get.
Otherwise I was just trying to figure out if it's better for me to change my wall collisions into just triggers and then deter$$anonymous$$ing how to adjust the colliding objects myself (thus getting an exact match on the existing game physics I'm trying to emulate). Or if I do the raycasting to catch only the specific corner hit issue. Using triggers may be better as I don't need as many raycasts each frame, just when I get a trigger collision, but I haven't figured that out yet. Still doing research to find out the best way. :)
Note I'm accepting your answer as it's been the best help so far!
Edit->Project Settings->Physics Inspector will show PhysicsManager Set 'Default Contact Offset' from 0.01 to 0.001 (I use 0.0001)
This WILL fix it as I use a ton of cubes in a 3D cubic tile based world.
Thanks a lot! This solved the problem I had with my tile based, ball rolling game :D
Hey,
I know this problem well and I'm working on a 2D game, currently. While I'm not using 3D collisions, my solution may help point you in the right direction. I ended up having to use the 'Edge Collider 2D' on my player, rather than the box collider. With each side covered by its own edge collider I've found that I don't get the... sticking to the corner of a block on the floor or walls. It also lets your character's feet have a different physics material to your character's sides.
Good luck
Thanks Venhip. I had read about that option, but unfortunately cannot apply it to my situation due to not doing just a 2D game. Thanks anyhow!
I had a similar problem, for anyone who still needs help, my solution was to use box renderers with children quad colliders along the surfaces you want to collide with. even though the edges are flush and shouldn't collide, they do. By excluding these surfaces, the object will never wrongly catch on them.
For everyone who still has this problem (I was searching for a solution for ~1hr):
what @AlwaysSunny stated is a great way to deal with this (in most cases). Try to have a gap of e.g. 0,01 between your (box-)colliders, so they don't directly touch each other - your character will not glitch through the edges anymore.
Also, keep in mind that the speed of your character has an influence on the clipping.
