I use an ortographic camera view and only Paper2D actors. When I deploy to device (android) sometimes I see z-fighting issues due to floating point precission. I only use y-axis for layering paper2d sprites (besides some simple 3d mesh like walls). I see z-fighting if sprites are close enough (setting a sprite on Y = 1.0 and other in Y = 2.0 can experiment z-fighting).
A workaround is to set a distance in Y-axis enough to avoid z-fighting issues but I do not like this approach, since this game being a 2D game I should not have any problem.
Ideally I would like to define a camera frustrum with a depth low enough for puting all my 2D objects without z-fighting issues.
Would you mind providing me with a couple of screenshots with assets you are seeing z-fighting?
Also, are you using any translucent materials for your sprites? This could be causing some of your sprites to render through your translucent materials and have a similar effect to z-fighting.
One thing to try would be to rearrange sorting order in which your sprites are rendered. Make sure any sprites that have a translucent material be rendered at same depth. There is a similar question I found here on AnswerHub that also can provide you with more detailed information on how to fix this issue.
Z-Buffer 2D Issue
Let me know when you have attempted these resolutions. If you are still unable to get right outcome, let me know and we can explore some other options.
This is not a translucent issue. I hardly have only one translucent material and its not involved in issue.
As I said, If I put sprites close enough in Y-axis (ie depth) then Z-fighting issues occur when deploying to android.
For example, two sprites one at Y = 1.0f and other one at Y = 2.0f might produce issue.
Playing in PIE / mobile preview this does not occur. Only on device. I guess setting depth buffer to 32bit would fix issue but is a bad workaround IMO.
Which Android device are you using to test your game?
Is there any reason you would not want to space out your sprites by more than a single integer value? If this is happening only when two sprites are very close in depth, then changing render depth would be a good solution.
You could also have some of your sprites render in a custom depth so they are completely separate from one another, and there won’t be any room for sprites to have this visual issue.
What I want is to be able to use my Y-axis to layering sprites. I want to avoid z-fighting when two objects are close enough in Y-axis. Or, at least, what is minimum epsilon-distance in Y-axis to avoid this issue?
I can not go over each renderable and change custom depth and I do not think this is a valid/scalable solution.
Currently documentation on 2D sprites is fairly limited at this time because Sprite Editor is still not fully production ready. As documentation suggests it is still a work in progress, but is on road map for improvements in future.
This is part of reason I am having trouble finding ‘minimum epsilon distance of Y-axis’. Sometimes you can find your exact resolution on our Forums there are users who are quite informative and helpful there as well.
Sorry for delay in response; has gone on vacation for a bit and I’m going to take care of this issue for you.
Just to make sure I understand correctly: It sounds like you have a Paper2D project using an Ortho view camera, and some of your sprites placed at different y values show z-fighting when playing on an Android device.
Does this happen when you Play in Editor? With Mobile Preview?
Does z-fighting only happen with specific sprites, or in specific locations?
If you separate them by more than 1 on y axis, does issue still occur?
Does it only occur with Sprites or does it also occur with flipbooks?
I’m going to try to recreate issue on Android, but any details you can provide may help me reproduce it more accurately. If you’re able to put together a small test project with which this occurs and upload it somewhere for me, we can do it that way too. Thanks!
Hi ,
Yes, I experiment Z-fighting using an Ortho view camera with sprites placed close at different Y positions.
1). This only occurs in android devices. Play in Editor and Mobile preview both work fine. Note: android devices where I test are 2 samsung galaxy S1 and 1 samsung galaxy S3. On S3 issue occurs less frequently (but it still occurs).
This occurs with some sprites at “random” times. Of course if there are no sprites close enough in Y, then it does not happen.
3). I have tried several Y-values I have no found minimum Y-distance to avoid issue. If there is a minimum distance, that would be a good workaround (but I think there should be a way to specify desired degree of depth in ortho view ie. near and far planes).
I have not seen this in flipbooks but I do not use a lot of them.
All my sprites move around, you could try composing a blueprint with several sprite components, animate them with a timeline and if they are close enough you should spot issue on some devices.
Sorry for delay in response, it took some time to test this. In most of devices I tested with, I wasn’t able to reproduce anything like this. I conferred with my colleague who is more familiar with packaging and deployment, and he informed me that S1 is not supported at all, and S3 is only barely supported (there are still a number of bugs with projects on it). In fact, when I launched a default 2D Sidescroller template to an S3 SGH-I747 and an Express SGH-I437, I got a black screen with only joystick visible. On our internal build, it crashed on launch on same devices.
I entered a bug for both (UE-8110) and I will let you know if developers are able to fix that or if we decide not to support S3. Either way, for now I would not expect projects to be completely successful on these. For reference, here’s our Android Device Compatibility page:
Just wanted to update you quickly: bug I entered has already been addressed internally, and I should be able to test that fix in next few days. I will then make another attempt to reproduce z-fighting issue on an S3.
I also heard from one of our developers that this may be an issue already being looked into for certain devices that are giving a 16 bit z buffer instead of 24, which could cause this problem. I’ll keep you updated as I hear more on that as well.
