Instead of making a chart for the exact right size, we make the biggest one we can, then do a distance check while iterating. This avoids redundant run-time work and, in particular, should make the tests we run under Miri that happen to allocate Spaces much faster.
Size of the data is a concern; it's currently 645 KB. In the future, I plan to replace this data structure with one which combines nearly-parallel rays that traverse the same cubes, until they diverge, instead of redundantly storing and iterating over each ray's sequence of cubes. That will allow more rays for the same data and compute costs.
One unused possibility for further compression is storing only the face/step directions instead of both the faces and the cube coordinates.
Instead of making a chart for the exact right size, we make the biggest one we can, then do a distance check while iterating. This avoids redundant run-time work and, in particular, should make the tests we run under Miri that happen to allocate
Spaces much faster.Size of the data is a concern; it's currently 645 KB. In the future, I plan to replace this data structure with one which combines nearly-parallel rays that traverse the same cubes, until they diverge, instead of redundantly storing and iterating over each ray's sequence of cubes. That will allow more rays for the same data and compute costs.
One unused possibility for further compression is storing only the face/step directions instead of both the faces and the cube coordinates.
Part of #490