I need to be able to make my colliders thicker so that they will actually trigger a “hit” when I shoot something at them. how do i go about doing this?
What do you mean by “trigger a “hit””?, are your objects moving too fast that the actual triggers cannot detect them?
We think that’s what the problem is, so I was wondering if there might be a way to have a wider/thicker collider that can trigger it. Any ideas?
Hello, I kinda understand you now 
Indeed there are some scripts on the Unity Wiki that can do what you are looking for 
checkout:
→ http://www.unifycommunity.com/wiki/index.php?title=CollisionIgnoreManager
→ http://www.unifycommunity.com/wiki/index.php?title=ComplicatedRigidbodyControl
And finally this is (i Think) the one that you are maybe looking for
→ http://www.unifycommunity.com/wiki/index.php?title=DontGoThroughThings
Hope it helps 
That works great, but obviously is only practical to use with border geometry on your level.
Just pick a wall, delete it’s current collider and add a new box collider to fit. Make sure it’s thick enough in depth that whatever object you’re shooting at it won’t be able to pass by it in a single frame.
naruse : Yes I think this will be quite helpful, thanks a bunch for this.
Quietus: Not really sure I’m following you. I was hoping for a way to make the trigger area bigger. I was under the impression that a collider only registered a “hit” when something was found to be colliding with the outermost edge. Is this not true? If not then I think larger/thicker colliders is not my answer. Thanks for the post
As far as I know, a hit is registered when it collides with any portion of the object, including the internal areas. To test this, just make two rigidbodies with useGravity on and a box collider and put them inside each other.
Making the box collider thicker easily makes things collide with it more consistently.
Hm, I see. Well i suppose making my colliders bigger should trigger the response I’m trying to get but I don’t think it’s very practical from a game play point of view. I’m thinking we might have to go more along the lines of a scripted approach.
Thanks everyone for the answers!
That is not true. For something to register a collision there has to be first a bounding box intersection when tested in an individual frame. If that happens then it will register a collision, and do more detailed collision checks if it’s not a trigger.
What happens is that an object will be translated a certain distance in a frame if under control of physics. Now if your collider is very thin and your object has a large velocity it might move totally past the collider in a single frame.
If that occurs then there will obviously be no collision detected. It’s as if you just manually set your position to a place beyond the collider where there’s no bounding box intersection.
Increasing the thickness of your collider to something greater than the distance an object can travel in one frame works wonders and solves the problem. However while it is a great solution for border geometry, you can’t quite do the same thing for a lamp sitting on a table. You need to raycast ahead for fast moving objects in those situations.
All game engines handle collision the same way. It’s fairly standard. So they all suffer from fast moving objects as well. That’s why in a lot of games, for things like bullets, there’s a raycast involved when firing but not an actual object spawned.
OK I think I understand,
So there does have to be a collision at the edge for it to register a collision/hit but if perhaps a bullet is found to be inside of an object (like in GargerathSunman’s example), the physics engine will send it out, which will then cause a collision detection as it exits?
Also, just to clarify, does a thicker collider in this case just mean bigger (covering more area)? or is there actually a way to make the collision detection plane thicker?
Not quite. OnCollisionEnter/OnTriggerEnter() are called on the first frame when something is anywhere within the collider. Check out the attached project for an example. When the button is clicked, the smaller cube makes an immediate jump inside the larger one, which causes the script attached to the larger cube to fire a debug message.
192714–6836–$collisions_339.zip (1.07 MB)
ok… so as long as my bullet/object spends at least one frame inside or colliding with the object it should register right? and the only way to get around it being missed, is to either use raycasting or larger colliders which would ultimately make the gameplay a little strange.
Correct.
There’s a third way, and that would be increasing the rate at which the physics engine runs. That would of course, result in a higher cpu load.
There is also nothing ‘strange’ about the gameplay, if as I said, you limit your thicker (not necessarily bigger) colliders to bounding geometry of your level. If something bounces off a wall as it is supposed to, I don’t quite see what’s so strange about that.
You’re right, I’d forgotten about this. I played with the settings a little and did see a bit of an improvement.
I think what I don’t understand is how you would make a collider thicker without making it bigger. Originally that’s the question I was looking for an answer to. Also I don’t quite understand why bounding geometry could implement this but not other objects. I think I’m missing something 
There’s not really a “thickness” to a collider at all, in the sense that it doesn’t have a “skin.” The thickness of a collider is just its size. Thus, if you make a collider much larger than the object it’s attached to, you’ll run into problems where things will collide with the object long before they’re physically near it. So you can increase the size of a collider to prevent fast-moving objects from appearing to pass through other objects, but you’ll create a whole new set of strange-looking behaviors.
What Quietus is suggesting is that this problem isn’t a problem at all for level boundaries. They can be as deep as needed to prevent the physics engine not catching a collision, since they don’t correspond to an actual object in the world. A rock (or something), however, doesn’t have this advantage because its collider needs to at least approximate the shape and size of the rock it’s representing.
Ok That’s what I though. I guess I was just thinking that even if the bounding geometry had extra deep colliders, if the outer edge lined up with the edge of a lets say building, the bullet would still appear to go through it. It would eventually detect the collision but not before you saw the bullet going into the object.
It wouldn’t actually detect the collision at all in the case you describe. Unity (and any system, for that matter), can only move objects with a certain degree of granularity. The engine is moving any moving object a certain amount for each time step based on the object’s speed. If that speed is fast enough, Unity has to move it further each time step than something moving slower, since it is forced to operate in discrete steps. With two objects small enough or moving fast enough, it’s possible that one of those steps puts the moving object entirely on the other side of the stationary object, without recognizing any collision whatsoever.
The physics engine would move the object to where it entered the collider before calculating reflection forces in the same frame the collision is detected. As this happens before the object is rendered you would see the bullet bounce off the wall, not penetrate.
To decide how thick your collider needs to be behind your wall, simply calculate how far your projectile can move in one frame.
Now if your projectiles are moving at the speed of say a rifle bullet, you’re not going to see them in any event and you’re better off just using a raycast and not spawning a rigidbody in the first place.
ok I think I see what I was missing before, and nothing should be moving at the speed of rifle bullets so we’re ok there.
Unfortunately most of the objects I’ll be hitting aren’t bounding geometry, so I’m guessing ray casting is our best bet. Is there a light way of approaching them? I’ve heard that ray casting can be a little heavy.
Well I’d suggest trying it out. That would give you a far better feel than just going on what you heard. If you find it’s a performance hog in your situation, spawning a slew of projectiles for example, raycasting every other frame would cut it’s impact in half.