Comment by nneonneo
3 years ago
Yeah, this part is very clever and quite well-done IMHO. I suspect the trick is to only store the state for any levels you've actually seen.
As you go higher, they can just arbitrarily select a location in the simulation a few levels up from where you are that is consistent with the metapixels you've seen; once you go up a few levels, there's no chance of you having seen beyond a very small window of the simulation, so it's a matter of just finding a matching pattern.
As you go lower, the time step cannot be set be zero, so they can simply initialize the simulation a few levels down to an arbitrary state since the lower levels will tick exponentially faster.
The only problem is that you do have to store state for levels between the highest level you've seen and the current level as you zoom in. I suppose this means that if you zoom out a lot (just spam the scroll) and then zoom in a lot, there might be substantial memory usage. I've tested it and they do seem to consistently remember the exact state of the simulation at least a few levels up - it's easy to check by looking at the length of the clock train on the left of the metapixel in each level.
Need they do any simulation? I would need paper and some time, but can’t you store 16 animations of a cell and then just have the state as a zoom level, position in x y space (wrapping) and a time (in a loop). The rest should be calculatable assuming this is a true fractal which I think it is. 0 zoom is probably the starting position. Zooming in actually switches to maximally zoomed out with each cell following the prerecorded animation from a layer up based on the x y position. What state are you imaging?
Yes, you’re right on the state: the state for each level can just be OTCA timestep and x,y within the parent level. However, I think you need to store somewhat more than 2^4 animations: there are 35328 cycles per OTCA tick, and a cell’s animation depends on all of its neighbors, for something like 2^9 * 35328 distinct states. The vast majority of cells are quite predictable (and have short animation periods) but some of the logic elements will change in somewhat unpredictable ways. There is likely to be some fancy compression that can be done if the states need to be computed ahead-of-time.
Some of the more subtle bits do depend on the neighbor cells in the parent level, so I think there still does need to be some simulation done to ensure that these subtle bits are correct when viewing lower levels. But that only needs it be done in a small neighborhood.
Interesting, I guess I forgot that the game of life includes edge neighbors and had no idea of the cycle time. Why isn’t it 2^8 neighbors though?. Maybe just running 2^8 simulations is the way to go? Or that’s 9 megabytes * frame size per so maybe that ends up being small enough with compression
Edit: the author has said that it’s non periodic apparently which seems like it would make this whole thing a lot harder and probably require more state
1 reply →