<p>I would say the reason for reducing cases of alpha blending (or testing) has less to do with the cost of the actual read-modify-write but more to do with increasing the use of early Z testing that's available in either, say, a TBDR system (eg PowerVR) or in systems with hierarchical Z.</p>
<p>For early Z, which can reject a significant amount of otherwise redundant work, the driver/API needs to know the geometry is 100% opaque. As soon as there is a chance of a blend, the early-Z probably needs to be disabled. Note that its not just the read-modify-write we should be concerned about - early-Z often avoids running potentially V. expensive shaders.</p>
<p>For cases where there is alpha tested geometry, e.g. a leaves of a tree, it may be beneficial to replace, say, every leaf that's modelled with a pair of alpha blended triangles with multiple triangles so that some of those tris are guaranteed to be 100% opaque. All the opaque tris should be batched together and rendered first as opaque.</p>

CC BY-SA 4.0
2022-10-28T13:51:18.700Z
This is definitely very informative, but by minimizing the amount of alpha, I meant reducing the amount of it on a model, and not either having or not having at all. So for example with a leaf example we could use a simple rectangle with a texture of leaf, but then you would have a lot of alpha on the model. If you instead use a bunch of triangles to more closely approximate the shape of the leaf, you minimize the amount of alpha on the model. And that's what I've seen professional modelers do sometimes. So doesn't have to do with early Z then, since there's still some amount of alpha.
Lenny White
CC BY-SA 4.0
2022-10-28T16:32:45.230Z
@LennyWhite : I *think* that is partly equivalent to what I was saying - use more geometric information and reduce the number of places where alpha is needed.
You can still have alpha blending and/or testing, but by moving it later in the submission order, the probability of hitting such an object decreases (due to having more opaque data earlier) and thus also likely reduces the rendering cost.

Of course, you are expending more effort on geometry so there will probably be a point where there are no more savings to be made and actually start slowing down
Simon F
CC BY-SA 4.0
2022-10-27T09:02:59.690Z
2022-10-27T09:02:59.690Z
Simon F
<p>When modeling something like a hair or foliage using textures with alpha value for offline or real-time rendering, it seems to be common practice among computer modelers to try to minimize the amount of alpha in the textures, referring to it being very GPU intensive. I wonder if this is true for both alpha testing and alpha blending techniques? With alpha blending it's pretty clear that the additional alpha would result in more fragments having to be alpha blended. Also if order-independent transparency techniques are used, I imagine more alpha would make it slower (?). With alpha testing however we just discard fragments based on an alpha threshold. But I wonder if this process is GPU intensive?</p>

<texture><alpha>
Why is it so important to minimize alpha in textures for rendering
Lenny White
# Why is it so important to minimize alpha in textures for rendering

(Asked by: username_0 on 2022-10-25)

When modeling something like a hair or foliage using textures with alpha value for offline or real-time rendering, it seems to be common practice among computer modelers to try to minimize the amount of alpha in the textures, referring to it being very GPU intensive. I wonder if this is true for both alpha testing and alpha blending techniques? With alpha blending it's pretty clear that the additional alpha would result in more fragments having to be alpha blended. Also if order-independent transparency techniques are used, I imagine more alpha would make it slower (?). With alpha testing however we just discard fragments based on an alpha threshold. But I wonder if this process is GPU intensive?

**Tags:** texture, alpha


---

## 1 answers

### Answer by username_1 on 2022-10-27. Score: 1

I would say the reason for reducing cases of alpha blending (or testing) has less to do with the cost of the actual read-modify-write but more to do with increasing the use of early Z testing that's available in either, say, a TBDR system (eg PowerVR) or in systems with hierarchical Z.

For early Z, which can reject a significant amount of otherwise redundant work, the driver/API needs to know the geometry is 100% opaque. As soon as there is a chance of a blend, the early-Z probably needs to be disabled. Note that its not just the read-modify-write we should be concerned about - early-Z often avoids running potentially V. expensive shaders.

For cases where there is alpha tested geometry, e.g. a leaves of a tree, it may be beneficial to replace, say, every leaf that's modelled with a pair of alpha blended triangles with multiple triangles so that some of those tris are guaranteed to be 100% opaque. All the opaque tris should be batched together and rendered first as opaque.

> **Comments:**
> **username_0**: This is definitely very informative, but by minimizing the amount of alpha, I meant reducing the amount of it on a model, and not either having or not having at all. So for example with a leaf example we could use a simple rectangle with a texture of leaf, but then you would have a lot of alpha on the model. If you instead use a bunch of triangles to more closely approximate the shape of the leaf, you minimize the amount of alpha on the model. And that's what I've seen professional modelers do sometimes. So doesn't have to do with early Z then, since there's still some amount of alpha.  
> **username_1**: @username_0 : I *think* that is partly equivalent to what I was saying - use more geometric information and reduce the number of places where alpha is needed. You can still have alpha blending and/or testing, but by moving it later in the submission order, the probability of hitting such an object decreases (due to having more opaque data earlier) and thus also likely reduces the rendering cost.  Of course, you are expending more effort on geometry so there will probably be a point where there are no more savings to be made and actually start slowing down  

---

