# hasVertexAlpha causes problems when \_unIndexed is used directly **URL:** \ **Category:** Bugs\ **Created:** [January 22, 2020, 4:02pm UTC](https://forum.babylonjs.com/t/hasvertexalpha-causes-problems-when-unindexed-is-used-directly/8181 "2020-01-22T16:02:01Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\ **Post date:** [January 22, 2020, 8:11pm UTC](https://forum.babylonjs.com/t/hasvertexalpha-causes-problems-when-unindexed-is-used-directly/8181/4 "2020-01-22T20:11:46Z")
> [@Philippe](#): > > Somehow, I would have expected that if a mesh `hasVertexAlpha` but with the max alpha value of 1 would be visually the same as a mesh which `hasVertexAlpha=false` . Am I wrong? Indeed. When a mesh is flagged as transparent, it does not write to the depth buffer when rendering, leading to potential artifacts, depending on your scene and meshes. See [https://doc.babylonjs.com/resources/transparency\_and\_how\_meshes\_are\_rendered](https://doc.babylonjs.com/resources/transparency_and_how_meshes_are_rendered) for more details. In your case, the blue cube is rendered first because it is defined first in the vertex data. So, when it is in front of the turquoise cube as in fig 1, the display is wrong because the turquoise cube being rendered second, it overwrites the blue cube (remember that the depth buffer is not written for transparent objects). You could try to use facet data sorting (see bottom of previous document), but it only works with indexed meshes… --- _[View the full topic](https://forum.babylonjs.com/t/hasvertexalpha-causes-problems-when-unindexed-is-used-directly/8181)._