render3D - index range

[peterd]

I’m trying to track down an issue scaling a value from z bottom to top… For some reason, 2 of the pixels at the bottom are getting a z value giving a bright pixel (where it should be dark) with this pattern:

export function render3D(index, x, y, z) {
  hsv(.9, 1, z) 
}

Also I’ve figured out that while I have 630 pixels, render3D is only being called with 1…629. Not sure if it should be 0 based or 1 based, but either way that’s not enough calls.

v 3.24.

Any thoughts? Thanks.

[peterd]

My first hunch is some weird wrapping in the map a few decimal places in… i.e. the two pixels in question have z values of -0.0001 which then wraps around to 0.9999…

Is it possible to get a dump of the map after it’s generated?

The setup is currently 9 bars of 70 pixels each. in 3 sets of 3 off an output expander.

I did a test pattern with every 10th pixel blacked out, and verified all the bars each have the correct number of pixels and they’re all responsive.

They’re 6812 RGBWW pixels. GRBW in the PB Config if if matters.

[jeff]

@peterd

I have 630 pixels, render3D is only being called with 1…629. Not sure if it should be 0 based or 1 based,

Hmm, it’s usually zero-based, so I would expect 630 calls total with indices from 0 to 629.

Could you post your map generation code here? I’d love to help and take a look.

I’m thinking we can allocate 3 exported arrays of 630 elements, then populate x, y, and z from within render3d() to inspect the map.

[peterd]

@jeff

Hmm, it’s usually zero-based, so I would expect 630 calls total with indices from 0 to 629.

So I’m going to state I think it’s a bug now with render3D… Given this code:

export var x0 = -5
export var y0 = -5
export var z0 = -5

export function render3D(index, x, y, z) 
{
  if (index == 0)  
  {
    x0 = x
    y0 = y
    z0 = z
  }
  
  hsv(x*y,1,z)
}

as the values are not being updated for index=0:

Same result for index=630. So they only update for 1-629, which is one pixel short.

Note: for render (not render3D) the working values are 1-630… So it’s NOT zero based, but should be given arrays are 0 based. I’ve also seen a few patterns fail with index out of range issues on render3D because of this.

That said, you asked for my map code:

function (pixelCount) {
  var map = [];
  
  var vA = new Point(0,0,0);
  var vB = new Point(0.943, 0.000, -1.333);
  var vC = new Point(-0.471, 0.816, -1.333);
  var vD = new Point(-0.471, -0.816, -1.333);
  var vE = new Point(0,0,-2.666);

  // channel 1
  map = map.concat(getLineSegment(70, vA, vB));
  map = map.concat(getLineSegment(70, vB, vC));
  map = map.concat(getLineSegment(70, vC, vE));

  // channel 2
  map = map.concat(getLineSegment(70, vA, vC));
  map = map.concat(getLineSegment(70, vC, vD));
  map = map.concat(getLineSegment(70, vD, vE));

  // channel 3
  map = map.concat(getLineSegment(70, vA, vD));
  map = map.concat(getLineSegment(70, vD, vB));
  map = map.concat(getLineSegment(70, vB, vE));

  return map;
}

function getLineSegment(pixelCount, p1, p2) {
  var m = [];
  var xStep = safeDiv(p2.x - p1.x, pixelCount);
  var yStep = safeDiv(p2.y - p1.y, pixelCount);
  var zStep = safeDiv(p2.z - p1.z, pixelCount);
  for (var j = 0; j < (pixelCount); j++) {
    m.push([p1.x + xStep * j, p1.y + yStep * j, p1.z + zStep * j]);
  }
  return m;
}

function Point(x,y,z) {
  this.x = x;
  this.y = y;
  this.z = z;
}

[wizard]

What does your settings screen look like?
If using an output expander, it’s possible to skip index 0 by not having any channel cover it. That could be throwing things off. Make sure these start at index 0 and have contiguous pixel coverage for best results.

If you don’t have an index 0 pixel then rendering wont cover an index 0. And throw off anything that assumes contiguous indexes from zero. With an expander it runs through the channels making render calls for each pixel in the channels range. It’s technically possible to have gaps and overlapping ranges, but many patterns don’t expect that.

The pixel map is referenced for each pixel, skipping renders if the index is out of range. The pixel map doesn’t have a way to specify the pixel index outside of having an element in the array, and if you map ends before your last pixel it could get skipped.

That is my guess.

[peterd]

Well your guess is a good one… I nearly always just set the counts and hit auto. Never paid attention to the start index. And in this case it was 1.

Looks like that solved it…

And also interesting for someone using firestorm. maybe they can keep their configs the same and just have the expander board select the pixels for the respective part of the scene…

Though it would be nice for the non expander users to have a start # along with pixels # as a future feature.

Thanks for solving that pixel, it was bothering me just enough to not go away.

-Peter