Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

OnTriggerEnter Not Fired?

Discussion in '2019.3 Alpha' started by SSheng, Jul 30, 2019.

  1. SSheng

    SSheng

    Joined:
    Apr 13, 2018
    Posts:
    6
    When update unity version, our project seems having this issue. Two triggers can't fire an ontrigger event when colliding. I'm pretty sure every settings are correct. Both of them have their rigidbody and it just works fine in old version.
    When I try make one of the trigger to collider, the event fired. Just two triggers won't call the OntriggerEnter. 1.png 2.png
     
  2. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    3,892
    Seems like you found a regression. Please submit a bug-report as described in this document:
    https://unity3d.com/unity/qa/bug-reporting

    It's important that you report these issues together with a reproduction project if you want them to get fixed. If you don't do it, it might be a long time until someone else reports them or until Unity Technologies find them.

    After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. Please post the Case number (number only, not the link) in this forum thread for Unity staff to pick up.
     
  3. ahmet_unity826

    ahmet_unity826

    Joined:
    Dec 28, 2018
    Posts:
    2
    Can confirm, in 2019.03.0a10 when two triggers collide OnTriggerEnter is not fired.
     
  4. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    21
  5. SSheng

    SSheng

    Joined:
    Apr 13, 2018
    Posts:
    6
    brunocoimbra likes this.
  6. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    This is probably the most visible regression in PhysX 4.1 that we knew about for a while. It's by design, as the team wanted to clean up some trigger code that was otherwise imperfect. I guess it is great now J. Nvidia recommends to duplicate trigger colliders. I'm closely watching this space, and if it turns to be a seriously painful topic, we can still roll out an optional workaround that would return the old behaviour back, at some extra cost.
     
  7. SSheng

    SSheng

    Joined:
    Apr 13, 2018
    Posts:
    6
    Thx for replying Yant.
    We made a workaround that create a child object with a collider in another layer for every trigger that need to do trigger-trigger event. Those colliders' layer only collide with triggers' layer and every time they overlapped, there will be 4 trigger enter events. trigger1->collider2, collider1->trigger2, trigger2->collider1, collider2->trigger1, and by having rigidbody we can ignore the collider event and have the same result.
    Since we are making a magic spell kind of game. A LOT of spells are made by triggers and they need to interact with each other. We took some time to convert our triggers. Don't know if we are in right track, can you give us some advice?
     
  8. greg-harding

    greg-harding

    Joined:
    Apr 11, 2013
    Posts:
    375
    @yant We're not using the 2019.3 alpha yet but I saw the trigger-trigger change mentioned a few times in other forum posts and in the feature list updates in this forum. We use trigger-trigger collisions all the time - they can be a real workhorse. If you don't roll out a low-level workaround, if you're not planning it already, I'd suggest updating the docs to show some common scenarios and how to achieve them in PhysX 4.1.
     
  9. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    I hear you, and encourage others to speak their mind here too. More perspectives help. Thank you so much for your continued interest in physics. Anthony.
     
  10. stevesan

    stevesan

    Joined:
    Aug 14, 2011
    Posts:
    64
    Could you explain the recommended work-around, and any possible perf costs? It's not clear to me what this means: "Nvidia recommends to duplicate trigger colliders." If trigger-trigger does not work, how would just adding more triggers help? And @SSheng's solution seems quite complicated.

    We actually rely on trigger-trigger as a "work-around" for detecting kinematic-kinematic collisions (I could be mis-speaking - not at work right now).

    Thanks!
     
  11. any_user

    any_user

    Joined:
    Oct 19, 2008
    Posts:
    339
    We use trigger/trigger interactions regularly. If there‘s an easy workaround I could live with that change, but currently it sounds like a useful feature is not available anymore without a real reason.
     
  12. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,542
    Well the reason is nvidia got rid of it, wasn't unitys decision.

    Anyway from the physx migration guidelines.

     
    xVergilx likes this.
  13. any_user

    any_user

    Joined:
    Oct 19, 2008
    Posts:
    339
    I’m aware of that. What I mean: It would be nice if Unity could implement the workaround behind the scenes, so we can keep using this workflow without additional work.
     
  14. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    1,875
    ... which is a workaround to the workaround.

    I'm against it, as long as it has any impact on the physics performance. Even 0.01%. No. Just no.

    @UT
    Stick to the latest PhysX version and features please.

    Never used this feature, and never suggested anyone trigger-trigger interactions.
     
  15. SSheng

    SSheng

    Joined:
    Apr 13, 2018
    Posts:
    6
    Just for learning, can you explain a little bit more about why we shouldn't use trigger-trigger interaction? In our project, since the unity layer count is limited, we have to use trigger to do some gameplay logic to make things not affect players movement? Do you have any advice for this?
     
  16. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    3,892
    Can't this be replicated rather easily through user code? I imagine I would only need a script that calls one of the Check/Overlap/Cast Physics methods to test if it hit a trigger?
     
    xVergilx likes this.
  17. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    1,875
    Physics queries. Most any flavor of those, OverlapSphere to replace sphere collider, OverlapBox to replace box one.
    Just use non-alloc versions of them.

    Way more precise, and way more flexible. 0 layers used if checked against components.
    Not restricted to the collision matrix.
     
  18. SSheng

    SSheng

    Joined:
    Apr 13, 2018
    Posts:
    6
    It sounds good but when you actually do it, things are different. If you remove triggers and use overlap function, you will not get those gameobjects you want since those triggers are removed. If you don't remove them, think about you have a complex gameobject that have a lot of triggers and several rigidbodies to handle different situations, overlap function will overlap all those triggers ignoring rigidbody. Also mostly we only want ontriggerEnter or OnTriggerExit event, but if you use overlap, you have to keep track of all triggered objects in every trigger. All these works are not hard but very annoying, and I feel like just having one checkbox in collider component that saying like enable trigger-trigger or something would be better.
     
  19. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    4,096
    We've used them extensively in every game we have shipped. It's core to our workflow, and since it's so obvious that it should work, what scripts use the feature isn't obvious, so working around it would be a bug-filled mess.
    On the other hand, what's never been a problem in any of the games we have shipped - except when porting to the Vita - is physics performance. I don't give a single toss about any performance improvement that could be added to the physics engine since physics performance is a non-issue for us. We don't use the physics engine for any simulation of physics, just for raycasts and trigger checks.


    So, in our book, this is a major, major regression in functionality. Ideally the PhysX ugrade would get rolled back until a workaround is introduced natively. If it ships, it needs to ship with big, fat, red flags in the docs saying "hey, a core feature was removed upstream, and there's no direct workaround".