标题: unity3d中Trigger的使用探讨（一） [打印本页] 作者: 会飞的鱼 时间: 2011-12-14 14:40 标题: unity3d中Trigger的使用探讨（一） 原文标题为：Getting Tricky with Triggers，很有用的知识点研究。 Unity triggers are insanely useful. If you aren’t using physics triggers–even if your game is seemingly non-physical–you’re missing out on some of the most powerful functionality in Unity. Let’s take a look:
What’s a Trigger?
A trigger is a Collider that fires events as other Colliders enter and leave its collision volume, but without physically interacting with your scene. They are physically “invisible”. If a Rigidbody “hits” a trigger, it passes right through, but the trigger produces OnTriggerEnter calls, when the object enters, OnTriggerStay calls, for as long as the object is inside the trigger, and OnTriggerExit calls, for when the object leaves the trigger.
Take a look at the Unity collider documentation for a more verbose explanation, as well as the collision chart for when collision events are called.
Where to Use Triggers?
We use triggers as:
Static Proximity Triggers
The most obvious trigger example is to use them as, well, actual proximity triggers. Some piece of game logic is***n when the player, or another object, reaches a point in space. You could place a trigger in front of a door which causes the door to open as the player approaches. You can easily test the entered Collider for some layer, tag, or Component to see if the trigger should***cute. This is as sample as:
function OnTriggerEnter(other:Collider)
{
// only process if we’re the player
if(!other.CompareTag(“Player”))
return;
// does the player have the blue key? if not, boo
if(!Player.HasKey(“blue”))
return;
// actually open the door!
}
Radius Triggers
The first trick with triggers is to realize they can move. You can set a trigger as a child of an object–even another physical object like a Rigidbody–and then use the trigger to take action as other objects approach or exit a radius around your object of interest.
Take the use case of spawn points, for instance; your goal is to trigger an enemy spawn as a spawn point nears your player. You could place a script on your player that iterates all possible spawn points and spawns something if it’s near enough:
function FixedUpdate()
The #1 reason for using triggers, over this “manual” method, is that triggers will be faster. Much faster! There are ways to make this example better–check the sqrMagnitude of the distance to avoid a square root, cache your Transform, etc–but the ***x of the problem remains: You have to***n this code every Update, FixedUpdate, or at least with enough frequency to respond interactively.
However, the physics engine is already checking for trigger collisions. It’s doing the work for you! Let it do its super-fast optimized thing; believe me, you can’t compete with PhysX on an optimization level. Instead of polling for spawn points in our radius ourselves, let the physics engine send events only when something enters our player radius trigger. This becomes:
function OnTriggerEnter(other:Collider)
{
var spawn:SpawnPoint = other.GetComponent(SpawnPoint);
if(spawn)
spawn.DoSpawn();
}
Create a gigantic trigger as a child of your player object, place this script on it, and voila! To prevent collision with your physical gameplay objects, your spawn colliders should also be triggers (yes, triggers send OnTrigger* messages when other triggers enter and exit).
Warning: Trigger colliders do respond to raycasts. You should make sure your triggers are set to the Ignore Raycasts layer if your game logic uses raycasts (or are otherwise ignored by your raycast LayerMasks).