# Draw-order based transparency issue

**URL:** <https://discourse.processing.org/t/draw-order-based-transparency-issue/22675>\
**Category:** Coding Questions\
**Created:** [July 17, 2020, 2:43am UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675 "2020-07-17T02:43:25Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![chittyxz](https://avatars.discourse-cdn.com/v4/letter/c/f475e1/32.png) [@chittyxz](https://discourse.processing.org/u/chittyxz)\
**Post date:** [July 17, 2020, 2:43am UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675/1 "2020-07-17T02:43:25Z")

</div>

I am having a transparency issue with drawing multiple POINTS style PShapes into a P3D PGraphics object. Each Vertex inside the PShapes has its own image-driven alpha value. Vertices with **partial** transparency misbehave. Those in PShapes drawn _later_ will properly blend partially into PShapes drawn _earlier._ The PShapes drawn _earlier_ will still exhibit partial alpha transparency, but they will **completely** mask out (i.e. fully occlude) PShapes that were drawn later. In other words, it appears that PShapes drawn _later_ only check for the existence of a potentially occluding pixel–they do not evaluate whether its alpha value is greater than 0.

I am a new user so it will only let me post one image at a time. Below is Image 1. See the followup post for Image 2.

 ![V1_Correct](https://canada1.discourse-cdn.com/flex036/uploads/processingfoundation1/original/2X/6/64932179a19fa7edd4af2a3862efb9a90c70a226.png)

Image 1 illustrates the **desired** behavior. Image 2 illustrators the **incorrect** behavior, with the circular image masking entirely through the face layer.

The only different is the order the PShapes were instantiated into PGraphics objects: Image 1 first added the red square, followed by the face, followed by the circular image. Image 2 added the red square, followed by the circular image, followed by the face.

This behavior is not acceptable for the purposes of this Sketch, because in some situations five separate PShapes will all have partial transparency information, in which case no PShape loading order would produce a correct result.

I have tried altering various **hint()** properties. None produce the correct result in situations where the order is “wrong.”

The script is too long to post in full, so there’s a pseudocode description of the process below. I will happily repost excerpts that might be useful for evaluating the problem, but I’m expecting the issue is more deeply rooted.

**Pseudocode:**  
PGraphics canvas = createGraphics(width,height,P3D);  
PShape s1,s2,s3;  
s1,s2,s3 = createShape(POINTS); _all vertices derived from image pixel values_  
canvas.shape(s1);  
canvas.shape(s2);  
canvas.shape(s3);  
image(canvas,0,0);

It’s the order that I call the canvas.shape(xxx); commands that affects transparency performance.

One (not ideal) solution would be to load **all** images’ vertices into a single PShape, but this would not be ideal because I allow interactive repositioning of each image cloud, and resetting 2,000,000 vertices is much slower than translating a PShape.

Please let me know if there’s anything that can be done to resolve this. I am running Processing 3.5.4, Java mode, on a 2019 Macbook Pro. Thank you!

---

<div class="post-metadata">

**Author:** ![chittyxz](https://avatars.discourse-cdn.com/v4/letter/c/f475e1/32.png) [@chittyxz](https://discourse.processing.org/u/chittyxz)\
**Post date:** [July 17, 2020, 2:44am UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675/2 "2020-07-17T02:44:50Z")

</div>

Below is Image 2, showing **incorrect** behavior, where PShape drawn earlier (the circle) masks entirely through a PShape drawn later (the face), which has no transparency.

 ![V2_Incorrect](https://canada1.discourse-cdn.com/flex036/uploads/processingfoundation1/original/2X/9/924e63e8be2db60d22ae22353636c11a4b3c86c1.png)

---

<div class="post-metadata">

**Author:** ![talfred](https://avatars.discourse-cdn.com/v4/letter/t/779978/32.png) [@talfred](https://discourse.processing.org/u/talfred)\
**Post date:** [November 30, 2021, 10:02pm UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675/3 "2021-11-30T22:02:16Z")

</div>

I just discovered the same, using only simple ellipses as shapes.  
In an array of 7 objects, with alpha values, the first drawn will not display the alpha value.  
If drawing from last to first5, the opposite

is there a fix for this problem now?

---

<div class="post-metadata">

**Author:** ![BennyHacker](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/bennyhacker/32/2969_2.png) [@BennyHacker](https://discourse.processing.org/u/BennyHacker)\
**Post date:** [December 1, 2021, 12:02am UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675/4 "2021-12-01T00:02:08Z")

</div>

Not sure if I fully understand the problem but from my own experience Processing will not blend alpha values like other software can. In order for proper blending, the transparent shapes must NOT overlap or else undesired visual effects will be produced. Also the objects should be sorted from front to back. I hope this helps…

---

<div class="post-metadata">

**Author:** ![chittyxz](https://avatars.discourse-cdn.com/v4/letter/c/f475e1/32.png) [@chittyxz](https://discourse.processing.org/u/chittyxz)\
**Post date:** [January 23, 2022, 7:48pm UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675/5 "2022-01-23T19:48:00Z")

</div>

Just confirming that there is no fix to it–this is just how Processing handles alpha. You’ll always have to make a layer order decision, and it will impact the final appearance.

---

<div class="post-metadata">

**Author:** ![scudly](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/scudly/32/5597_2.png) [@scudly](https://discourse.processing.org/u/scudly)\
**Post date:** [January 23, 2022, 8:32pm UTC](https://discourse.processing.org/t/draw-order-based-transparency-issue/22675/6 "2022-01-23T20:32:36Z")

</div>

The only way for multiple transparent polygons to render correctly is to draw them from back to front. OpenGL, and, therefore, Processing, don’t know anything about the front to back order of your polygons and so can’t render them as you would like. OpenGL uses a z-buffer to store depth information per-pixel and, when drawing a random triangle, will only draw a given pixel if it is closer to you than (in front of) all the previously seen triangles that overlap that pixel. Transparency breaks this since you can see through a pixel to the triangles behind. The problem comes when you later try to draw a new triangle that falls between previously seen transparent triangles. The z-buffer only knows the depth of closest triangle, whether it’s opaque or transparent, so it assumes the closer pixel must be hiding the new triangle’s pixel and doesn’t show it.

The only way you can handle this is to draw all of your opaque triangles first, in any order, letting the z-buffer order them per-pixel. Then you have to manually sort your transparent triangles based on depth from the camera and draw them into the scene from back to front. If any of your transparent triangles intersect each other, you have to split them along the line of intersection and render the back halves first and then the front halves. It’s a mess.