Well it uses the input of course but I found that if you make it truly random, the lines mostly go down in a straight line, all bunching up in the middle, which isn’t very pleasing. So now the beams have a “current direction” which has a 25% of flipping at every splitter
I used a u8, one bit per level to do mine, but because not all bits correspond to a splitter, it ends up duplicating a lot of the paths. Which is why I made the lowest bit at the top, so it flip-flops a lot, giving the appearance of multiple different paths :D
If I understand correctly, your visualization shows up to to 256 unique paths then?
In this one, every time the beam passes a splitter, the other side is put on a queue, so eventually all possible paths are traced, breadth first. Initially I worked through the options recursively, but that depth-first filling out was boring to look at.
Well it uses the input of course but I found that if you make it truly random, the lines mostly go down in a straight line, all bunching up in the middle, which isn’t very pleasing. So now the beams have a “current direction” which has a 25% of flipping at every splitter
I used a u8, one bit per level to do mine, but because not all bits correspond to a splitter, it ends up duplicating a lot of the paths. Which is why I made the lowest bit at the top, so it flip-flops a lot, giving the appearance of multiple different paths :D
If I understand correctly, your visualization shows up to to 256 unique paths then?
In this one, every time the beam passes a splitter, the other side is put on a queue, so eventually all possible paths are traced, breadth first. Initially I worked through the options recursively, but that depth-first filling out was boring to look at.