scatter3d points aren't ordered by depth across traces

[etpinard]

See http://codepen.io/etpinard/pen/oYOMZO

[etpinard]

cc @dfcreative

[alexcjohnson]

#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: 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...

[rreusser]

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.

[dy]

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.

[etpinard]

cc @archmoj

[archmoj]

Issue example displayed in a candidate patch: codepen.

[brianpenghe]

I also have this issue when having opacity = 1. Any solutions?

[drscotthawley]

Wow, 4 years old and still no solution. How can we help?

Currently seeing this: If I start with the first figure and rotate it a bit toward the right such that the blue points should be in front of the brown points,.... the blue points disappear completely ??

How can we help fix this? I'm not a JS programmer (these are from Python) but... willing to try to contribute if it means getting non-nonsense plots.

NOTE: This behavior is independent of opacity value; even opacity=1.0 yields this foreground/background mixup.

[alexcjohnson]

@drscotthawley (and @brianpenghe if you're still interested, sorry I didn't see your comment last year!) I don't see any problems in my tests with opacity=1.0, can you share some self-contained code showing the issue you see with that?

Unfortunately, for any opacity < 1 as some of the older comments here say, there seems to be no good known order-independent algorithm, which means we can't parallelize the render in the usual way, and the solution would need to be a major rewrite of our rendering system, and likely far slower than what we do today.

[tabeaf]

Hi, so this is kind of how I'm using scatter3d in my js code, and have the same problem, also with opacity: 1.0
https://jsfiddle.net/kosgcfhv/
The orange "b" trace appears in front of the blue "a" trace no matter how you rotate the plot, even in cases where the blue trace should be in the foreground.
I hope my question and code is clear and would appreciate any help!

[drscotthawley]

@alexcjohnson Thank you for your reply. I am now looking at a 3d scatter plot in plotly Python 5.14 made via Express with opacity=1.0, where background objects are 'covering up' foreground objects. I don't have a minimal example to share at this time. But I see that @tabeaf's JS version demonstrates the problem too.

I understand re. the major code overhaul; sorry I failed to read some of the previous discussion carefully.
I wonder if it might someday be possible to switch to a "slow render" method for things like saving figures, that might support transparency.