Pattern Editor chooses `render` when the Pixelblaze is mapped to 3 dimensions

[bbqchickennn]

I’m starting to add 3d mapping to my croquet set project. The idea is that each hoop in the croquet set is a 2D arch embedded in 3d space by adding the corners of the playing field to the map array after all the actual pixels have been mapped:

As a first attempt, I wanted to write a simple pattern which swept through the color spectrum along the y-axis, similar to the default when you start a new pattern. I noticed, thoiugh, that I was getting an error that there was no exported render function when I had written a correct render3D. I then simplified as much as I could and noticed that even though the Mapper and the preview showed the wicket in 3 dimensional space, the pattern was selecting render over render3D. The same happened when I tried to write render2D

render3D:

render2D:

render:

Notice that no pattern was generated except for render. In the case where both function are uncommented, render is chosen over both render3D and render2D

I’m wondering if the extra entries in the map array are throwing off the pattern editor somehow. I’m really surprised that render2D isn’t even picked up as the wicket is a 2D shape. What am I missing?

[wizard]

If the chip had reset without a save on the mapper, I could imagine a scenario where the controller itself didn’t know the map, but the UI did. In that case the pixels would be shown in a 3d preview, but the chip wouldn’t know how to use render3D. If you did save the mapper tab, that shouldn’t happen (it would load the map on startup).

To help troubleshoot stuff like this, keep an eye on the mapper error message, and the top live preview area.

If the mapper has an error, it should show just below the text area. In some cases it’s handy to force a refresh. Typing a space somewhere or otherwise changing the contents will force a refresh, and resend the map to the chip. Likewise for the pattern.

If it says “no valid render function found” eg when you only have a render 3d, then the chip doesn’t have a map for that coordinate dimensionality for some reason.

Extra pixels shouldn’t cause a problem, but commenting out that code temporarily would tell you if that was causing it.

[bbqchickennn]

None of the chips were reset and I made sure the mappers were all saved. All of the mappers have no errors on them.

I made some progress – I had a guess that somehow the pattern editor was only looking at the first pixelCount entries of the map in order to determine which render function to use and might have seen that the hoop is really “just a line” somehow.

I don’t think that hypothesis is correct, but I added a small adjustment to the mappers so that the wickets have some motion in the y axis as well:

This worked, and render3D is now being chosen.

Interestingly enough, the end posts which are actually just lines reoriented in space didn’t need adjusted for render3D to be picked up: