Using opacityscale with surface results in ordering by addition order, not depth

[wkumler]

Hi all, been using plotly with R for a while now and really loving it - thanks for assembling such a phenomenal program! I'd like to report a bug found while plotting multiple surface objects, which causes them to layer in the order they're added rather than the "depth" at which they should really render in the figure. See this codepen for code and examples, which are also rendered below as screenshots.

I previously posted in ropensci/plotly, but have since learned enough Javascript to assemble the codepen and the issue persists, making me think it's not an R problem. There's also no discussion of the new "opacityscale" feature there and a lively discussion here, making me hopeful that more people will have some idea how I might fix this if it isn't a bug.

This is great:

This is less great (same figure rotated to look from below):

It seems that the surface that renders always on "top" is the one that's added last in the data array. If we alter the above code a little bit to render the top layer surface before the middle one, we get some more interesting results:

Plotly.newPlot('graphDivReorderOpac', [data_z1, data_z3, data_z2]); rather than Plotly.newPlot('graphDivReorderOpac', [data_z1, data_z2, data_z3]);

Apologies for the repetitive code in the codepen - I really did learn just enough JS to make this one and will be hiding behind R wrappers in the future.

[archmoj]

I think this could be improved by #4643. Here is your codepen using that branch.

[wkumler]

@archmoj Thanks for taking a look at this! I'm a little baffled by the new behavior, however. I'm seeing the surfaces become transparent when they overlap rather than stacking in the incorrect order, which I'm not sure is an improvement for the functionality I'm looking at. Is the "opacityscale" still passed as a list of lists denoting min/max opacity? If so, I'd expect no transparency at all when looking at this codepen since everything from 0 to 1 maps to fully opaque.

[archmoj]

I'd expect no transparency at all when looking at this codepen since everything from 0 to 1 maps to fully opaque.

In that case why don't you simply remove opacityscale?

[wkumler]

Sorry, my comment was misleading! In my larger project, I'm using the full range of opacity from fully transparent to fully opaque. To illustrate the issues I'm having, I made this "toy" example in the codepen - which does indeed work perfectly when I remove opacityscale. However, if I were to apply this to my larger project then I'd have the problems illustrated in the latest codepen where things that should be fully opaque are not, despite theoretically mapping to an opacity of 1.

[archmoj]

So you think plotly.js should look into opacityscale array and discard the scale in case alll values are 1?

[wkumler]

Um, maybe? But that still wouldn't solve the issue where a surface is fully transparent on the left half and fully opaque on the right half (which is exactly what I'm trying to do in the larger project). In that case, I do need to use multiple values for the opacityscale, but the fully-opaque halves won't order correctly because they're plotted in the order they're added rather than the one that's on "top" for a given view. With this improvement, the parts of the surface that are fully opaque would still show some transparency, if I understand it correctly.

[archmoj]

Not sure if that would be a major problem... Here is a working demo.

[wkumler]

I'm noticing the same issue in your working demo as I did in your original refit of my codepen - that the regions that should be "fully opaque" aren't, because I can still see the second trace which should be hidden behind it.

Here's my problem illustrated a bit more precisely: I'm hoping to have regions that are fully transparent in the same trace as regions that are fully opaque. Instead, I'm seeing some "bleed through" of the trace behind that appears in front of the trace that should be in front.

[gvwilson]

Hi - we are trying to tidy up the stale issues and PRs in Plotly's public repositories so that we can focus on things that are still important to our community. Since this one has been sitting for several years, I'm going to close it; if it is still a concern, please add a comment letting us know what recent version of our software you've checked it with so that I can reopen it and add it to our backlog. Thanks for your help - @gvwilson

[wkumler]

Hi @gvwilson,

I am actually going to request this remain open as an issue - it is a pretty obvious bug and is still present in v2.33. I've updated the codepen from above to use v2.33 here: https://codepen.io/wkumler/pen/abdWKdg?editors=1010. I realize that there hasn't been much obvious interest in this from the community but at least having it documented as an open bug could help others realize what's going on if they run into something similar.

[gvwilson]

thanks @wkumler - I'll reopen and add to the backlog. cheers - @gvwilson

[archmoj]

I think this could be resolved by #4643.

[wkumler]

I believe that's correct - I think that's what was decided previously and I'm encouraged to see new efforts on that issue! Happy to let this issue stay closed if it helps to have things consolidated into a single push on that side and I'll start following that issue instead.