Make surface contour levels configurable

[archmoj]

Attempt to address original ticket #485 to make surface contours adjustable and aligned with heatmap & contour trace.
In this PR contour.start, contour.end and contour.size are added and could be applied by the user to slice surface graphs on desired positions other than tick positions which is the default behaviour.

Codepen example

@plotly/plotly_js

[etpinard]

Hmm. In #485, we propose making surface contour settings on-par with the attributes for contour traces. @archmoj are your new attributes equivalent to contour's

autocontours, ncontours, contour.start, contour.end and contour.size

? If not, could you explain why your new attributes make more sense for surface traces.

[archmoj]

Hmm. In #485, we propose making surface contour settings on-par with the attributes for contour traces. @archmoj are your new attributes equivalent to contour's

autocontours, ncontours, contour.start, contour.end and contour.size

? If not, could you explain why your new attributes make more sense for surface traces.

I thought this setup could provide more flexibility so that the users can put the contours where they may need.
For example if they want them to be non-uniformly spaced, or in case of skipping one or few contours from the list, it is as simple as providing an array of desired world locations (i.e. similar to iso-surface slices).
Also in regards to @alexcjohnson's comment #485 (comment) similar options are provided for relative locations on/between grid points.

[etpinard]

I would prefer reaching parity with the attributes for contour, but I could be convinced otherwise.

[archmoj]

I would prefer reaching parity with the attributes for contour, but I could be convinced otherwise.

Would you like me to implement ncontours, contour.start, contour.end and contour.size as well?
That's relatively easy.

[alexcjohnson]

I would prefer reaching parity with the attributes for contour, but I could be convinced otherwise.

Would you like me to implement ncontours, contour.start, contour.end and contour.size as well?
That's relatively easy.

Definitely - the primary goal should be that you can take anything that works in a type: 'contour' trace, change just the type attribute to 'surface', and it still displays all the same contours.

Then at some point we can extend BOTH of these to support an array of contour values - perhaps contour.values - for the nonuniform case.

[etpinard]

Do we really need locations and relative to ✅ this feature?

I would prefer making surface on-par with contour to start.

[archmoj]

Good call. Let's put this on 1.47.0.

[archmoj]

Dropped those features in 98aebc5 as surface code is already pretty complicated for us to maintain.

[etpinard]

Have you tried re-using setContours? It probably gives similar results, but it would be nice to double-check.

[archmoj]

I tried that on a different branch. Also wanted to add autocontours and ncontours in this PR.
But unfortunately that could add too much complexity while surface contours are in 3 directions not only z.

[etpinard]

It would've been nice to bring this a bit more on-par with contour, but I guess that can wait for the regl-rewrite.

This will be a nice feature for 1.47.0 💃