Color mapping discontinuity in surface surfacecolor

[etpinard]

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

where odd looking line appear on the surface e.g.

I believe this issue is related to how colormap is handling custom colorscale. The colormap package is a dependency of the gl-surface3d gl-vis module.

[etpinard]

@dfcreative would you be interested in looking into this?

[dy]

@etpinard ok, sure

[rreusser]

Interesting. I've been wondering about how to do complex colormaps and ruled out this approach because of this artifact. Presumably it's because the argument loops around from 359˚ back to 0˚. My only thought is that, given two arguments θ1 and θ2, to interpolate between θ1 and θ2 + n * 360˚, for whatever n minimizes |θ1 - (θ2 + n * 360˚)|. That way it will be smart enough to know that 359˚ -> 0˚ is a small change, not a large change.

Edit: Ah, but colormap knows nothing of angles. But maybe it's the same though with the colormap parameterized, whether it loops around from 0.999 -> 0 or not.

[rreusser]

In thinking about it though, this might need to be a configuration option. Sometimes you might really just want to capture the whole colormap range between two adjacent points…

[dy]

If I get it right, the function has discontinuity in the place of "lines", in terms of linear space:

Not sure what exactly happens in gl-surface3d, but it seems to build verteces based on passed samples, connecting all the values by verteces. Therefore some verteces connect the opposite sides of that discontinuous "jump", which is proper behaviour. Therefore these samples interpolate over the whole colormap (low-res):

Possible solution to that would be avoiding verteces with discontinuities. Or detect these discontinuities somehow and take edge color for these verteces.
But it has nothing to do with colormap.

[rreusser]

Sorry to stick my nose in, but I've been trying to get a better handle on shaders. Yeah, I get it now. The definition of vertex vs fragment shaders means there's really no way to handle this without complicated preprocessing. The fragment shader would need to know about all three pre-interpolated vertex values, which, unless I'm wrong, it just doesn't. Could compute the color in the vertex shader and interpolate the color instead of the value, but that leads to different artifacts.

Here's an example that uses a geometry shader to pass the values at each vertex to the fragment shader. That would make it possible to (optionally?) detect and fix this case in the shader, except… geometry shaders.

So yeah, seems like a feature and not a bug that the colormap is applied in the fragment shader itself.

(Having only thought a little about this, I'd think the best approach would be to somehow add actual knowledge of real and imaginary parts (or modulus/argument?) so that proper color wheel, domain coloring or similar could be used—but the market for complex variables is likely very small 😞)

[rreusser]

Again, pardon my interest… last thing: Moved the colormap eval to the vertex shader instead. Works perfectly, but in general colors are then interpolated and don't necessary lie on the color wheel itself, depending on the density of the data. But does work… can't think of a way to have cake and eat it too though…

[dy]

@rreusser oh, that is nice solution, all we have to do is just to pick color in vertex shader indeed.

I’ll make a PR to gl-surface3d

[rreusser]

The only downside is that it might not always be desired. At the very least, be aware that it might not pass the existing image tests due to slight differences in the order of operations.

Like you might want a single quad to span the whole colormap gamut. With evaluation in the fragment shader you get a whole rainbow. With evaluation in the vertex shader, you get a single flat color (red at both ends?).

It might be reasonable to create a switch to opt for one or the other since short of some wild shader trickery, I don't think the choice can be avoided. I don't love the idea of low-level switches, but I just don't know how else to handle a colormap on a variable that repeats.

It feels almost like a hairy ball theorem sort of conundrum… (though I guess simple continuity is enough to explain the dilemma. I guess I sorta just wanted to find a legitimate reason to mention the theorem. 😄 )

[dy]

Ok I’ve made a PR with mode switch.

[etpinard]

@dfcreative

TODO:

• bump and npm publish gl-surface3d (you might need @mikolalysenko to get you publish rights for that)
• resolve this comment: Pick color in verteces gl-vis/gl-surface3d#8 (comment)
• add logic to src/traces/surface/convert.js
• add image test mock and baseline in test/image/

[rreusser]

Not for this since it's complex-aware and so is a bigger project, but I made a glslify shader, glsl-domain-coloring that tries to really do complex colormaps the right way. If it were possible to pass extra real/imag components, then this could conceivably be dropped in. But again, that's a bigger project.