3D streamtube traces #2658

etpinard · 2018-05-23T22:15:47Z

Note that this branch is @kig 's https://github.com/plotly/plotly.js/tree/gl-vis-streamtube rebased with the 2018/05/28 master.

Streamtubes are coming to plotly.js, this time for real (#701 😏 )

But first, we'll need to bring this branch up-to-speed with the work done for cones in #2641 ⚒️

Here's a list of TODOs:

cc @alexcjohnson @jackparmer @kig

- reuse cone colorbar - compute x/y/z bounds in calc - pass cmin/cmax to meshData.vertexIntensityBounds - rename starting position attributes cx/cy/cz -> startx/starty/startz - misc cleanup to bring streamtube closer to cone - add new TODOs

etpinard · 2018-05-25T14:50:38Z

Update:

Here's a few problems I noticed yesterday:

gl-streamtube3d exposes a meshgrid attribute that "samples" (i.e. downscales) the vector field about the cartesian product of arrays of x,y,z coordinates. But now, @kig how can users specify the vector field's own x,y,z coordinates (like what the positions setting does for gl-cone3d)?

From 812be20#r29129877, gl-streambed3d's widthScale setting has a hard-coded default that does a very poor job in some cases. 🆘 We must fix this before the v1 release. 🆘 I think @kig will be taking this one.

On-par with cone traces, the colorscale's cmin and cmax auto value are computed using the u/v/w max vector norm. For cones, this turns out to be exactly the span of color values displayed, but for streamtubes cmin-cmax overestimate the span of color values displayed, as the tubes aren't drawn at the vector field coordinates. So, should we compute the max vector norm at the tubes' location to determine cmin and cmax? I can see an argument for both methods. Computing cmin/cmax just from u/v/w is probably more "true to the data" whereas computing cmin/cmax from the vector field interpolated to the tubes' locations will give better aesthetically-pleasing results.

As for hover, it's an interesting problem. I'm thinking of three families of solution. 1) Just show the vector field x/y/z and u/v/w pt values just like for cones. This solution is true to the input data, but doesn't offer info about the tubes. 2) Just show the coordinates of the tubes' vertices and the u/v/w components at their location. Here, we're entirely in "tube-space", the input x/y/z and u/v/w don't show up on hover. 3) Show the tubes' starting position (i.e. items from startx, starty and startz) and the tubes' center coordinates plus (optionally) the scalar velocity at the tubes' center. When hovering over a section of a tube, it seems useful to me to know where that tracer started from.

Thoughts?

alexcjohnson · 2018-05-25T15:42:53Z

Computing cmin/cmax just from u/v/w is probably more "true to the data" whereas computing cmin/cmax from the vector field interpolated to the tubes' locations will give better aesthetically-pleasing results.

"True to the data" is my preference here - it shows you a bit of what you've missed about the data by converting to tubes. It shouldn't often be very far off the interpolated values, right?

As for hover, it's an interesting problem.

Interesting indeed - I actually think "true to the data" would be really confusing here, as there's nothing to "hover on" at the data point. Particularly since this is 3D, you could end up hovering on something at a totally different depth from the tube you're inspecting. The tube vertices (2) don't mean anything. I assume when you say this you're talking about the surface of the tube? I'm thinking the ideal solution (tell me how painful this would be to calculate...) would be to find the exact tube surface point the cursor is over (not the closest vertex) and project from there back to the centerline of the tube; show x/y/z and u/v/w/norm for that point (or perhaps the closest actual data point? that could be confusing though); and perhaps somehow highlight the whole tube, so you can see not just where it came from but the whole streamline? That last part seems more like a "nice to have" that we could add later though.

etpinard · 2018-05-25T15:58:42Z

"True to the data" is my preference here

Fantastic 👌

I assume when you say this you're talking about the surface of the tube?

Yes, exactly.

I'm thinking the ideal solution (tell me how painful this would be to calculate...) would be to find the exact tube surface point the cursor is over (not the closest vertex) and project from there back to the centerline of the tube; show x/y/z and u/v/w/norm for that point

I agree, this sounds like ideal. I'll have to dig into how the tubes coordinates are computed to answer the "how painful this would be" question. Maybe @kig would be interested in helping us out?

kig · 2018-05-29T14:39:33Z

gl-streamtube3d exposes a meshgrid attribute that "samples" (i.e. downscales) the vector field about the cartesian product of arrays of x,y,z coordinates. But now, @kig how can users specify the vector field's own x,y,z coordinates (like what the positions setting does for gl-cone3d)?

