Search Unity

OnTriggerEnter Not Fired?

Discussion in '2019.3 Beta' 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:
    4,116
    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:
    35
  5. SSheng

    SSheng

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

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    304
    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.
     
    createtheimaginable likes this.
  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:
    381
    @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:
    304
    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.
     
    Prodigga likes this.
  10. stevesan

    stevesan

    Joined:
    Aug 14, 2011
    Posts:
    65
    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:
    341
    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,718
    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:
    341
    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,947
    ... 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:
    4,116
    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,947
    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,283
    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".
     
    GameDevCouple_I, SugoiDev and 2dchaos like this.
  20. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    170
    So what have we do? Wait for workaround? Rewrite all the code using Physics queries? I don't understand how to duplicate colliders to get the same functionality (withoud actual physics collisions). Also there is no info about this change not in Upgrade guide nor in changelog or recent blog post.
     
  21. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    1,967
    Can we get a dots implementation of some stuff in physics class to get around this?

    Im fine with you making breaking changes ,but if you break something as crucial and fundamental as trigger < > trigger then for the love of god at least make it very widely known.
     
    Last edited: Sep 2, 2019
    SugoiDev and Griz like this.
  22. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    4,283
    @yant, any update on your plans for this?

    As I talked about (at length) in the other thread, the overlap box/sphere etc. replacement is really, really slow. There's also no version of them (afaik) in DOTS, so we can't even break out a dots-based replacement that could theoretically (if you make it correctly) be fast.
     
    SugoiDev, SSheng and Kichang-Kim like this.
  23. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    170
  24. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    1,581
    @yant is currently on vacation. He'll update you once he's back.
     
    Peter77 and Baste like this.
  25. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    304
    I see now how important it is, will be coming with a proposition of a solution in the following weeks. Thanks for your patience and care for the physics.
     
  26. hoesterey

    hoesterey

    Joined:
    Mar 19, 2010
    Posts:
    545
    Is Trigger on Trigger collision getting fixed before release? If not we need to avoid upgrading as it foundational change to our implementation methodologies.

    If it helps with your proposed solution I also think this is a non-starter due to how unity links render and physics layers. It is already very difficult to design collision solutions with the limited number of layers. (Also please please fix that so physics and render layers are separate, its one of the weakest things in the engine). Trigger on Trigger collisions allow us to setup situations where objects on layers that normally collide can overlap and early out in the on trigger enter based on a gameside defined "type". We need this functionality as we can't split objects up enough given the limited and linked physics and render layers.

    Please let us know if this will be fixed before release of 2019.3 so we can avoid the version if it will not be. Thanks!
     
    Last edited: Sep 30, 2019
    konsic likes this.
  27. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,718
    One of my biggest pluses for the new unity physic package is that entities can belong to multiple layers and it's not linked to rendering.

    Obviously this doesn't really help if you're using the classic engine but something to look forward to in the future.
     
    hoesterey, SSheng and brunocoimbra like this.
  28. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    688
    Is it fixed in b5?
     
  29. SynapticBytes

    SynapticBytes

    Joined:
    Sep 26, 2019
    Posts:
    6
    Just downloaded b5 and tried. Unfortunately, it still doesn't work :(
     
  30. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,718
    You might be underestimating the work involved. I wouldn't be surprised if it didn't make it into 2019.3. Maybe they find an elegant solution fast, though I'm doubtful.
     
    Last edited: Oct 2, 2019
    LeonhardP and Lurking-Ninja like this.
  31. Wetw0rx

    Wetw0rx

    Joined:
    Jun 30, 2017
    Posts:
    102
    NOOOOOOOOO!! What a fun killer. Waiting for a good workaround or fix for this or I'll be stuck in 2019.1 forever...
     
    Last edited: Oct 10, 2019
  32. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    304
    Just to let you know - I've tried the Pierre's snippet and that works great, however it requires turning on kinematic-kinematic and kinematic-static pairs if you need kinematic triggers. I might drop something here just to show progress in a few days.
     
    hoesterey, SSheng and SugoiDev like this.
  33. Wolfos

    Wolfos

    Joined:
    Mar 17, 2011
    Posts:
    738
    This is a project-breaking bug. It shouldn't ship this way. Breaking changes like this should be announced well ahead of time.

    Anyway, here's a workaround. Put the colliders on a separate layer that only collides with itself (under Project Settings > Physics). Now uncheck the trigger box on one of the colliders.
     
    Last edited: Oct 8, 2019
    yant likes this.
  34. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,718
    It was announced nearly 8 months ago (feb 25th) well before 2019.3 alpha was even released.

    It's not like you need to upgrade your project to 2019.3 and if you started your project more than 8 months ago it would usually be highly recommended you did not upgrade your project mid development cycle.
     
    Peter77 likes this.
  35. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    304
    Could you guys try out this build and report me everything wrong about triggers you find?https://beta.unity3d.com/download/f490c56742c5/public_download.html

    If it works fine, then this will get shipped - otherwise I'm back to rewriting our trigger system to use pristine contact detection instead (per Pierre's suggestion, but that opens a can of worms tbh).

    This is essentially based on normal PhysX 4.1 where I returned back as much code that supported trigger-trigger as I could find by comparative analysis of 3.4 and 4.1.

    It's based on the latest 2019.3beta for your convenience. Thank you so much for your swift responses and constructive feedback, appreciated.

    yours anthony
     
    Wetw0rx, antwood, Wolfos and 7 others like this.
  36. hoesterey

    hoesterey

    Joined:
    Mar 19, 2010
    Posts:
    545
    At first blush everything seams to work correctly with triggers now. Only tested on PC not Xbox/Switch/PS4 but assuming functionality will carry over. Distributing the editor to the rest of the team and we will let you know if we run into any issues. Really appreciate you looking at this! We didn't want to upgrade but were forced to move off our version of 2018 due to Console min version requirements and figured we might as well go all the way to latest so we can stay ahead of the required upgrade curve for as long as possible ;). Thanks again!
     
    brunocoimbra likes this.
  37. SynapticBytes

    SynapticBytes

    Joined:
    Sep 26, 2019
    Posts:
    6
    My use-case is pretty basic, just a couple cubes (player & enemy) and a capsule (bullet) triggers, in the GameDevHQ Unity course, but it is now working with this test version.
     
  38. creat327

    creat327

    Joined:
    Mar 19, 2009
    Posts:
    1,073
    Wow. Just found this thread. It was driving me nuts for the past few weeks since my collisions were not working.

    In my case I have something as simple as a car (with rigidbody and collider) and a camera that goes into the water. I want to change the fog color when the camera goes inside the water (not when the vehicle goes into the water).

    So, the system was pretty simple. I set a trigger box into the water and another trigger into the camera gameobject. I add a rigidbody to the camera game object and a script that detects on trigger enter and exit. And just changes the fog.

    worked like a charm until now. What suggestion do you give for it to work Now? With this new system that trigger on the camera is never called. Only the ones on the vehicle.
     
  39. SynapticBytes

    SynapticBytes

    Joined:
    Sep 26, 2019
    Posts:
    6
    Did you try the updated version that yant posted?
     
  40. creat327

    creat327

    Joined:
    Mar 19, 2009
    Posts:
    1,073
    no, because i'm looking at a way to make it work properly on physisx4.1 without workarounds
     
  41. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    304
    In case the intent was not clearly communicated - we're trying to work out a path forward in this thread, and the latest build shared above has a fix inside physx that reverts the change that made trigger-vs-trigger overlaps impossible. I will just go ahead and ship if it proves useful.
     
  42. PierreTerdiman

    PierreTerdiman

    Joined:
    May 9, 2017
    Posts:
    15
    I don't quite understand this setup. The "normal" way to do that in PhysX would be a regular rigid body around the camera (with collision response disabled), and one trigger in the water. Camera enters water, you get a trigger notification, done. The trigger around the camera doesn't make sense to me because the camera in itself isn't a sensor - you don't need notifications when other objects touch the camera for example.
     
  43. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    688
    Thank you. When is planned to ship it?
     
  44. Wetw0rx

    Wetw0rx

    Joined:
    Jun 30, 2017
    Posts:
    102
    Thanks! Works perfectly in all my tests so far. I'll post any wierdness I might run into but this is great.