anchor.diff:  = Transparency Sorting
  -:author:
  -:revnumber:
  -:revdate: 2016/03/17 20:48
  +:revnumber: 2.0
  +:revdate: 2020/07/13
   :keywords: transparent, sorting, bucket, z-buffer, alpha
  -:relfileprefix: ../../
  -:imagesdir: ../..
  -ifdef::env-github,env-browser[:outfilesuffix: .adoc]
   
   
   There is often a lot of confusion with how pixels get processed in relation to the z-buffer and why sorting is important.  Most importantly it can be mind-warping trying to wrap one's head around how to 'fix' the cases where proper sorting isn't possible.
  
positive.code: Finally, I'll augment the worst case sorting with something like `alphaDiscardThreshold` (or the old alphaTest/alphaFalloff values).  In this example, let's pretend we only discard pixels with alpha = 0.
  
  
  image::jme3/intermediate/transparency_sorting3.png[transparency_sorting3.png,width="600",height="",align="center"]
  
  
  It's better but not perfect.  Any partially transparent pixels will still show the issue.  Partial transparency will drive you crazy if you let it.
  
negative.code: The first image I'll show is the 'best case' where all objects are drawn back to front.  I'll then discuss briefly the steps JME goes through to try to make that happen.
  
  
  image::intermediate/transparency_sorting1.png[transparency_sorting1.png,width="600",height="",align="center"]
  
  
  In JME, the opaque layer would generally be placed in the opaque bucket.  All opaque layers are drawn first and within the ability to sort them, they are sorted front to back to prevent overdraw.
  