The streamtube visualization needs a continuous vector field. It works by sampling the vector field at each of the starting points, then moving a small amount along the sampled vector, sampling again, moving again, repeat until far enough from the starting point to create a stream segment. Push stream segment to the stream points array, continue until out of bounds or reach maxLength segments in stream points array.

The meshgrid parameter defines the vector field for the streamtubes. It maps each of the vectors to a position in space. And since it's a nicely defined grid, it's easy to sample values inside each grid cell by interpolating between the 8 corners of the cell according to the sample position.

Doing arbitrary vector positions for the vector field would be doable if you've got some nice algorithm to sample them as a continuous vector field.

Re: widthScale, auto scale, I wrote an auto scaler this morning. gl-vis/gl-streamtube3d@97c89d7 -- it also removes the widthScale parameter and replaces it with tubeSize and absoluteTubeSize params.

The auto scaler keeps track of the maximum divergence value encountered and uses that to calculate the radius of the tubes. The tubeSize param controls the auto scaled width so that tubeSize of 1 would scale two max divergence tubes at adjacent starting positions so that they don't overlap.

The absoluteTubeSize param overrides the auto scaler, and is used to multiply the divergence value to get the tube radius in coordinate space units.

The divergence used for the streamtubes is || divF || instead of the divF 3-vector. I don't know if that's the right thing to do or if we should scale the tubes in a non-uniform fashion according to the 3D divergence.

I'm thinking the ideal solution (tell me how painful this would be to calculate...) would be to find the exact tube surface point the cursor is over (not the closest vertex) and project from there back to the centerline of the tube; show x/y/z and u/v/w/norm for that point

This sounds doable, the tubes definition contains all the sampled interpolated data points, and picking should get you the triangle & data point matching that. What would you need for this?

etpinard · 2018-05-29T15:44:54Z

Re: widthScale, auto scale, I wrote an auto scaler this morning. gl-vis/gl-streamtube3d@97c89d7 -- it also removes the widthScale parameter and replaces it with tubeSize and absoluteTubeSize params.

Thanks @kig ! I'll try to incorporate your work in this PR in the next few hours.

@kig

... using @kig's work from gl-vis/gl-streamtube3d#3

etpinard · 2018-05-29T21:06:07Z

The streamtube visualization needs a continuous vector field.
The meshgrid parameter defines the vector field for the streamtubes. It maps each of the vectors to a position in space. And since it's a nicely defined grid, it's easy to sample values inside each grid cell by interpolating between the 8 corners of the cell according to the sample position.

Thanks for writing this down @kig . You're absolutely right, the "mesh" requirements for streamtubes are much more stringent than for cones. Too bad x/y/z will have a slightly different meaning in streamtube vs in cone traces, but I think we can live with that.

Having x/y/z generate of "mesh" of x.length * y.length * z.length items using a cartesian product and requiring u/v/w to be of length x.length * y.length * z.length isn't the most plotly.js-esque API unfortunately. I guess we could make u/v/w 3D arrays. This would be a first though, and I doubt that's better. Perhaps requiring x/y/z to list all coordinates (so that x/y/z and u/v/w would have matching lengths) would be best albeit (way) less efficient. For example,

var x = [], y = [], z = [];
var u = [], v = [], w = [];

for(var i = 0; i < nx; i++) {
  for(var j = 0; j < ny; j++) {
    for(var k = 0; k < nz; k++) {
      x.push(i); y.push(j); z.push(k);

      u.push(1+Math.sin(i));
      v.push(Math.cos(j));
      w.push(Math.sin(k*0.3)*0.3);
    }
  }
}

alexcjohnson · 2018-05-29T23:24:54Z

Perhaps requiring x/y/z to list all coordinates (so that x/y/z and u/v/w would have matching lengths) would be best albeit (way) less efficient.

It's not way less efficient - x/y/z are way bigger, but the trace as a whole is only twice as big. I think we should require this form (x/y/z/u/v/w all the same length) as the default. We can extend this with some non-default option that lets users specify the more efficient x/y/z (either with 3D or 1D u/v/w arrays, we can discuss that later), but then we can also handle arbitrary sample points in the future, either by pre-interpolating like in convert_column_xyz and interp2d or some Delaunay-like algorithm. And it'll ensure users can switch between streamtube and cone relatively robustly. Then we could fill in all the corresponding gaps in cone data handling as well.

etpinard · 2018-05-30T13:05:21Z

