Extending Colliders?

Unity Engine
,
1

I’m trying to push the envelope when it comes to performance on the iPhone - and avoiding as many GetComponent calls as I can especially if it’s called every frame.

For example I usually have some code like this somewhere :

function OnTriggerStay(other:Collider){
   var item : Item = other.GetComponent(Item);
  switch(item.itemType){
     case ItemType.Horse : 
                item.horse.EatShit();
                break;                          
 }
}

If I could extend a BoxCollider (or other colliders) and attach it I could cache the Item to a variable inside the collider and avoid the GetComponent call :

function OnTriggerStay(other:Collider){
   var item : Item = (other as ItemBoxCollider).item;  // if  I am only using ItemBoxColliders
  switch(item.itemType){
     case ItemType.Horse : 
                item.horse.EatShit();
                item.myTransform.Translate(......);
                break;                          
 }
}

but I can’t since I get this message if I extend the BoxCollider and try to add it to a gameObject :

Can't add script behaviour ItemBoxCollider. The script needs to derive from MonoBehaviour!

But I can add a BoxCollider and other stuff that derives from Component with no problem… anyway around this? any other ideas how to avoid calling GetComponent inside a “OnTrigger” function ?

2

if collider.other is the same as the previous collider.other, than the Item component should be the same.

that said, i wish there were a way to have the colliders register a delegate so you wouldnt have to use the message system :wink:

3

That’s true if you expect the same collider or object every frame , but I want to use that on multiple objects in the trigger area and apply the function on all of them , OnTriggerStay, is called once per frame per collider so it’s now a matter of saving some list with colliders and their corresponding Item - and doing the lookup on that table, which might become as heavy as using GetComponent…

4

FWIW, I doubt a hashtable lookup is as expensive as GetComponent… something to benchmark for sure… but then you have to weigh in the creation costs of the hashtable &c.

5

my guess is that GetComponent propably just iterates through the components of the gameObject and if the Component is of the type I’m looking for - it returns it. which means going through 4-8 components on some component list .
If I hold a hashtable and keep updating it with new items that I instantiate and remove old items which are no longer in the scene and do the lookup inside all objects it the scene - it’ll probably be slower… but than again I don’t really know what GetComponent does behind the scenes so I might be wrong.

What I do right now , which work faster as far as I can tell (less frame drops) , is iterate through all “Items” in the scene - I hold and maintain an “Items” array - and do a Collider.bounds.Intersects(otherCollider.bounds) check instead of using the trigger system. that way I avoid the GetComponent calls.
I don’t know how the trigger system works backstage and if the intersection checks between the colliders are happening anyway (if that’s the case I can use the renderer bounds for the check) - but because it is more low level than what I do and written by better programmers it should probably work faster. And another problem with my method is that Bounds.Intersect() only works with axis aligned Bounding Boxes (AABB).
so basically I’m kind of confused as to what is the best way to do this, I guess I should try a couple of methods and just check how much time each of them takes .