Improve unstepped contours mapping of color and range #1079
Conversation
For stepped data, the range values need to have one more entry than the color values, since the range values define the divisions where colors change. For non-stepped data, we were still asking for one more range entry than color entry, but the final range entry was not used. Allow a one-to-one mapping for non-stepped data, as this is more obvious.
| @@ -63,7 +64,8 @@ var meshFeature = require('./meshFeature'); | |||
| * @property {number[]} [rangeValues] An array used to map values to the | |||
| * `colorRange`. By default, values are spaced linearly. If specified, the | |||
| * entries must be increasing weakly monotonic, and there must be one more | |||
| * entry then the length of `colorRange`. | |||
| * entry then the length of `colorRange` if the contour is stepped, or the | |||
There was a problem hiding this comment.
stepped or unstepped may not be obvious to some, should we also add "continuous" and "discreet"
There was a problem hiding this comment.
Should we just change the documentation, or do you think we should allow multiple names for the parameter, too?
There was a problem hiding this comment.
for the backward compatibility, adding multiple names for the parameters makes sense to me.
There was a problem hiding this comment.
Okay -- let's do that in a separate PR.
| @@ -25,7 +25,7 @@ void main () { | |||
| step = steps - 0.5; | |||
| } | |||
| } else { | |||
| step = valueVar; | |||
| step = valueVar + 0.5; | |||
There was a problem hiding this comment.
what is 0.5 added to the valueVar? I did not look at the complete code
There was a problem hiding this comment.
is valueVar range values or values?
There was a problem hiding this comment.
I should have documented this better as a bug fix and not directly related to the rest of the PR. Specifically, we have a small texture which is the color map of the colors for the normalized range values. The color of the fragment is interpolated from the texture. Without the + 0.5, it was picking the wrong color: with + 0.5 an integer value will be centered in texture's pixel coordinate and therefore that exact color. In our examples, this is a relatively subtle shift. You can construct an example where it is more obvious (for instance, a two color range where a lot of the values are at the high and low values would have shown some areas as halfway between the two colors instead of exactly at one of them).
For stepped data, the range values need to have one more entry than the color values, since the range values define the divisions where colors change. For non-stepped data, we were still asking for one more range entry than color entry, but the final range entry was not used. Allow a one-to-one mapping for non-stepped data, as this is more obvious.