Not sure how you want folks to submit animations, but I spent a little bit tonight making Conway's Game of Life on your tree. It was really fun - thank you for setting it up!

Side note: I think this could be made a LOT prettier by fading the LEDs out rather than just turning them off and on, but I didn't have time to implement that visual feature. There are also probably other Cellular Automata rules that will look prettier on a tree. Should be easy enough to add whatever rule you like to the transition_function.

Another fun thing you could try is initializing the states to try to create gliders. Might be impossible given it's being computed on a graph, not a grid, though.

• Grapher file removed
• Octahedron now spins in a random direction for a while, switching axes periodically to keep things interesting.
• Octahedron radius "ballradius" can be changed. Set ballradius to a large number to illluminate the entire tree!
• colourA through colourH can be modified to create a personalized holiday spirit!

3D Plasma and 3D Fire.

My simulator being dumb at the moment it is really hard to see how plasma would render on a real 3D Christmas tree and would probably need a lot of tweaks.

I think 3D fire do works fine, probably would need some tweaks to run properly on the real tree.

I wasn't able to test this for real, so I hope it works...

The animation it produces should look something like this (except that it will continue smoothly instead of stuttering after each loop...):

The animation is designed to tile horizontally, so I map it onto the tree by taking the angle of an LED from the central axis and using that as the X coordinate in the animation frame.

Each coordinate is assigned a bit string such that the Hamming distance can only be large between two bit strings if the Euclidean distance between the coordinates is large. That's something that's tricky even on a grid, and worse on a Christmas tree!

The lights are then controlled by a simulation of a quantum computer. I basically use the same effect as I once wrote a blog about here.

The script uses the actual board and neopixel when available, and otherwise tries to use sim.py from #5.

Following the instructions at https://learn.adafruit.com/neopixels-on-raspberry-pi/python-usage on how to install the neopixel library, I get this:

Collecting sysv-ipc (from Adafruit-Blinka->adafruit-circuitpython-neopixel)
  Using cached https://files.pythonhosted.org/packages/0c/d7/5d2f861155e9749f981e6c58f2a482d3ab458bf8c35ae24d4b4d5899ebf9/sysv_ipc-1.1.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-p029qfz7/sysv-ipc/setup.py", line 11, in <module>
        import prober
      File "/tmp/pip-build-p029qfz7/sysv-ipc/prober.py", line 137
        d["SYSV_IPC_VERSION"] = f'"{version}"'
                                             ^
    SyntaxError: invalid syntax

I checked that I have python3 installed.

The second command doesn't work either:

pi@kano4:~/xmastree2020-main $ sudo python3 -m pip install --force-reinstall adafruit-blinka
Collecting adafruit-blinka
  Using cached https://www.piwheels.org/simple/adafruit-blinka/Adafruit_Blinka-5.13.1-py3-none-any.whl
Collecting sysv-ipc (from adafruit-blinka)
  Using cached https://files.pythonhosted.org/packages/0c/d7/5d2f861155e9749f981e6c58f2a482d3ab458bf8c35ae24d4b4d5899ebf9/sysv_ipc-1.1.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-5yeeu738/sysv-ipc/setup.py", line 11, in <module>
        import prober
      File "/tmp/pip-build-5yeeu738/sysv-ipc/prober.py", line 137
        d["SYSV_IPC_VERSION"] = f'"{version}"'
                                             ^
    SyntaxError: invalid syntax

Ignoring the error and trying to run anyway didn't work...

pi@kano4:~/xmastree2020-main $ python3 xmaslights-spin.py
Traceback (most recent call last):
  File "xmaslights-spin.py", line 144, in <module>
    xmaslight()
  File "xmaslights-spin.py", line 9, in xmaslight
    import neopixel
ImportError: No module named 'neopixel'
pi@kano4:~/xmastree2020-main $ python xmaslights-spin.py
Traceback (most recent call last):
  File "xmaslights-spin.py", line 144, in <module>
    xmaslight()
  File "xmaslights-spin.py", line 43, in xmaslight
    pixels = neopixel.NeoPixel(board.D18, PIXEL_COUNT, auto_write=False)
AttributeError: 'module' object has no attribute 'NeoPixel'

Any suggestions what to do next? (btw python newbie, so can I ask you to spell it out and not assume I know much about how python works)

thanks

Graham

Based of my previous one, now instead searching for x number of nodes in a semi-sphere below and then jumping to one least "bright" or random if all nodes are the same brightness. Didn't send this in by mail to Matt, I think it was enough with first one :) I guess it's similar to the falling spheres they had in their video in many ways, except this jumps around a bit more hectic :) Also, probably some mistakes, but eh, works atleast somewhat.

Many thanks to @DutChen18, using his simulator from Pull Request #5 to test!

Real-Time 3D Octahedron Rotation Graphic.

