cc @dfcreative
opacity: 1 I see a mixture of blue and grey throughout, not one color dominant throughout the dense middle part:
This seems to me frankly a major bug for partly-transparent traces. It means the essential 3d-ness of the plot is silently lost, making you think the last trace drawn has a greater extent than the others or something...
Painter's algorithm is one solution, but that means view-dependent sorting. Unfortunately order-independent transparency tends to be pretty nontrivial to the best of my knowledge. 馃槥
The only other simple workaround I can think of is making the colors strictly additive or subtractive so that they might be partially transparent, but the order has no effect on rendering. It'd mean a pretty abrupt discontinuity between transparency 0.999 and 1.0 though.
Seems that we have to do single gl-scatter3d render pass for accumulated data, logically. Trying to figure out how are we doing that now.
cc @archmoj
Issue example displayed in a candidate patch: codepen.
Most helpful comment
1466 at least makes the behavior not be path-dependent, so that's good. But there's a bigger issue here: points aren't ordered by depth across traces. The trace that was drawn last always has all its points in front of the other traces, even if they are really farther away. It turns out this is only an issue for traces with opacity. If I change the traces in http://codepen.io/etpinard/pen/oYOMZO to
opacity: 1I see a mixture of blue and grey throughout, not one color dominant throughout the dense middle part:This seems to me frankly a major bug for partly-transparent traces. It means the essential 3d-ness of the plot is silently lost, making you think the last trace drawn has a greater extent than the others or something...