Z sorting difference from editor to iPhone

Unity Engine
1

Did anybody have the same issue ?

I’m using a simple transparent shader for the Waitress, with Zwriting off, using Blend, not AlphaTest.

first screen is iPhone, second Editor.

205126--7558--$ss_iphone_637.jpg
205126--7559--$ss_unity_901.jpg

2

zwrite off and having blend is a very bad idea.
as both pixels have different depths, its up to the gpu to decide whats in front and the iphone gpu is very optimized to drop stuff as early as possible for example to prevent overdraw along with other optimizations. (it behaves significantly different from any desktop gpu)

I would recommend you reenable z writting and use depths if oyu want control over what is in front and what not, otherwise you can only guess what will be in front, there is no defined “right” or wrong result

3

I understand. But wasn’t Zwriting meant to be off for transparency shaders ?

Because if we turn it on, translucent pixels will hide the ones they overlap, won’t they ?

4

I don’t know why transparent pixels should hide the ones they overlap.

z write off basically means that you forbid the pixel to write its z value, so it no longer has any depth.
Without having any depths, they can’t be in front or behind things any longer, as these concepts don’t exist without depth.

But perhaps I’m just missunderstanding the whole thing.

5

I had a big whine about translucency randomness in this thread lately.

Basically, the reason behind Alpha pixel hiding what they overlap is that they are based on their primitive. For example, a plane with a transparent texture overlapping an opaque triangle would display a void, as renderer first calculate primitives culling, and then texturing.

In general, it is advised to render transparent pixels by ordering objects from back to front on iPhone (which Unity is doing with renderQueue = transparent), and to disable Zwriting. This Unity doc presents it.

But I do agree with you on the fact that I can’t understand how it is possible to render things properly without zwriting.

Damn, this Alpha management is such a mess …

6

for depthsort / alpha I would recommend you to ignore the editor and use the device.

thats one of the few things where the differences between ALL GPU vs iphone gpu is by far the largest.

7

Yep, I think this is where I’m forced to go.

It’s no good, though, as I will have to compile so much often now …

8

I’m using alpha too but the sprite manager / sprite ui particle z shader that comes with it and don’t have ANY problem in game view or on the device (only the editor view goes bogus but who cares about the editor doing something stupid during game mode :slight_smile: )

so I would give that a go first and then care about higher build frequencies :slight_smile:

9

Yeah I’ll take a look to this particle Z mechanism, thanks for the tip :slight_smile:

10

Ok, I found this Shader’s dirty secret about being always successful : It uses AlphaTest :slight_smile:

But this is problematic, AlphaTest still being unrecommanded for iPhone :cry:

I’m still totally surprised that so many devs are using AlphaTest on iPhone … They should check the performance gain when they replace it by Blend only.
(average x1.5 faster)
I know Blend-only is difficult to proceed, but seems like nobody wants to search in this way :roll:

11

Yeah alpha test is definitely a costly thing.
But so far I had no reason to invest any time on that end. but once I will have to I am sure I will find a way to get that thing working the way its meant to … the iphone has supreme early out capabilities and it must be able to use them and use blending together without bombing the whole thing.

12

This would take a load of work, I think.

Actually, ReJ even advised me (by mail on a bug report) to avoid translucent textures.

As he is the tech leader, it is kind of revealing about the pain that is translucency :confused:

I can’t understand why some very early 3D games had tons of sprites on screen, without any slowdown (Doom, Duke Nukem, etc)…