Problem: sprite overlaping just for an instant when colliding.

UPDATE:
{
I finally solved the problem. Thank you all for helping me.
I still have no idea why it was doing the stuff I mentioned at the beginning, which was the reason why I opened this thread. But now everything works fine. Please, see the solution at the end of this first post or at the end of the thread (the big paragraph I wrote).

Go to full explanation of what the heck I did and why and to see the final result, with the character doing its job properly.
}

Hello. I am doing the Ruby’s Adventure tutorial.
I found a graphic problem and I have no idea about how to fix it. The problem is: when I move the character against an object (a box), character’s sprite overlaps box’s sprite just for a moment after colliding. Like in the next gif I made:

7551655--933604--pgif1.gif

If the character is next to the object (with no space between remaining), and you try to move it, this doesn’t happen. So, the character has to move some space before colliding to make this happen.
If the character moves but doesn’t collide with the object, it doesn’t overlap box’s sprite either (see the gif below). But when it collides, even moving slowly, the graphic error happens again.

7551655--933652--pgif2.gif

The only exception is when you move a little each time, pressing fast and quick the key to move (like trying to move pixel by pixel). This way you finally collide with the box, but there’s no overlaping. This makes me think that maybe speed has something to do with the issue.

(EDIT: I want the character to hide a little bit behind the box, the problem is not that it gets behind the box)

Details:
These are the collider boxes for both objects:

7551655--933622--characterSprite.png 7551655--933625--box sprite.png

These are the settings I am using for the Graphics (following the tutorial), so Unity calculates which sprite should appear on top:
7551655--933628--graphic settings.png

Transparency Sort Mode: Custom Axis
Transparency Sort Axis: x=0 y=1 z=0

Also, character prefab has “Sprite sort point” setted as “Pivot”.
Box’s sprite has “pivot” at “bottom”. Character’s sprite has “pivot” as custom (but also put at bottom in the editor).

As I said, I have no idea about how to fix this problem. Please, can anyone tell me why is this happening and help me to fix this?
Thank you very much.

UPDATE: THE SOLUTION :smile::smile::smile:
Well, after changing the box collider increasing it’s height, I found that the character keep rendering on top and not hiding. I cound’t get the same problem as I mentioned in first place (rendering on top a little then hidding behind the box).

Anyway, the solution is the next one:
If you want the character to hide a lot behind the box as I did, when the character passes half the height of the box sprite, it is rendered on top. You should change the box prefab and set its “Sprite sort point” to “Pivot” (box sprite should have its pivot in bottom). This way, the character will not be rendered on top (unless it passes the bottom pivot, which is impossible due to the collider).

If you want to keep the sprite sort point of the box prefab as “Center” instead of “Pivot” (for any reason), you just need to adjust the collider to be tall enough to pass half the height of the box sprite, so the character will not pass that point and Unity will not render the character on top (as Unity uses that point to calculate which thing goes on top).

Have you changed the Collision Detection in the Rigidbody 2D ?

7552057--933730--Collision.png

Thank you very much for your answer.
I tried what you said. I changed the collision detection in the rigidbody2d of the character objetc to “Continuous”.
It seems to work much better. At first I thought it was perfect after making this change. But it still generates the same problem sometimes (like 10-20% of the times).
In the gif below that I made, you can see that at the third attempt it still makes that overlap.

7552543--933778--pgif3.gif

I would like to know if there is a way to fix this to ensure that it will work 100% of the times.

Anyway, with the solution you have proposed it works much better. Thank you very much. :slight_smile:

Are you able to provide the project? I think it has something to do with the transform/ pivot of the box

Why don’t you just move the collider a bit up? I don’t see the problem doing that.

Are you always moving the object by calling .MovePosition() on the Rigidbody2D? If you are directly manipulating the transform.position you are bypassing the physics system and it may glitch on you.

Yeah, no problem.

Here you have the link to download the whole folder of the project as a zip file:
https://mega.nz/file/QoMjlYrQ#l4XfP8Q7GY_w3IxTGdlVm1EMOjVVbpEFeqtXiNwPSus

Or if you prefer, here’s the link to get the exported assets package. You will have to open the scene called “MainScene” and to set the custom axis for the graphics (Project Settings > Graphics > Transparency Sort Mode: custom axis & Transparency Sort axis x=0 y=1 z=0).
https://mega.nz/file/t8N1kQIR#JOIpd8NUtAa6RU6FACMVOURjP-u4YdQVdw4CbE23gF4

Just in case you find a different behaviour of the scene: I tried to chagne the collider boxes as another user suggested. Now, after the collision, the character doesn’t even hide behind the box sprite. I undid the changes and set again the colliders as they were before. The problem still remains.

I am afraid after I did that, the problem still remained, but now it’s worse. Now the problem always happens, and the character doesn’t even hide behind the box. I tried to put the colliders as they were before, but the problem remains. :face_with_spiral_eyes:

7554409--934021--pgif4.gif

It doesn’t make any sense at all. How can changing the collider boxes makes this happen? XD

