 # First attempts at a map - 3d lines

I’m working on putting together a map. My application is a long table, with a backboard (sideboard) on one side. My eventual goal is to use the sensor on the pixelblaze v3 sensor board to react to the direction that the table is tapped.

It seems that the preview in the map section doesn’t always display the code that is pasted into it. I assume this occurs when there is an error in the code.

As a starting point, I referenced the rectangle example:
function (pixelCount) {

``````  function line(x, y, dx, dy, count) {
var line = [];
for (var i = 0; i < count; i++) {
line.push([x + dx * i, y + dy * i]);
}
return line;
}

var map = [];
// start at 0,0, move 1,0 for each pixel, 152 pixels
map = map.concat(line(0,0, 1, 0, 152))
//then moving down, assuming 1 pixel from above counts toward the 38 tall
// start at 152,1, move 0,1 for each pixel, 36 pixels
map = map.concat(line(152,1, 0, 1, 36))
//then from the bottom right to bottom left
map = map.concat(line(152, 37, -1, 0, 152))
//and back up
map = map.concat(line(0, 36, 0, -1, 36))

return map;
}
``````

and the walled cube example to infer that the z-axis is inferred by simply adding an extra parameter to the array. I’m not sure this is true. Also, looking through the example codes, I’m not sure if semicolons are important in this language or not - sometimes they are there, sometimes they aren’t.

My map code is:

``````function (pixelCount) {
width = 55
lenght = 60
height = 30
// generate wireframe of tabletop with backboard

// a 3d adaptation of the 2d line function
// x, y, z is the starting position
// dx, dy, dz is how far each step is, 0=no movement, 1=move in positive direction, -1=move in negative direction
// count is the number of steps

function line (x, y, z, dx, dy, dz, count) {
var line = [];
for (var i = 0; i < count; i++) {
line.push([x + dx * i, y + dy * i, z + dz * i]);
}
return line;
}

var map = []
// start at 0,0, move 1,0 for each pixel, lengthPixels
// first long side of tabletop]
map = map.concat(line(0,0, 0, 1, 0, 0, length))

//then moving down, assuming 1 pixel from above counts toward the widthPixels
// start at lengthPixel,1, move 0,1 for each pixel, widthPixels
// short, back side of tabletop
map = map.concat(line(length,1, 0, 0, 1, 0, width))

//then from the bottom right to bottom left
//second long side of tabletop
map = map.concat(line(length, width, 0, -1, 0, 0, length))

//vertical leg up backboard
map = map.concat(line(0, width, 0, 0, 0, 1, height))

//second short side of tabletop, at higher *height
map = map.concat(line(0, width, height, 0, -1, 0, width))

// vertical leg down backboard
map = map.concat(line(0, 0, height, 0, 0, -1, 0))

return map;
}
``````

(I recognize the code will have some duplicated pixels - I stripped out my embedded math to try and troubleshoot this lack of displaying)

Given that the demo is not displaying, I imagine there is a problem here.
Are there any obvious problems with this?
Thanks!

The typo in “lenght” might be the issue

Lol, Love it!
Thanks for the sharp eye @Scruffynerf
As I hadn’t done this before, I assumed I had a bigger problem, rather than a typo!

For anyone wanting to see the map, this is it, with the corrected math for the segments. I don’ think I have any duplicated pixels with it.

``````function (pixelCount) {
width = 55
length = 60
height = 30
// generate wireframe of tabletop with backboard

// a 3d adaptation of the 2d line function
// x, y, z is the starting position
// dx, dy, dz is how far each step is, 0=no movement, 1=move in positive direction, -1=move in negative direction
// count is the number of steps

function line (x, y, z, dx, dy, dz, count) {
var line = [];
for (var i = 0; i < count; i++) {
line.push([x + dx * i, y + dy * i, z + dz * i]);
}
return line;
}

var map = []
// start at 0,0, move 1,0 for each pixel, lengthPixels
// first long side of tabletop]
map = map.concat(line(0, 0, 0, 1, 0, 0, length))

//then moving down, assuming 1 pixel from above counts toward the widthPixels
// start at lengthPixel,1, move 0,1 for each pixel, widthPixels
// short, back side of tabletop
map = map.concat(line(length,1, 0, 0, 1, 0, width))

//then from the bottom right to bottom left
//second long side of tabletop
map = map.concat(line(length-1, width, 0, -1, 0, 0, length))

//vertical leg up backboard
map = map.concat(line(0, width, 1, 0, 0, 1, height))

//second short side of tabletop, at higher *height
map = map.concat(line(0, width-1, height, 0, -1, 0, width))

// vertical leg down backboard
map = map.concat(line(0, 0, height-1, 0, 0, -1, height-1))

return map;
}``````

I think you do have dupes in some use cases

Line 1 from point A to point B
will give you points A to B and points in the middle.
Line 2 from B to C
will give you points B to C and points in between.

You have B twice.

Add a option to skip either/both start or finish

Otherwise 2 pixels are B.

1 Like

Thanks @Scruffynerf. As I finish the physical assembly, I’m going to tinker with the formulae.

A question for the general group, though:
When I adjust the variables, the preview changes the density of pixels along what appears to be the same “distance”. I’m guessing this makes things more simple for the render3d and render2d functions.

Now that I have my final LED strips cut for my model, I notice that my top edge and bottom edge strips differ by 3 pixels (physical model surface constraints).
Am I better off to cut the longer strip shorter (rather not, as this would affect a very visible corner), or can the render3d functions take this into account based on the apparent above-noted change in pixel density over a constant length?

My numbers (in order of data flow):
Left side 59
Bottom strip 54 **
Right side 59
Right vertical 23
Top strip 57 **
Right vertical 23

If it’s too challenging to make it work in that order, I suppose I could make it start elsewhere (ie after the shorter run on the bottom, and pretend that the strip is full length - the top and bottom would be slightly out of sync for some motions, but would be less noticible than the verticals being out of sync). The change in start point would be a moderate inconvenience for the design, but doable.

Any thoughts?

None of that should matter.

It’s going to map accurately, if your math is right.

If you pack pixels looser or tighter, that’s up to you. All PB knows is where in 2D/3D space you put the pixels individually. It doesn’t know about density/etc. Your mapping code is all that matters.