Introduction

For a while now, we’ve wanted to make a multicomputational theory of LEGO bricks, where each official LEGO set is nothing more than a single point in a vast an unfathomable multiway graph with lots and lots of uncharted “My Own Creations” (MOC). For example, here’s a combination of recent sets “The Insect Collection” 21342 and “Succulents” 10309 (and a few extra spacers, plates, risers, axles, etc. from my collection):
[ Personal Disclaimer: I don’t think LEGOs are the worst use of petroleum. Nor do I think the plant-based products in the background are any better for decorations. ]
Ethical issues aside, how should we formulate a “LEGO multiway system”? Well, it can be just like our recent example with pattern blocks, but perhaps that is too fine-grained to be useful in practice? The pattern blocks example, as well as all tiling examples from Stephen Wolfram's recent blog, assume an infinite reservoir of proto-tiles which can be drawn from when creating an update edge. Each update edge simply indicates the addition of one piece from the reservoir.
What we may ultimately want for MOC creation is to have the pieces drawn from multiple finite and separate reservoirs, and then to tag the edges with reservoir identities. The example above uses mostly pieces from two recent sets, but also critically depends on part 6538, which has been printed now in three different variants. A simple, coarsest-grained input-output graph would look like this:
[ Note that the “extra piece” reservoir is incomplete. I also had a few extra pink flower pieces and green 1x1 slope tiles from visiting the actual LEGO store in Kansas City, ha ha ha. Miscellaneous parts can be purchased on https://www.lego.com/ or on https://www.bricklink.com/ ].
Unfortunately this is too course-grained to be very helpful at all, so let’s deconstruct the multiway graph and add a few more levels (using screencaps from instructions at rebrickable):
[ Also note that the insects are built verbatim and added in at the last step, while miscellaneous pieces are added as needed mostly on level 2. ]
Now we can see that some of the modular succulents were split apart into different level-2 components, most notably the seventh from left, which contributes to the redesigned mantis stand as follows:
The other mostly “freestyle” assemblage is the ladybug garden, which takes leftover pieces from all stands as well as from two of the succulents:
If you look closely, you can spy that one lady bug has escaped the mantis’s line of prey, while the other three are directly at risk. That’s nature, unless the beetle decides to grab the mantis with its claws and throw him off the book shelf as an ahimsa practice. Nothing wrong with having a bit of imagination!
What’s overall apparent here is that we’re getting ahead of ourselves. In Kotaro Okazaki's previous post on lego art, the winning strategy was limiting the parts inventory to essentially just one piece. Then, we don’t need to pre-load a lot of parts files, and in Kotaro’s post we also didn’t need the type intersection checking we had in the pattern blocks post via Planar Polygon Fragmentation. In this sequel, we will need to do some intersection checking in three dimensions. But we can’t jump right in to master set building, we need to take a first incremental step with extreme simplicity bias.

LEGO Headlight Aggregations

source: https://www.holgermatthes.de/bricks/en/lampenstein.php
The headlight piece is one of the oldest LEGO pieces for "Studs Not On Top" building, a technique that’s now used extensively in LEGO sets, especially the ideas sets, which are designed for adults (18+). One aspect that makes it easily adaptable to mono-tile building is that it has an equal number of inputs and outputs, two each. However, we’re not here using the exact LEGO headlight, rather a voxel-ized idealization:
Once a system is built out for matching inputs to outputs, and for checking intersections on voxels, then the first level of the multiway system can be built out:
This graph is canonicalized, and if correct, says that the second term in the aggregation growth sequence counts 11 symmetry-unique headlamps. Calculating a few more terms, we get:
Well, it's not in OEIS, and no real reason to expect it would be, but maybe someday it should be? As long as we can double-check these terms and get a few more, it remains a possibility. At level four, something interesting happens, and we start to get headlamps tightly locked in cycles:
Are we sure there’s only essentially six ways to lock four headlamps into a cycle? Again, it would be nice to have a double-check on this result if anyone cares...
Once we have the data up to level three we can make the video as in the Headliner. Additionally, we would also like to see larger aggregations. One approach, as in the previous blog, is just to make random aggregations:
In the blog we look for holes in tilings, but here the notion of hole is somewhat undefined due to higher-dimensionality. Instead, we can look for cycles in the adjacency graph:
And here are five of them extracted and plotted as configurations:
Unfortunately, two of these configurations can not be built with actual headlamps. Can you tell which ones, and do you know the reason why?

Subsequent Work

As LEGO experts know, there are rules and illegal configurations. If we look closely at the headlight schematic drawing we can see that the front stud protrudes beyond the front lip, so it can not be placed in either of the following configurations:
What we really need for a full-fledged LEGO project, is more accurate part drawings, and reliable tools for testing intersections of those parts. Can it be done with Regions functionality? I don’t know, but I’m willing to try in the context of a student project if anyone is interested to co-work.
Whether we can get better parts drawing or not, there are still more interesting structures to study in the idealized headlight multiway graph, including larger-and-larger Menger sponges. With only 48 headlights I was only able to get to one “LEGO voxel” unit:
Here’s one last programming challenge: can anyone build this using the tools below, and then extract the adjacency graph? If yes, can you then build an arbitrary-recursion-depth computer model of a Lego Menger Sponge? That would be a nice fun result to obtain...

CITE THIS NOTEBOOK

LEGO meets Multiway Systems​
by Brad Klee​
Wolfram Community, STAFF PICKS, January 2, 2024
​https://community.wolfram.com/groups/-/m/t/3095175