And it'll ensure users can switch between streamtube and cone relatively robustly. Then we could fill in all the corresponding gaps in cone data handling as well.

This is winning argument 🏆 . @kig would you be interested in converting the gl-streambed3d meshgrid argument to x/y/z positions?

kig · 2018-05-31T08:12:44Z

By converting the meshgrid argument to x/y/z positions, do you mean that it'd be like an "expanded" meshgrid? You'd have the same x coordinates for every y and the same y coords for every z, and they'd be sorted small to big?

For example,

var x = [0,1,2,0,1,2,0,1,2,0,1,2],
    y = [4,4,4,5,5,5,4,4,4,5,5,5],
    z = [6,6,6,6,6,6,7,7,7,7,7,7];

var uniq = function(arr, e) {
  if (arr.length === 0 || e > arr[arr.length-1]) {
    arr.push(e);
  }
  return arr; 
};

var meshgrid = [x.reduce(uniq, []), y.reduce(uniq, []), z.reduce(uniq, [])];
=> [ [0,1,2], [4,5], [6,7] ]

kig · 2018-05-31T09:16:46Z

Btw the cone meshgrid argument works in a similar fashion. It interprets the vector array as a vector field, and then uses the cone positions as points to sample from the vector field.

... with the help of gl-vis/gl-streamtube3d#5

- which makes x/y/z and u/v/w streamtube data interchangeable with cone traces - convert x/y/z columns to gl-streamtube "meshgrid" using Lib.distinctVals - add pad around tube x/y/z bounds to allow them to go a little bit beyond the mesh w/o getting clipped.

etpinard · 2018-06-01T17:01:09Z

it'd be like an "expanded" meshgrid? You'd have the same x coordinates for every y and the same y coords for every z, and they'd be sorted small to big?

Yes, exactly. Commit e99ffc9 adds a x/y/z columns -> meshgrid vector converter in plotly.js before calling tube2mesh.

It interprets the vector array as a vector field, and then uses the cone positions as points to sample from the vector field.

We chose to not expose gl-cone3d's "meshgrid" setting to plotly.js users in 5a42de0. In this context, (if I understand correctly), gl-cone3d assumes that the x/y/z positions and u/v/w vectors input match. So now, plotly users using the same x/y/z and u/v/w columns can plot streamtube and cone traces with no array additional array manipulations.

etpinard · 2018-06-05T21:04:13Z

I also notice that when multiple tubes come together and overlap we don't do anything to stop this, for example this set of 3 near the one I flag ^^ that spend most of their length conjoined. Is that a normal way of handling things? Not what I would have expected comparing these to 2D streamline plots, for example, where a line usually disappears when it gets too close to another.

cc @kig

or goes on forever?

gl-streamtube3d has a maxLength (mapped to maxdisplayed in plotly.js) which sets the maximum number of segments per tube. The default is 1000 segments. So don't worry about tubes that go on forever.

alexcjohnson · 2018-06-05T22:56:13Z

src/traces/streamtube/convert.js

