In the game I’m building I have a ground mesh object that the player character can run around on. I am instantiating player pickup meshes via code. These pickups are of a prefab that has a rigidbody and box collider. When run these pickups appear and fall onto the ground. Works fine.
But as soon as I click “Is Trigger” on the collider, the pickup meshes fall straight through the ground. Is this normal? I want to add a collider script that makes the pickups destroy etc. when the player runs into them.
I need to keep the rigidbody, so the objects tumble to the floor. Manually placing the objects isn’t an option.
I’ve tried different types of colliders including convex mesh colliders all to no avail
I even tried adding a rigidbody to the gems in Will Goldstone tutorial scene and got the same behaviour.
Triggers don’t have physical interactions with anything, which is why they are triggers. You could have the objects start out as non-triggers, and then change them over to triggers when they are positioned on the ground, or you could place them using raycasting instead of letting them fall.
So an object can’t have physics behaviour and a trigger attached to it?
Sounds like a big limitation
I wonder how I can detect when the object has hit the ground and stopped…
The ground is not a flat plane or at a certain height.
I suppose a poor workaround would be to do something like creating an array of possible positions and randomly choosing one each time but it looks great the pickups falling from the sky, and I would like the positions to be as varied as possible.
Maybe as you intimate, a script on each rigid-body object that checks if the object is stationary, and if it is, it removes the rigidbody and adds the collider…
Not at all; that’s the entire point of triggers, and you don’t want triggers to generate collision events. Otherwise they’d be kind of useless…you use them is to set up areas where you want something to happen, without physically affecting other objects. e.g., using a trigger as the finish line of a racetrack to detect when the lap is over–you don’t want your car bouncing off it!
function Start () {
collider.isTrigger = false;
while (!rigidbody.isSleeping()) {
yield;
}
collider.isTrigger = true;
}
Or, like I mentioned, use raycasting to position them, which is pretty simple if you check out the examples in Physics.Raycast.
In the Hierarchy panel, drag the new, empty GameObject onto the GameObject you want to add a trigger to, making it a ‘child’ of the original GameObject.
This is a “parent-child” relationship in computing jargon, so named because programmers like to be very explicit about the specific nature of their data structures. (Another popular metaphor is the ‘tree’ structure, with individual GameObjects referred to as ‘roots’ and ‘branches’. It’s not perfect as the resulting tree tends to be upside-down, but I suppose using “Container” simply wasn’t geeky enough.)
Basically, it means the new GameObject will follow the ‘parent’ GameObject around the Scene. If the parent moves, its child moves with it; rather like an owner taking his pet dog out for a walk.
Give this new empty GameObject a Collider Component – Box, Sphere, Capsule; whichever best fits the model – and set it as a Trigger. Twiddle the position, scale factor, rotation, etc. to make sure the Box Collider is centred over the parent object and is slightly bigger than the actual 3D model. Et voilà! You have an game object with both a proper collider and a trigger collider. Two for the price of, er, two!
(Note, the trigger usually needs to be slightly bigger than the model, otherwise the player might not hit it under every circumstance. This is less of an issue if the actual model is indeed a cube. The trigger collider is ignored by the physics stuff, so it can be as big as you like.)
