chore(ClipClosedSurface): fix surface colors not showing

[Jo-Byr]

Context

Surface colors are incorrect in ClipClosedSurface example

Results

The sphere and plane colors are now correct.

Changes

Added mapper.setColorModeToDirectScalars(); in the example to use the scalars set by the filter.

• semantic-release commit messages
• Run npm run reformat to have correctly formatted code

[daker]

LGTM

[finetjul]

Can you please explain why changing to direct scalar mode fixes the problem? Could it be the active attribute field that is not correctly set?

[Jo-Byr]

Can you please explain why changing to direct scalar mode fixes the problem? Could it be the active attribute field that is not correctly set?

From my understanding, it's necessary because we set the colors as the scalars directly, rather than use a lookuptable.

[daker]

@Jo-Byr There is a bug related to this i think #2574 ?

[Jo-Byr]

To be more complete:

There's 2 coloring modes: colors and labels

If we are in color mode, we can have only 3 colors: base, clip and active. The example didn't use the colors correctly because we didn't tell the mapper to use the scalars as colors directly, so it tried to use the colors as scalars, reading their first component as a float scalar resulting in the binary blue/red we saw due to saturation of the default lut that maps from 0 to 1 (colors are in uint8 so we could only get both ends).

In label mode, we have the same issue if we don't change the LUT because the filter uses labels 0, 1 and 2 arbitrarily without allowing to change these values:

if (model.scalarMode === ScalarMode.COLORS) {
  numberOfScalarComponents = 3;
  createColorValues(
    model.baseColor,
    model.clipColor,
    model.activePlaneColor,
    colors
  );
} else if (model.scalarMode === ScalarMode.LABELS) {
  colors[0][0] = 0;
  colors[1][0] = 1;
  colors[2][0] = 2;
}

So if we want to be able to still show scalars, we would need to be able to use default scalars instead of this overwrite for "base" right ?