I would love a more detailed explanation about rigidbodys / physics. Thank you for this video. I abandoned my mini golf project because of this problem for a few months ago. Now I can finally go back 🙏🏼❤️
How would you handle this? This probably applies for 3D, but let's imagine you have a Rigidbody2D on your player character. On your player character, you have multiple triggers, that perform multiple tasks. For example, you have a ground detector, a trigger to determine when the player's mouth enters and exits a water body, a ledge detector, an enemy proximity detector. ETC. Now, using OnTriggerEnter2D on the main character's root game object will execute when ANY of them are triggered, since the Rigidbody2D takes possession of all of them, even if they are on child objects. So then, how do you process the overlap event? Well, there are a number of solutions and workarounds, but some of them are not efficient (which is important for scalability), and all of them are not that elegant or come with their own set of issues. A) On every OnTriggerEnter2D and OnTriggerExit2D, you could query all the triggers to determine which one exactly is touching, and then either you could either specify a layermask for each collider, or add layers to the collision matrix that are specific to these colliders. You may also need to manually keep track of whether a trigger is "inside" if getting repeated OnTriggerEnter2D events is an issue. B) You could exclusively put all the triggers on the game objects external to the player. This includes every ledge, every body of water in every level, a wide "proximity" trigger box around every enemy. C) Use Physics2D raycasts or overlap boxes every frame, in place of everything that is a trigger. D) Do not use OnTriggerEnter2D or OnTriggerExit2D on the root game object. Instead, split the triggers up into child game objects, and use OnTriggerEnter2D and OnTriggerExit2D on scripts that are attached to the children objects. This would require creating some communication between the child object scripts and the parent object scripts, which could make it harder to understand what's happening for others on your team. I was using approach C in one of my projects, but was criticised by an industry insider that it's not a scalable solution to use physics casts on every frame. Unfortunately, I didn't get much opportunity to explain the dilemma to them.
Can you not attach small MonoBehaviors to the sub-objects that are your triggers and have them send a message or raise an event that is listened for by your main player to do whatever special stuff on that particular event? I mean to attach a MonoBehaviour to the "mouth trigger" that listens for that trigger event, one to the ledge detector, etc.. Then each MonoBehaviour is only receiving a single event and your main player script can have references to each of these and subscribe to delegate functions on them. Would that solve your problem?
@@LlamAcademyThis would solve the problem. That sounds most similar to solution D. That's a good idea to use events. I've actually now created a generic trigger middleman monobehaviour which can be subscribed too. This creates an experience more similar to Unreal Engine, where an actor can wire up stuff to the "On Begin Overlap" of a specific collision primitive. Thankyou for the response.
I just made the colliders a bit larger than the tiles. It fixed the issue for the most part, but not entirely. I think that's a separate bug that I haven't gotten around to patching though.
I just read the docs and they say "If another collider needs to slide along your compound collider (for example, a character sliding across ice), try to have just one collider along that surface, to reduce jittering during transitions from one collider contact to another."
It can be tricky to find the specific cases that you are encountering. From the Unity talk, it seems like for complex use cases you may need to track a significant number of things to resolve it fully.
This dropped just 45 min ago? I was having the problem today. I thought it was because of code. after some time I found the problem. To fix the issue (for my case) I just used Mesh Collision with covex off. Others might have some other problems with it
It works well for slow moving objects or small values of fixedDeltaTime. Do you use it with 3D or 2D? I remember this being a well known hack in Box2D when I was using it like in 2010. The creators of Box2D had no idea why it worked according to some posts on forums, only that it did work.
@@LlamAcademy I will try to go for this approach just to be safe. And never have I faced such issues before. If you didn't upload the video then I wouldn't have known why it happened.
I heard about this problem and maybe had a few random occurrences, but it didn’t ever show itself with such prevalence as it did in this project. It was a very interesting experience!
That's disappointing. I hoped for a generic robust solution. I'm won't be paying $2000 per year to get havok for my shitty platformer game. :( I need something that will work for objects that move dynamically and can have any rotation, position, and scale. In my game I cranked the offset, physics steps and all physics settings, but still can sometimes get a ghost collision like this.
@@ShadowOrigin28 I was having different issues when using MeshColliders instead. The way the depenetrate is different and can more often produce unstable results like objects shooting off to the distance like Team Rocket, specially when using the reduced offsets. And it also opens up opportunity for objects to get stuck in other objects as only the edge is colliding.
According to the docs here: docs.unity3d.com/Packages/com.havok.physics@1.3/manual/licensing.html You can use Havok if you already have Unity Pro. If you do not, then yes it is an expensive proposition
A video about rigidbodies would be greatly appreciated!
Amazing video! Thanks a Lot!
I would love a more detailed explanation about rigidbodys / physics. Thank you for this video. I abandoned my mini golf project because of this problem for a few months ago. Now I can finally go back 🙏🏼❤️
Always wondered about this but never did the deep dive myself! Good stuff 👍
Thanks, that was quite insightful!
good video! thanks alot
Another solution may be to make a seperate invisible object for collision for the entire ground area
How would you handle this? This probably applies for 3D, but let's imagine you have a Rigidbody2D on your player character. On your player character, you have multiple triggers, that perform multiple tasks. For example, you have a ground detector, a trigger to determine when the player's mouth enters and exits a water body, a ledge detector, an enemy proximity detector. ETC.
Now, using OnTriggerEnter2D on the main character's root game object will execute when ANY of them are triggered, since the Rigidbody2D takes possession of all of them, even if they are on child objects. So then, how do you process the overlap event? Well, there are a number of solutions and workarounds, but some of them are not efficient (which is important for scalability), and all of them are not that elegant or come with their own set of issues.
A) On every OnTriggerEnter2D and OnTriggerExit2D, you could query all the triggers to determine which one exactly is touching, and then either you could either specify a layermask for each collider, or add layers to the collision matrix that are specific to these colliders. You may also need to manually keep track of whether a trigger is "inside" if getting repeated OnTriggerEnter2D events is an issue.
B) You could exclusively put all the triggers on the game objects external to the player. This includes every ledge, every body of water in every level, a wide "proximity" trigger box around every enemy.
C) Use Physics2D raycasts or overlap boxes every frame, in place of everything that is a trigger.
D) Do not use OnTriggerEnter2D or OnTriggerExit2D on the root game object. Instead, split the triggers up into child game objects, and use OnTriggerEnter2D and OnTriggerExit2D on scripts that are attached to the children objects. This would require creating some communication between the child object scripts and the parent object scripts, which could make it harder to understand what's happening for others on your team.
I was using approach C in one of my projects, but was criticised by an industry insider that it's not a scalable solution to use physics casts on every frame. Unfortunately, I didn't get much opportunity to explain the dilemma to them.
Can you not attach small MonoBehaviors to the sub-objects that are your triggers and have them send a message or raise an event that is listened for by your main player to do whatever special stuff on that particular event?
I mean to attach a MonoBehaviour to the "mouth trigger" that listens for that trigger event, one to the ledge detector, etc..
Then each MonoBehaviour is only receiving a single event and your main player script can have references to each of these and subscribe to delegate functions on them. Would that solve your problem?
@@LlamAcademyThis would solve the problem. That sounds most similar to solution D. That's a good idea to use events.
I've actually now created a generic trigger middleman monobehaviour which can be subscribed too.
This creates an experience more similar to Unreal Engine, where an actor can wire up stuff to the "On Begin Overlap" of a specific collision primitive.
Thankyou for the response.
I just made the colliders a bit larger than the tiles. It fixed the issue for the most part, but not entirely. I think that's a separate bug that I haven't gotten around to patching though.
In my experience this just migrated the ghost collision off the seam to wherever the collider ends up being 😟
Does it happen with Entities Physics?
couldn't we use compound colliders for this?
I just read the docs and they say "If another collider needs to slide along your compound collider (for example, a character sliding across ice), try to have just one collider along that surface, to reduce jittering during transitions from one collider contact to another."
Sadly does not solve the problem ☹️
I already spent 10+ hours trying to modify the contact pairs but I feel like I would need 100+ hours to make it work reliably in different scenarios.
It can be tricky to find the specific cases that you are encountering. From the Unity talk, it seems like for complex use cases you may need to track a significant number of things to resolve it fully.
What would happen with this code if you hit a wall?
It’s not discarded and bounces correctly. I know in the video I didn’t show that, but in the game on itch you can see it in action
maybe bake new colision mesh after level ready.
That was part of this solution, but as you see at the seams we still have problems. If you only need 1 physics material, that can work
@@LlamAcademy well then you can make trigger zones that changes material. anyway this is nasty problem. i have it in my game but in other way.
That’s an interesting approach I hadn’t considered. Thanks for the idea🙂
This dropped just 45 min ago? I was having the problem today. I thought it was because of code. after some time I found the problem. To fix the issue (for my case) I just used Mesh Collision with covex off. Others might have some other problems with it
It works well for slow moving objects or small values of fixedDeltaTime.
Do you use it with 3D or 2D?
I remember this being a well known hack in Box2D when I was using it like in 2010. The creators of Box2D had no idea why it worked according to some posts on forums, only that it did work.
In some specific cases that may also help. For the types of cases shown here unfortunately it does not resolve the issue 😕
@@LlamAcademy I will try to go for this approach just to be safe.
And never have I faced such issues before. If you didn't upload the video then I wouldn't have known why it happened.
I heard about this problem and maybe had a few random occurrences, but it didn’t ever show itself with such prevalence as it did in this project. It was a very interesting experience!
That's disappointing. I hoped for a generic robust solution. I'm won't be paying $2000 per year to get havok for my shitty platformer game. :( I need something that will work for objects that move dynamically and can have any rotation, position, and scale. In my game I cranked the offset, physics steps and all physics settings, but still can sometimes get a ghost collision like this.
how about trying mesh collider with covex off?
@@ShadowOrigin28 I was having different issues when using MeshColliders instead. The way the depenetrate is different and can more often produce unstable results like objects shooting off to the distance like Team Rocket, specially when using the reduced offsets. And it also opens up opportunity for objects to get stuck in other objects as only the edge is colliding.
i have this colision problem in my game. i just got into blender created 3 d model without sharp corners and use it instead collider
According to the docs here: docs.unity3d.com/Packages/com.havok.physics@1.3/manual/licensing.html
You can use Havok if you already have Unity Pro. If you do not, then yes it is an expensive proposition