[Bug] `canUseTextureMapForColoring` returns true for cell data with indexed LUT

[daker]

Bug description

canUseTextureMapForColoring in vtkMapper incorrectly returns true for cell data when an indexed lookup table is active.
The indexed lookup check is placed after the cell data shortcut that unconditionally returns true, so it is never reached.
This causes cell data + indexed LUT to take the texture mapping path, which generates NaN colors.

vtk-js/Sources/Rendering/Core/Mapper/index.js

Lines 616 to 646 in f3cfe26

	publicAPI.canUseTextureMapForColoring = (scalars, cellFlag) => {
	if (cellFlag && !(model.colorMode === ColorMode.DIRECT_SCALARS)) {
	return true; // cell data always use textures.
	}
	if (!model.interpolateScalarsBeforeMapping) {
	return false; // user doesn't want us to use texture maps at all.
	}
	// index color does not use textures
	if (model.lookupTable && model.lookupTable.getIndexedLookup()) {
	return false;
	}
	if (!scalars) {
	// no scalars on this dataset, we don't care if texture is used at all.
	return false;
	}
	if (
	(model.colorMode === ColorMode.DEFAULT &&
	scalars.getDataType() === VtkDataTypes.UNSIGNED_CHAR) ||
	model.colorMode === ColorMode.DIRECT_SCALARS
	) {
	// Don't use texture is direct coloring using RGB unsigned chars is
	// requested.
	return false;
	}
	return true;
	};

Steps to reproduce

import vtkMapper from "@kitware/vtk.js/Rendering/Core/Mapper";
import vtkLookupTable from "@kitware/vtk.js/Common/Core/LookupTable";
import vtkPolyData from "@kitware/vtk.js/Common/DataModel/PolyData";
import vtkDataArray from "@kitware/vtk.js/Common/Core/DataArray";
import {
  ColorMode,
  ScalarMode,
} from "@kitware/vtk.js/Rendering/Core/Mapper/Constants";

const polydata = vtkPolyData.newInstance();

polydata
  .getCellData()
  .setScalars(
    vtkDataArray.newInstance({
      name: "Categories",
      values: new Uint8Array([0, 1, 2, 3, 0, 1]),
    })
  );

const lut = vtkLookupTable.newInstance();
lut.setNumberOfColors(4);
lut.build();
lut.setIndexedLookup(true);
lut.setAnnotations(["0", "1", "2", "3"], ["Cat0", "Cat1", "Cat2", "Cat3"]);

const mapper = vtkMapper.newInstance({
  scalarMode: ScalarMode.USE_CELL_DATA,
  colorMode: ColorMode.MAP_SCALARS,
});
mapper.setInputData(polydata);
mapper.setLookupTable(lut);

mapper.mapScalars(polydata, 1.0);

console.log(mapper.getColorMapColors()); // BUG: null (texture path nulled it)
console.log(mapper.getColorTextureMap()); // BUG: non null (texture was created)

Detailed Behavior

• canUseTextureMapForColoring returns true (cell data shortcut fires first)
• mapScalarsToTexture is called, which:
  1. Sets colorMapColors = null
  2. Creates a texture from a ramp of float values mapped through the LUT
  3. Since indexed LUT is active, the float ramp values don't match any annotation strings which returns NaN color.

Expected Behavior

// Expected output:
console.log(mapper.getColorMapColors()); // non null
console.log(mapper.getColorTextureMap()); // null

Environment

• vtk.js version:
• Browsers:
• OS:

[daker]

@bruyeret i traced this issue to your commit 3054982 is my finding valid ?

[bruyeret]

The idea of this commit was for the following use case:

• we have scalar values per cell
• we associate a color to each scalar with a LUT
• we often want to change the LUT (for example by moving the range of the LUT with a slider)

What was done before my commit: the whole VBO contained the colors for each cell and was re-uploaded to the GPU, with a new color for each cell (which can be super heavy).

The solution of my commit: put the scalar values in the VBO (instead of the colors) and use the LUT directly in the shader when rendering. Changing the LUT is a lot less heavy a can be done in real time. The performance cost to render a frame is almost nothing but the gain to update the LUT in real time are not negligible.

I may have lost the context since I have not contributed for a while, but if the rendering is broken I think that the solution is to fix how the LUT is sent to the GPU instead of changing this flag.

Edit: from the PR containing my commit I see that the scalars are not sent, but the coordinates in the texture are sent, which makes my example with the slider wrong. But when keeping the range of the LUT, my conclusion still holds (changing the flag may cause a regression).

[finetjul]

@daker are you experimenting the problem with WebGL AND WebGPU or just with WebGPU ?

[daker]

@finetjul I am testing on both(side by side), do you have a specific test/example use to valide this?

[finetjul]

The example @bruyeret used was the GeometryViewer example. You can try it with a polydata mesh with point and cell data.