1
$\begingroup$

I've read Wikipedia's article on the topic, and a tutorial on how it affects MikuMikuDance. I tried to read a patent on "packing the 3D array with a prefix sum scan, or linearizing", but I have no idea what "a prefix sum pass on the generated count buffer to calculate locations in a fragment buffer in which to store all the fragments linearly," means.

Wikipedia says exact OIT requires "storing all fragments before sorting and compositing".

Would the following be compatible with current technology?

  1. find the minimum and maximum Z-depth of each transparent material, or object.
  2. order materials that don't collide in Z-depth, and determine which ones do exist at the same Z-depth.
  3. blend transparent materials until you reach materials that have the same Z-depth, so draw order is uncertain.
  4. store only the fragments for the potentially intersecting materials, whether it's two or more.
  5. sort these fragments by depth and blend them.
  6. continue on with nearer materials.

Instead of just Z-depth, could maybe also use X and Y coordinates or even an efficiently-created shape of a different orientation, like a box around a pane of glass to the side of another transparent object. These would reduce the number of times steps 4 and 5 would have to be done, but are steps 5 and 6 compatible with current or potential future GPUs?

$\endgroup$
  • $\begingroup$ Commenting on my own question: MikuMikuDance lets you create mirrors. If you have two mirrors that should reflect each other, one of them won't show the other mirror, while the other one will show the mirror as a gray screen. In this case, draw order may be important, but the rules for transparent objects won't solve it. Order-independent transparency may reduce the need to manually set draw order without eliminating it. $\endgroup$ – Misaki May 8 '18 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.