Possible issue: missing coordinates during cross-dimensional rendering (since 3.66?)

Troubleshooting
1

  • Pixelblaze 3.66 added 1D maps and expanded render-function fallback so patterns can run even when the map and available render function have different dimensions.

  • The 3.66 release notes say that when the selected render function requires coordinates the map does not provide, the missing coordinates default to the middle of world space—0.5.

  • I am seeing different behavior when a lower-dimensional map is used with a higher-dimensional render function. The missing arguments appear to contain coordinates belonging to following LEDs.

  • This only affects the “up-rendering” situation where the function requires more coordinates than the map supplies. Exact-dimensional matches appear to work normally.

Case 1: render3D() with a 2D map

A 2D map supplies x and y, while render3D() requires x, y, and z. I therefore expect the missing z to be 0.5.

I used this 2D map:

function(pixelCount) {
  var map = []

  for (var i = 0; i < pixelCount; i++) {
    map.push([i / (pixelCount - 1), i % 2])
  }

  return map
}

And this pattern:

export var observedZ

export function render3D(index, x, y, z) {
  if (index == 1) observedZ = z // value is next pixel's x; should be 0.5
  hsv(0, 0, 0)
}

For pixel index 1:

Expected z: 0.5
Observed z: 0.007843

0.007843 is approximately 2 / 255, which is the x coordinate belonging to pixel index 2—the following LED.

Case 2: render3D() with a 1D map

A 1D map supplies only x, while render3D() requires x, y, and z. I therefore expect both missing values, y and z, to be 0.5.

I used this reversed 1D map:

function(pixelCount) {
  var map = []

  for (var i = 0; i < pixelCount; i++) {
    map.push([1 - i / (pixelCount - 1)])
  }

  return map
}

And this pattern:

export var observedY, observedZ

export function render3D(index, x, y, z) {
  if (index == 1) {
    observedY = y // value is next pixel's x; should be 0.5
    observedZ = z // value is following pixel's x; should be 0.5
  }
  hsv(0, 0, 0)
}

For pixel index 1:

Expected y: 0.5
Expected z: 0.5

Observed y: 0.992142
Observed z: 0.988220

Those observed values correspond, within fixed-point quantization, to the mapped x coordinates for pixel indexes 2 and 3.

Scope of the behavior

This does not appear to be a general mapping or render-selection problem.

These cases worked as expected:

  • A 2D map selected render2D() when the pattern defined it.

  • A 3D map successfully used a pattern defining only render2D().

  • A 3D map successfully used render(index, x), with x coming from the 3D map.

The unexpected values appear specifically when the chosen render function needs more coordinates than the map contains:

2D map → render3D()  needs a synthesized z
1D map → render2D()  needs a synthesized y
1D map → render3D()  needs synthesized y and z

Test context

  • Device: Pixelblaze V3 Standard (pb32)

  • Firmware: 3.67

  • Pixel count: 256

  • Map point count: 256

  • Reproduced with both a temporary map upload and a saved map

  • Map encoding was checked against the format used by ZRanger’s pixelblaze-client

The relevant 3.66 release notes say:

Missing coordinates default to the middle of world space.

Is 0.5 still the intended value for these missing coordinates? If so, could the renderer be reading onward into the following map entries instead of supplying the missing values?