What this code does: This code generalizes the two-color rotation effect that Matt Parker showed in his video (https://www.youtube.com/watch?v=TvlpIojusBE) to an eight-color version, where the cones spanning the octahedron's faces partition the tree into eight regions with customizable colors. The octahedron animates by rotating along an arbitrary, user-configurable direction.

• Colors are defined using colourA through colorH. • Rotation speed is controlled by adjusting the 'theta' variable, representing the angle in radians by which the octahedron rotates in a single timestep. • [ux, uy, uz] is the UNIT vector about which the octahedron rotates. This vector must have unit norm.

Future expansions: • Allow rotation direction to wander randomly over time. • Allow colored octahedron faces to evolve over time • Allow center of rotation to wander randomly over time. • Allow radial dependence in color. Fading out as r increases, or perhaps a hard cutoff at a radius R where the color abruptly becomes black, to form a colored sphere rotating within the Christmas tree. • Allow the number of faces to also be configurable, so other platonic solids can be used. • Use this rotation effect as a "filter" to apply to other light effects

As Santa prepares his reindeer and sleigh, there's a problem NP hard here at play. Your Christmas tree bulbs were all very nice, but a random walk through them will not suffice,

To light them all up Santa will need, a computed path to help him with speed. To hop here and there like a quick-flying raven, for him I computed the Traveling Salesman.

So what I've done is I took the coordinates of the bulbs and computed the shortest Hamiltonian Path through them with the assumption that they form a fully connected graph of straight-line distances.

I used the 2-opt local search algorithm to find the solution and it took a while to compute (almost as long as it took me to settle on a rhyme for the word "salesman"). The solution is hardcoded into the script so you will not have to wait for it to compute every time you run it.

The algorithm finds an approximation only, so the path I found may not be the actual best path. It may qualify for the title of a Parker path though.

Enjoy the Santa bulb running around your Christmas tree. : )

I'm also attaching a visualization of the two paths. The blue path represents the cable on which the bulbs are (I'm assuming) and the red path represents the Hamiltonian path solution:

This adds a script that will simulate RGB spheres.

3 spheres are created. Each of the 3 spheres represents one of the RGB primary colors.

During the initialization, the origin of each sphere is chosen such that they are approximately as far away from each other as possible. Each origin will be at one of the given LED coordinates.

The sphere’s radii will increase and decrease during the animation. The initial radius is chosen at random for each sphere. For each enlarge or shrinking cycle, the green sphere uses 120 animation frames the red sphere uses 160 frames, and the blue sphere uses 200 frames

Each RGB color component is calculated using the distance to the corresponding sphere. Specifically, the formular used is 255 * (1 - dist / max_dist) ^ 3, where max_dist is the maximum distance any of the LED can have from the sphere.

The sphere changes from enlarging to shrinking, when the current radius is approximately equal to its max_dist. It switches back to enlarging, once its current radius is approximately 0.

I tested this already using the simulator provided in #5.

Slight refactor into 3 functions, containing original effects and two new effects, a rainbow that moves vertically and spins and a fireplace for the cozy winter months. Also added a switch at the top to test with 3d scatter plot to verify code. Simply just need to comment/uncomment the *_lights functions in the main xmaslight function to pick the corresponding effect.

Not sure if the LED values I choose are bright enough, but I did include a scaling in the USE_PLOTS that could potentially be taken out of the if statement: colors = np.array(colors) * SCALE_FACTOR

The hardware never considered the lights to be in GRB order. However, there was something else going on. Basically, the library is written to always allow you to specify colors in RGB order, but it can then write those colors to the lights in different orders (mainly RGB or GRB) and for some reason, by default it assumes your LEDs take the colors in GRB order.

As such, it was rewriting the RGB colors to GRB format, even though the LEDs actually took them in RGB order, which made the colors wrong. Writing the colors as GRB is the opposite of this, so it undoes the change, making it seem that's the right way to specify the colors.

By just telling the library that the LEDs are taking the colors in RGB order, you can specify the colors the way you normally do: RGB.

So in the video you say there is much better ways to track the LEDs. Fun Fact, there is not. is there any way we can grab a copy of your tracking code and a list of dependency's. Not after a full tutorial just enough that I can stumble uphill instead of downhill.

P.S. Love your work.

Calculation of pixel color calculated by a function that accepts 4d space+time coordinates of current LED and current time.

Animation is stateless - no state is kept between calls to the animation function or between animation loops. Animation rate and form are determined only by the color function. The color functions also uses parameters extensively so many aspects of the animation can be set without re-writing the math.

Several samples are provided, starting from a simple blink to a few more complex ones.

Visualization using matplotlib - many thanks to @DutChen18 ! #5

Intended to fix #18

Candycane stripes with adjustable swirl.

https://user-images.githubusercontent.com/116757/103164481-a9f7d980-47d9-11eb-9a7e-e9633a680c55.mp4

https://user-images.githubusercontent.com/116757/103164482-ab290680-47d9-11eb-9699-0435fe468ed5.mp4