Thoughts on Overdraw.

I'm learning how opaque geometry is less taxing than transparent sprites on iOS.

1. With particle systems, are transparent sprites the cause of bad performance on mobile? Could you explode a 1000 opaque polys with good performance?

2. If making a detailed city backdrop with various building shapes, will 3d models perform better than 4-5 sprite layers? Could be similar poly count to sprite mesh w/ tight fit, just no overdraw.

3. Does alpha cutoff cause overdraw? I assume it does, and read that cutout shaders are bad for iOS gpu. I was going to animate a pattern using _Cutoff float value. The object would have two textures - base and pattern. Could just animate one texture by looping an array or spritesheet instead.

Alpha cutoff example:

Fun making progress. If you have any wisdom to share, thanks in advance!

 

Not just iOS, opaque geometry is faster than transparency on everything. However alpha test is not equivalent to opaque geometry; by opaque geometry they mean the entire surface of a polygon is considered opaque.

As you read alpha test is significantly slower on iOS than transparency. This is actually true for most mobile platforms as well. The reasons have to do with the various bandwidth and power saving techniques that mobile GPUs use mean discard() or clip() calls (what alpha test uses) causes a stall on the GPU. You can however get something close to alpha test with a transparent shader quite easily, though that doesn't really answer the questions you have.

1. Yes they can be. Opaque particles will be faster than the same number and size of transparent particles. But the main performance problem is overdraw and fill rate so if you keep the particles small they should still be fairly fast. That and opaque particles usually means you're stuck with square or rectangular shapes unless you use mesh particles which can easily get more expensive.

2. Again, opaque will be much faster here as long as the polycount isn't hugely different. A technique some games have used to keep the transparent look while also keeping performance is to have a low poly mesh for the opaque sections and a thin-as-possible close fit low poly edge with the transparent area. Basically keeping the transparent overdraw to a minimum and opaque to a maximum.

3. This is a more complex question. The answer is both yes and no. Full opaque geometry generally gets rendered first filling in the depth buffer front to back. This means opaque objects close to the camera get rendered first and generally occlude the objects behind them so they don't get drawn. There's still a chance for some overdraw here as it's sorted by object and not by polygon and intersecting polygons guarantee some overdraw. Alpha test gets rendered next, again front to back, because it's more expensive (even on PC), and might be occluded by the already rendered opaque geometry. These are guaranteed to add at least one layer of overdraw in the places they're not occluded, but as alpha test generally also writes to the depth they can occlude later alpha test geometry. After that transparent surfaces are rendered and can get occluded by both the opaque and alpha test.

On PC or consoles alpha test is fast to render. Not as fast as purely opaque, but faster than transparency, so using it in abundance where you can is often recommended. Since on mobile alpha test is not fast to render, it's slower than transparency, so it's usually faster to have a couple layers of overdraw with transparent geometry than to use alpha test. With enough transparent overdraw the alpha test can be faster again, but it's rare.

 

@bgolus Awesome reply! Thanks so much. There's a lot I can research here.

My thought on the particles (fireworks) is they are small, but could have a ton of overlap. I could get by with a rectangle, or a simple star mesh

Cool technique on the outer strip for transparency. Was just reading about that. I can actually make 3d buildings faster. I just assumed they would have slower performance than sprites...

It's awesome you understand the order of rendering like that. Lots to learn!

Do you think animating textures by looping a texture array would be slow on iOS? I was going to use alpha cutoff to animate a pattern on an object (as a second texture, which might have to go on a second mesh). I could also loop a sprite sheet.

Nonetheless, thanks for your reply!

 

Sprite sheet animation is no more expensive to render than a non animated transparency. Well, there's a small cost on the CPU for updating the UVs and the cost of a the resolution texture required, but it's unlikely those will even show up in profiling with the existing variability of Unity.

 

Awesome, thanks! Trying some animated textures now.

Found a script for looping a sprite sheet as a texture. Also some info on looping an array, if needed for higher res stuff.

 

Just to share the stuff I found, for anyone who finds this trying to learn the same thing, here are some resources on animating textures.

For animation with small frame count or small image size, this one uses a sprite sheet:
http://wiki.unity3d.com/index.php?title=Animating_Tiled_texture

If you need larger resolution or more frames than can fit on a sheet, here are some options:

An asset with no coding needed: (haven't tried yet)
https://www.assetstore.unity3d.com/en/#!/content/6848

A script that pre-loads an array of textures, which plays smoothly but requires more memory:
http://www.41post.com/4726/programming/unity-animated-texture-from-image-sequence-part-1

A script that loads textures as needed at run time to use less memory, but might not play as smooth:
http://www.41post.com/4742/programming/unity-animated-texture-from-image-sequence-part-2