EDIT:
I am not sure if you meant to adjust the collider of the box so the character doesn’t pass through it. But I want the character to “hide” behind the box (to half of the box height aproximately), to make it more realistic, as the tutorial shows. The problem is not that.

EDIT 2:
Ok, I finally understood what you meant. Yeah, one solution is to increase the height of the collider so the character doesn’t pass the medium height and it’s not rendered on top either. The other way to solve the problem is to change the pivot to botom and set the sprite sort point to custom in box prefab. I explained the stuff in my last post, as well as the solution. :slight_smile:

I don’t understand why this conversation is steered towards physics. Physics doesn’t control render sorting. It can restrict positions but the conversation seems to be jumping between subjects.

If you’re fractionally on the limit where the sort point takes effect then you’re being too precise, give yourself a larger margin for error. If it’s not that then it’s not related to physics and is some rendering issue.

1 Like

Yes. This is the controller code I am using. In the last part of the code I am doing what you mentioned:

7554454--934036--controller code.png

So it seems to be what you said. Thank you very much.

I am still not sure about how to solve the problem.

EDIT:
I changed some part of the code (it wasn’t updated in the Spanish course, but anyways I used both the right one and the previous one before opening this thread) but the problem still remains. The code is:

7554454--934051--controller code 2.png

Anyway, as I said, I still see the same graphic problem.

Thank you for your answer. Sorry for my ignorance in the subject, but I don’t know how to implement what you said to test the problem and try to fix it. How do I increment the margin for error and where? I think I am not understanding what you mean.
And if it’s a rendering issue, is there any way to solve it?

To be able to solve something you need to know what’s going wrong; that’s not been established so nobody can tell you.

If you are saying it’s going too far down then increase the size of the collider so they STOP you going too far down as has been said above here .

If this isn’t the problem and it’s NOT going too far down then it’s a rendering thing. Rendering order is based upon where the sprite pivots are. Ignore your movement code and just place it in edit mode yourself and check what’s going on?

None of this should be relevant and again, the conversation about physics is just distracting from you debugging the problem. Do what I suggested above and make sure that when it’s in the position you want, it renders correctly.

1 Like

Thank you for your comment. It helped me to solve the problem.

I didn’t get the idea of “increasing the sie of the collider”. I did that, but the problem remained.
After reading your comment, and not looking anymore at the controller code, I started to check things in the Edit mode again as I did before opening this thread. But as you said, I tried placing objects and moving them in the Edit mode trying a few things.
The issue was so simple that I am still amazed by how easy it was.

I saw that the character was on top of the box after some position (nothing new), but I realised it was the middle of box height. Then I understood.
As the character goes down, it passes that middle point and renders on top of the box. So, in the prefab of the box I adjusted the “Sprite sort point” to “Pivot”. Now, it worked! The character never renders on top anymore.

After that I understood the idea of increasing the collider size. I didn’t make it taller enough when I changed it before. But by adjusting the box collider to pass that middle point of box sprite height, the problem is also solved, event if in the box prefab the “Sprite sort point” is set as “Center”.

The reason why I didn’t change the “sprite sort point” in the box prefab before was that in the tutorial it wasn’t mentioned (and it is not necessary to do so, unles you make the collider box as short as I did). So now, there are these two options to solve the problem.

I have to say that the reason why I opened this thread was that the first problem I found was really weird. Let me explain this.
After changing a little bit the collider box as other user mentioned, then everytime the character was on top of the box when colliding (because of the height and the middle point of the sprite as I said).
But the first problem I saw (the one I explained in the first post) was that the character only was redered in top of the box for a moment before hidding back again (I still don’t know why was this happening, but it doesn’t happen anymore).
That’s why I thought it had some relation with the movement, like if it was passing some point of the sprite for just a moment (maybe passing that middle point). And that was the reason why I wasn’t focusing on the pivot of the box. I just checked that everything was like in the tutorial. That was the difference. But now everything works fine!

So, to sum up for someone that finds the same problem (I will put the solution in the first post):
Change the “sprite sort point” in the sprite renderer of the box prefab to “Pivot” (and the box sprite should have the “Pivot” in “Bottom”). By doing this, even if the character passes the half of the box height, it would not be rendered on top.
Or if you want the box prefab to have “sprite sort point” set as “Center”:
Increase the box collider of the box height, so the character would not pass the half of the box height and Unity would not render it on top of the box either.

Thank you very much to all the people that spent time reading the problem and helping me. And thank you, @MelvMay for your answer, it helped me to focus on the right things and to solve the problem.

Here’s our little friend in the game doing what she is supposed to do:
7555060--934204--pgif5.gif

Thanks a lot for taking the time to come back and give us a post-mortem. Your words are highly-likely to help someone in the future. I personally haven’t done much with this position-based sprite sorting so it was a learning experience for me directly.

If everyone replied with their solution in the detail that you did, the forums would be a better place. As Kurt put so well, thanks for taking the time here to post that. Very much appreciated and good luck with your projects.

I’m glad to read that. I personally learn a lot from other’s answers in different forums when programming, so I thought this could be helpful to someone in the future.

1 Like

Thank you very mcuh, MelvMay.

1 Like