+        } else {
+            // use all pts on 2x2 and 1x1 planes
+            sx = valsx.slice();
+            sz = valsz.slice();


Presumably this length > 2 condition should be done separately for x and z? Also, I don't know what model is used for extending the field outside the x/y/z bounds, but if it's uncertain enough that at 3+ points it's best not to start at the last coordinate, then I'd think at 2 points it'd be best to use a single point halfway between the two.

Also, I don't know what model is used for extending the field outside the x/y/z bounds

Currently, positions outside the mesh get (u=0, v=0, w=0) if I understand correctly:

https://github.com/gl-vis/gl-streamtube3d/blob/0359ed9696de5af570fa6a5e36bdfbca2013220b/streamtube.js#L228-L231

cc @kig

New attempt in 83f3bdc

alexcjohnson · 2018-06-05T23:03:33Z

src/traces/streamtube/index.js

+        // Does not correspond to input x/y/z, so delete them
+        delete out.x;
+        delete out.y;
+        delete out.z;


kig · 2018-06-07T16:37:34Z

I also notice that when multiple tubes come together and overlap we don't do anything to stop this, for example this set of 3 near the one I flag ^^ that spend most of their length conjoined. Is that a normal way of handling things? Not what I would have expected comparing these to 2D streamline plots, for example, where a line usually disappears when it gets too close to another.

This could be done in a post processing pass, checking if any two points have a distance below an epsilon -> throw away the shorter stream suffix. As it is, the stream generator just generates a stream from each starting point and draws them all out.

- to not have to .slice input array twice

... mesh3d, surface and streamtube attribute declarations.

etpinard · 2018-06-19T15:09:39Z

@alexcjohnson are any of your remarks in #2658 (comment) blocking for a v1 release?

@kig would you be interested in looking at the broken tube @alexcjohnson noticed in gl3d_streamtube-first ?

etpinard · 2018-06-19T15:11:59Z

src/traces/cone/attributes.js

-extendFlat(attrs, colorAttrs('', 'calc', true), {
-    showscale: colorscaleAttrs.showscale,
+extendFlat(attrs, colorscaleAttrs('', {
+    colorAttr: 'u/v/w norm',


This give better attribute descriptions for cone colorscale and friends. For example, for cmin we have

"Sets the lower bound of the color domain. Value should have the same units as the u/v/w norm and if set, cmax must be set as well."

alexcjohnson · 2018-06-19T18:15:15Z

are any of your remarks in #2658 (comment) blocking for a v1 release?

Just the broken tube - if there's a benign explanation for it then fine, I'd just like us to make sure we're not setting ourselves up for breaks in some broad class of conditions we haven't fully explored yet.

etpinard · 2018-06-26T20:24:27Z

More on the broken tube of #2658 (comment),

At sizeref: 0.2 we have:

which looks like one (very) narrow but not broken section.

the same view at sizeref: 0.1 is:

where many tubes are overlapping.

kig · 2018-06-30T13:09:22Z

Right, two ideas of what might be causing this.

The coordinate system generated based on the velocity vector is not continuous, so when a stream passes through a discontinuous angle, the coordinate axes suddenly change, which would cause a >< kink in the tube.

Alternative explanation: the divergence function returns a zero for some reason.

alexcjohnson · 2018-07-03T20:06:42Z

Looking at that point again - I can confirm that it's not broken, it does all seem to connect ala pinched sausage links. But we're off the edge of the data here, the largest x in the data is 4 and we're almost at x=5 here. So I'm not sure what extrapolation is going on but I can't imagine it would take what looks like a fairly large and stable divergence and take it through zero before coming back out to essentially the same magnitude at the next point. Is there any chance it's taking two neighboring rings and rather than connecting them directly, it's connecting them inverted? Meaning it's making a mesh that connects points at the top of the tube on the first ring to points at the bottom of the next ring, and so on? I feel like I see some tight folding that makes it look like a wrapped present, which seems like it could happen with an inversion scenario like that:

etpinard · 2018-07-05T14:06:50Z

Ok merging this thing.

Go to #2781 for a list of open items.

kig · 2018-08-02T11:43:23Z

Is there any chance it's taking two neighboring rings and rather than connecting them directly, it's connecting them inverted?

Yeah, that's probably what happens. At some angles, the coordinate system generated from only the velocity vector suddenly swaps its axes. I can fix it by also sending the previous velocity vector, then the shader could compare the coordinate systems to avoid sudden swaps. Or do it in JS and pass up vectors to the shader.

kig and others added 4 commits May 23, 2018 16:29

streamtube integration, first pass

616d043

add gl-streamtube to package.json

2435a96

add gl-streamtube3d to package-lock

355aed1

use gl-streamtube3d version that works on etpinard's laptop

583499f

etpinard added feature something new status: in progress labels May 23, 2018

etpinard added this to the v1.39.0 milestone May 23, 2018

etpinard added 5 commits May 24, 2018 18:15

cleanup streamtube/

39c254e

- reuse cone colorbar - compute x/y/z bounds in calc - pass cmin/cmax to meshData.vertexIntensityBounds - rename starting position attributes cx/cy/cz -> startx/starty/startz - misc cleanup to bring streamtube closer to cone - add new TODOs

add first streamtube mock

38a1310

properly scaffold streamtube trace module

971351c

factor out zip3 into src/lib/

218dfc8

Merge branch 'master' into streamtube-traces

1367c07

etpinard referenced this pull request May 25, 2018

streamline integration, first pass

812be20

etpinard added 2 commits May 29, 2018 14:12

add 'sizeref'

8ea0c25

... using @kig's work from gl-vis/gl-streamtube3d#3

fixup streamtube-thin baseline

3b1f809

etpinard mentioned this pull request May 29, 2018

Tubes disappear when meshgrid is too fine gl-vis/gl-streamtube3d#4

Open

etpinard added 2 commits June 1, 2018 10:39

fixup cmin/cmax -> vertexIntensityBounds,

b0cd99d

... with the help of gl-vis/gl-streamtube3d#5

first cut streamtube hover

e0ff37f

alexcjohnson reviewed Jun 5, 2018

View reviewed changes

alexcjohnson and others added 4 commits June 5, 2018 19:13

typos in streamtube meta

ca7c022

fixup hoverinfo: 'all' for cone traces

9a53250

sub startx/starty/startz -> starts.(x|y|z)

22f0c7e

fixup 'starts' attribute declaration

d796bda

etpinard added 2 commits June 12, 2018 10:16

Merge branch 'master' into streamtube-traces

2d1df2b

fixup streamtube after merge master

0093ac8

jackparmer mentioned this pull request Jun 12, 2018

3D Support for Streamline/Quiver Plots plotly/plotly.py#861

Closed

etpinard added 5 commits June 18, 2018 11:40

mv lib/zip3 -> plots/gl3d/zip3

5c2ddfc

add 'len' argument to zip3

9fa5ece

- to not have to .slice input array twice

merge all colorscale attribute generator in one function

d33fc45

fix #2723 - list correct 'color' attribute in cone,

9e3c533

... mesh3d, surface and streamtube attribute declarations.

improve auto starting position algo

83f3bdc

etpinard commented Jun 19, 2018

View reviewed changes

etpinard mentioned this pull request Jun 26, 2018

Isosurface traces #2752

Closed

5 tasks

etpinard mentioned this pull request Jul 5, 2018

Streamtube open items #2781

Closed

4 tasks

etpinard added 2 commits July 5, 2018 09:49

Merge branch 'master' into streamtube-traces

f348ac3

use [email protected]

966bc8d

etpinard merged commit 9698e78 into master Jul 5, 2018

etpinard deleted the streamtube-traces branch July 5, 2018 14:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

3D streamtube traces #2658

3D streamtube traces #2658

etpinard commented May 23, 2018 •

edited

Loading

etpinard commented May 25, 2018

alexcjohnson commented May 25, 2018

etpinard commented May 25, 2018

kig commented May 29, 2018 •

edited

Loading

etpinard commented May 29, 2018

etpinard commented May 29, 2018 •

edited

Loading

alexcjohnson commented May 29, 2018

etpinard commented May 30, 2018 •

edited

Loading

kig commented May 31, 2018

kig commented May 31, 2018

etpinard commented Jun 1, 2018 •

edited

Loading

etpinard commented Jun 5, 2018

alexcjohnson Jun 5, 2018

etpinard Jun 19, 2018

etpinard Jun 19, 2018

alexcjohnson Jun 5, 2018

kig commented Jun 7, 2018

etpinard commented Jun 19, 2018

etpinard Jun 19, 2018

alexcjohnson commented Jun 19, 2018

etpinard commented Jun 26, 2018

kig commented Jun 30, 2018

alexcjohnson commented Jul 3, 2018

etpinard commented Jul 5, 2018

kig commented Aug 2, 2018

3D streamtube traces #2658

3D streamtube traces #2658

Conversation

etpinard commented May 23, 2018 • edited Loading

etpinard commented May 25, 2018

alexcjohnson commented May 25, 2018

etpinard commented May 25, 2018

kig commented May 29, 2018 • edited Loading

etpinard commented May 29, 2018

etpinard commented May 29, 2018 • edited Loading

alexcjohnson commented May 29, 2018

etpinard commented May 30, 2018 • edited Loading

kig commented May 31, 2018

kig commented May 31, 2018

etpinard commented Jun 1, 2018 • edited Loading

etpinard commented Jun 5, 2018

alexcjohnson Jun 5, 2018

Choose a reason for hiding this comment

etpinard Jun 19, 2018

Choose a reason for hiding this comment

etpinard Jun 19, 2018

Choose a reason for hiding this comment

alexcjohnson Jun 5, 2018

Choose a reason for hiding this comment

kig commented Jun 7, 2018

etpinard commented Jun 19, 2018

etpinard Jun 19, 2018

Choose a reason for hiding this comment

alexcjohnson commented Jun 19, 2018

etpinard commented Jun 26, 2018

kig commented Jun 30, 2018

alexcjohnson commented Jul 3, 2018

etpinard commented Jul 5, 2018

kig commented Aug 2, 2018

etpinard commented May 23, 2018 •

edited

Loading

kig commented May 29, 2018 •

edited

Loading

etpinard commented May 29, 2018 •

edited

Loading

etpinard commented May 30, 2018 •

edited

Loading

etpinard commented Jun 1, 2018 •

edited

Loading