Question Overdraw - is it stopped by opaque meshes?

So I want to have a treeline at the edges of my map, to block line of sight of things.

But im worried about having a heap of them stacking up and it resutling in overdraw as ill be targeting mobile.

If I have the bottom part of my treelines on a opaque shader (Blue here) and just the top as a cutout shader (red),will this stop overdraw?

So I guess im asking do opqaue meshes stop overdraw if you put them between trasnparent/cutout ones?
See final graphic for the scenario Im talking about.

 

Yes, it's a common technique.

I would advise against cut out, and have close fit transparent mesh instead. It's because mobile are using tile base rendering with early z, so a discard from cut out invalidate the cash and force a read back that slow things.

Also such qu'est are better posted in shader forum, there is shader Santa Klaus there, BGolus!

 

Thanks for the reply, I thought this was the shader forum = s.

With the cutout vs transparent thing. Ive had trouble with sorting when using transparent for my trees.
Is there some transparnt option Im missing to fix this sorting issue?

 

I have heard a lot of people mention alpha being slower than cutout on mobile, but have never seen that be the case in practice from my profiling. Especially if you have lots of overlapping geometry, cutout is significantly faster, as it can skip rendering the pixels behind it, even if the pixels behind it are cutout. This is not possible with alpha transparent.

 

LMAO I thought I was still on general my bad lol

 

Which phone though, fragmentation is a pain


Generally you have a chart like this, with note about how the backward arrow from late visibility to early visibility is costly, because memory access is costly.

But that might be true for low end phone mostly, I'm on low end.

 

Yes, but notice how in that graph, alpha blend happens at the end, whereas alpha test (cutout) is iterative/in a loop. With overlapping alpha test, they can early z cull each other. But with alpha blend, they are all forced to be rendered at the end (no opportunity to early kill pixel rendering).

I could see where if you have low overlap (or definitely the case for no overlap), then alpha blend would be faster. But any overlap at all and alpha test starts to be a lot faster because shaders read memory too, and it will be a lot more memory than the visibility testing, unless your shaders are super super simple.

 

This was a serious issue for several GLES 1.0 and early GLES 2.0 devices. But alpha blending was also more expensive than additive blending for some of those devices.

Today both of these are far less of an issue. An alpha test material is more expensive than a fully opaque material, if compared using the same geometry, but that’s not really a fair comparison since usually you’re using alpha tested materials to mimic what would otherwise be quite high polygon geometry. But it’s still useful to note that if you have a large object with alpha tested edges, it might be faster to use two materials instead of one so that any triangles that are fully opaque don’t use the alpha tested material.

For transparent materials, even modern mobile GPUs can struggle with these if you have several that overlap. It is possible you could create situations where alpha tested geometry is more expensive than similar alpha blended ones, but they’d be fairly contrived setups with alpha tested geometry using random noise for the alpha. I know I’ve managed to do so. However almost anything with GLES 3.0 support or better is going to handle alpha tested geometry far better than the older counterparts.

Many modern mobile GPUs use TBDR (Tile Based Deferred Rendering) which renders out all opaque geometry’s depth (and sometimes other data) first, and then renders that opaque geometry again using the actual shaders. This two pass approach means that only the visible geometry ends up having their shaders rendered. On older GPUs this depth buffer was stored in a specially compressed format that didn’t actually store the actual per pixel depth. The problem with alpha tested materials is it forced the GPU to uncompressed the depth buffer and store the actual per pixel depth which made rendering to those tiles more expensive. Today they’re still often using compressed depth buffers, but using techniques that can handle per pixel depth without being a performance hit. The other big change is a lot of older GPUs would only do the TBDR on fully opaque geometry, and alpha tested materials would get rendered afterwards like transparent geometry, meaning potentially a lot of alpha tested surfaces would be rendered and not end up in the final image if another alpha tested surface ended rendering closer afterwards. Today any modern mobile GPU that does alpha testing and TBDR does the alpha testing as part of the initial depth pass. It generates special depth & alpha test only shader passes to render first before rendering the color pass.

Unfortunately there’s not one perfect set of rules for when to use higher poly opaque geometry, alpha tested geometry, or alpha blended geometry as the case for when one is faster or slower than the other options depends on a wide range of factors. Those factors include which specific GPU you’re running on, but also what the exact assets you’re using are for that geometry, or what else is in the scene. It’s always a balancing act. In the past big budget mobile titles would have dozens if not hundreds of phones they’d test on and sometimes build unique assets for certain sets of them to ensure frame rate could be maintained. Today almost no one is going to do that beyond maybe a small handful of devices to test general “tiers” of performance because even “old” devices are surprisingly fast.