OnTriggerStay alternatives?

[jess84]

So my game uses 16 gameobjects on a grid of 25. The positions of he gameobjects can change over time.

I'm currently sending an event to neighbouring gameobjects when an in-game action happens. This event on all other gameobjects triggers a check using OnTriggerStay (OnTriggerEnter isn't useful, as the object will already be within the colliders), it checks this, and 0.2 seconds later goes back to an empty state - so that it's not checking every frame.

I thought that if I'm only running this check for 0.2 seconds, it wouldn't be expensive.

However, have a look at the profiler info in the screenshot - it's a real performance drain.

Should this be this bad?

[dasbin]

Correct me if I'm wrong, but I think you've gone about this the wrong way - my understanding is that waiting for an OnTrigger event isn't actively "checking every frame," as you say (as the script itself isn't doing anything at all), but rather waiting for the physics engine to call the method on the script instead. The method is being "pushed" by the engine when needed and otherwise it's not called.
So you're probably doing yourself a disservice by re-entering that state over and over so quickly - PlayMaker stores its own "last collision" data set, so it might have something to do with it re-initializing access to that every time you enter the state.

In any case, all I can say is I have a whole bunch of objects (dozens) in my game constantly waiting for an OnCollisionStay event and the performance impact from all of them is sub-millisecond.

[jess84]

I'm not re - entering that state over and over...  As I said, I check it when an event is deliberately sent from another object, if there's a match it sends an outgoing event, if there's no match, it returns to an empty state.

I added that check as without it my game was running at about 5 frames a second beforehand.

You say you're using lots of OnCollision actions, is that any different performance wise  to onTrigger?

As you can see from the profile screenshot I posted,   the bulk of the calls are onTrigger related, I'm not making that up!

[jess84]

Well I switched to using OnTriggerEnter and Exit and bools for capturing the status, and it has dramatically improved things.

See the screenshot for new performance.

[jeanfabre]

Hi,

 Always prefer using this technic over TriggerStay or COllisionStay. That's part of the reason why I am not sure how to tackle the Unity 2d demo as it only use that kind of TriggerStay checks over and over, and it's not a good practice within PlayMaker.

bye,

 Jean

[jess84]

Argh... it's been several hours of trying to figure this out, and I'm going insane!

Problem:  Using the TriggerEnter/TriggerExit and bools method works fine except when the 2 objects are spawned on level start next to each other - they don't go through the OnTriggerEnter state because they are already there to begin with.

I've tried setting the scale of my child objects containing the trigger zones to 0 initially, and then as my mission starts, scaling them back to 1, but that doesn't work either - these 2 objects don't recognise that they're in each other's trigger zones.

Funnily enough, as I'm using iTween shake on my objects, if one of these 2 shakes, then suddenly one will go through the TriggerEnter state and will acknowledge the other. (though just one of them, they don't both then recognise each other)

I really don't know what to try next.

The annoying thing is that OnTriggerStay worked perfectly for me - I never had a single problem, but it was just way too expensive.   

[jeanfabre]

Hi,

 yep, the usual dilema.

-- make it so that they don't overlap
 
Or

-- assume they are if you know when this happens.


have you tried to have one fsm doing this, and disable it once it ran? so the OnCollisionStay would work only once because the fsm is disabled straigh away. Never tested that option, double with the profiler if performances are still bad even when it's disabled.

bye,

 Jean

[jess84]

In the end I decided on spawning the cubes initially at position where they don't touch anything else (so on Y 1,2,3,4 etc.), then move then into place when the player clicks to start. It works well.

I was wondering though. I have my 16 cubes in the scene by default (they are prefabs, but only for managing changes), is there any performance difference between doing this compared to using create object state after the level has loaded, and spawning them this way?

[jeanfabre]

Hi,

 for 16 objects, not really, go for what's easier for you to develop and maintain.

bye,

 Jean