Texture: Support update ranges with other formats than RGBA.

[rotu]

Description

Creating a non-RGBA texture and using the partial texture update via addUpdateRange doesn't update the intended part of the texture.

Reproduction steps

See fiddle https://jsfiddle.net/vx3u16zj/2/

Code

  const width = 8;
  const height = 8;
  const data = new Float32Array(width * height);
  for (let i = 0; i < data.length; ++i) {
    data[i] = i / data.length;
  }
  const dataTexture = new THREE.DataTexture(data, width, height);
  dataTexture.format = THREE.RedFormat;
  dataTexture.type = THREE.FloatType;
  dataTexture.internalFormat = 'RED32F';
  dataTexture.needsUpdate = true;


  setTimeout(() => {
    data.fill(0);
    // this should update the 12 texels starting at #32
    // instead it updates the 3 texels starting at #8
    dataTexture.addUpdateRange(32, 12);
    dataTexture.needsUpdate = true;
  }, 1000);

Live example

https://jsfiddle.net/vx3u16zj/2/

Screenshots

Version

0.181.2

Device

No response

Browser

No response

OS

No response

[Mugen87]

This is a known limitation. It's because of this line:

three.js/src/renderers/webgl/WebGLTextures.js

Line 759 in 56fc856

const componentStride = 4; // only RGBA supported

We should update the documentation of Texture.addUpdateRange() to make that clear.

If I change the componentStride to 1 to support RedFormat, I get this warning:

GL_INVALID_OPERATION : glTexSubImage2D: invalid unpack params combination

[agargaro]

The logic of texture.updateRange has a problem anyway that I'm trying to fix here (only WebGLTextures.js), but the fix needs to be improved.

[rotu]

This is a known limitation. It's because of this line … We should update the documentation of Texture.addUpdateRange() to make that clear

I thought that might be the culprit. The docs should mention what the unit of the offset and length are (e.g. bytes/texels/typed array elements).

If I change the componentStride to 1 to support RedFormat, I get this warning

I think that warning is telling us that the given line is not the only place that embeds this assumption. Maybe it’s missing a pixelStorei(… UNPACK_ALIGNMENT) or somesuch?