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

**URL:** <https://forum.electromage.com/t/possible-issue-missing-coordinates-during-cross-dimensional-rendering-since-3-66/4716>\
**Category:** Troubleshooting\
**Created:** [July 10, 2026, 7:30pm UTC](https://forum.electromage.com/t/possible-issue-missing-coordinates-during-cross-dimensional-rendering-since-3-66/4716 "2026-07-10T19:30:29Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![captainCat](https://forum.electromage.com/user_avatar/forum.electromage.com/captaincat/32/4087_2.png) [@captainCat](https://forum.electromage.com/u/captainCat)\
**Post date:** [July 10, 2026, 7:30pm UTC](https://forum.electromage.com/t/possible-issue-missing-coordinates-during-cross-dimensional-rendering-since-3-66/4716/1 "2026-07-10T19:30:29Z")

</div>

- 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:

```auto
function(pixelCount) {
  var map = []

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

  return map
}

```

And this pattern:

```auto
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:

```auto
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:

```auto
function(pixelCount) {
  var map = []

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

  return map
}

```

And this pattern:

```auto
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:

```auto
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:

```auto
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](https://forum.electromage.com/t/v3-66-release-community-patterns-pixelblaze-integration-more-led-types/3891/1) 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?