koobas.hobune.stream
2D Z-Fighting - I have no idea how to fix this, someone please help!
Alright so, as the title says, this is an issue with 2D Z-Fighting, specifically, the "coins" that I am using.
What is the specific details? And what in the heck is going on in the image above? Well here is my understanding!
The Coins consist of two objects, the coin 'base', which contains the inner part of the coin, and the coin 'border', which rotates around the coin base. It achieves this rotation animation via the inbuilt Unity Animation thingo, the z-rotation property is linearly animated between 0 and 360 degrees, with loop pose turned on. This makes the animation real smooth like.
Normally, I wouldn't care if two coins were Z-fighting, as long as they were always fully layered... however that was back when coins were one object. Now the border of one coin can render in front of another coin.
Now, if you'll note, the above statement provides a solution: just create a sprite-based animation externally, then the spinning border and base will be considered as one render, giving me the behavior I had before. But man! Is it tricky to get a seamless rotation externally, without it looking a bit jerky! it looks much better when rendered internally anyway! (Also it's harder to animate it externally, as free animation tools... sigh... I mean, I have been using OpenToonz which can do what I want, but it adds a weird yellow outline to the border-part of the coin... but that's a whole different issue.)
Another solution I came up with would be to assign a different layer order to each coin and border pair, or well... two layers orders to insure the border renders in front of each instance of a coin. But I don't feel comfortable doing it like that, it seems like it might cause a lot of overhead... you know?
Ah well, I'm just wondering what would be the best way to tackle this situation, any insight would be greatly appreciated!
Well, that's still beta, but didn't Unity 5.6b introduce something like sorting order order? You can always look for other solution, but as far as I read changelog there was something that I understood as you can sort sprites in their "local space" and then sort combinations in the old way.
You just a thought
Yes. By "layer order", I meant "order in the layer" : P. Or well, sorting orders in layers... Sorry, it made sense in my head, you know how these things go : P.
Thank you tho!
I think you'll ultimately have to specify the order in layer as you suggest. You should only have to do that once though when you create the coin. In theory you could try and keep track of what layers are used, but I would hazard that you'll do just as well choosing a random order-in-layer each time you spawn one.
i.e. on spawning a coin:
pick a random order-in-layer with something like mylayer = Random.Range(0,1000)
iterate over all the sprite renderers in your coin and set their order in layer accordingly
You can build on that solution by reserving multiple slots in the layer for a coin or changing the range of layers you use).
mylayer = Random.Range(0,1000)*10 + 100 //gives each coin 10 order-in-layer slots to play with, starting with layer 100
It won't be perfect, but it'll be nearly perfect and that's generally what you're after:, with these things :)
Ah... Hmm... that could work!
I'm just wondering if all those extra layers would add significant overhead, but I suppose that won't be too hard to test for. Thanks!
Heheheh... I almost didn't fully understand your answer as I forgot the "start" function was called even for things that aren't instantiated during game play (the coins are placed around the map as well as being dropped by enemies), because I am very silly. But yeah :D, thanks again for the help!
I'll complain at you if it brings up bugs that are probably 100% my fault XD.
