Volume3d iso

[archmoj]

Supersedes #2753
Volume-3d visualisation for Plotly.

Please use this demo to test it in your browser.
@plotly/plotly_js @jackparmer

[etpinard]

Nice!

Could you elaborate on why you chose to not add a new trace type?

[archmoj]

@etpinard Thanks for the note.
This way it may be easier to maintain. But yeah we could do that. And it would inherit good amount of code from iso-surface and add opacity to various layers.

[alexcjohnson]

@archmoj this is really interesting, not that I've played with volumetric data very much but I don't think I've ever seen it presented quite like this. It seems like a very smooth and rich display. I'd be curious to get it in the hands of people who DO have real uses for it (@jackparmer is there anyone specific who's been asking for this?) to get some feedback.

I guess looking at how it's constructed - seems like there is a series of isosurfaces, as well as some sort of surfaces throughout the rest of the volume though I can't quite tell what shapes they're making - I can see why you built this into isosurface rather than making a new trace. Kind of like how our scatter encompasses line and area charts... a bit unfortunate, might have been better in retrospect to call it volume or something, but that's moot at this point.

I see you can still use isomin and isomax, which is very cool - but one feature of #2753 that I thought was going to be quite useful is opacityscale - so you could choose to give more opacity to high data, or low data, or both extremes... different data sets could be better served by different scales.

It doesn't seem like there's any sense of depth order in this rendering, am I understanding that correctly? I can get a sense of where a feature is while rotating it, but if for example I set an orientation with one of the red blobs near the front and the other near the back, they look about the same. I know that's a long-standing issue with our 3D surfaces, but it really becomes prominent here. For all its problems, displaying a set of stacked planes seemed to do that reasonably well. Here's what I see if I set isomin: 1000 in your demo:

It seems like to first order what you see at any given pixel is the highest value along that ray, despite the fact that there is quite a lot of volume at lower values in the near-horizontal blob that's entirely in front of the more vertical blob. And it's not just because the near-horizontal one is a smaller volume, the same thing happens if I reverse their order. But that brings up another point, that I'm not sure this is accurately depicting how much volume is occupied by a given value; shouldn't the smaller-volume feature appear less opaque? That's true even if I reduce the opacity so I can clearly see through each volume. I guess what's going on is each isosurface contributes the same opacity, even if they're layered very closely together and so represent very different volumes?

[jackparmer]

is there anyone specific who's been asking for this?) to get some feedback.

Really just trying to keep up with ipyvolume:

https://github.com/maartenbreddels/ipyvolume#volume-rendering

[archmoj]

Thanks @alexcjohnson for the great feedback. I would definitely try to keep those details in mind when we could rewrite new shaders for mesh3d.
Would you mind testing this new prototype? Now that all the layers contribute in the image and something was fixed in new gl-mesh3d module, it produced renders like this:

[archmoj]

Also here is another prototype by implementing opacityscale in gl-mesh3d.

[archmoj]

This new codepen is based on a new trace type: volume-4d.
Which could be used to create things like this:

[archmoj]

Now in #3488