Light chart precalculation

[kpreid]

Commit f40f290 introduced the "propagation_table" for pre-computed light ray propagation data. This improved light update performance, but computing it is a significant cost when constructing a new Space.

The obvious solution is to memoize the table, but I think we should go farther. Components of the solution:

• Rename it to “light ray chart” or “propagation chart”, because “chart” is the word I've decided to use for all “precomputed data about spatial relations” (like “ChunkChart”).
• Precompute the largest chart we'll ever need (with distance info so we can truncate it when evaluating)...
  • …and store it as a compile time constant..
• Make the chart smaller and more efficient by:
  • deduplicating common prefixes of cubes (making the chart a tree data structure),
    • (this will also let us increase the overall ray density for better lighting!)
  • mirroring it across octants at read rather than write time, and
  • deleting relative_ray_to_here and synthesizing the debug visualization rays instead. (This will be more or less necessary for the tree-shapedness anyway.)

[kpreid]

relative_ray_to_here can't be deleted entirely because its direction is used to sample the sky for exiting rays. (But perhaps we can drop the origin point and have a more compact representation.)

[kpreid]

I'm coming to the conclusion that the first thing that should be done here is to set up the compile-time chart creation. However, this is tricky to achieve:

• If I add this calculation to the build script (which already computes the light ray pattern), then the build script needs to execute raycasts.
  • Option 1: try to mod the raycaster and all of its supporting code into the build script. I've tried this and the dependencies between various all_is_cubes::math types are quite tangly since they all want to be able to convert to each other and so on.
  • Option 2: perform another crate split, so that the raycaster (and GridAab and Cube and so on) can be depended on normally by the build script.
• Option 3: If I use the strategy of a test which validates/rebuilds some hardcoded data, then that hardcoded data, which is likely to be largish as source code goes (though it could be include_bytes!ed), ends up in version control and packaging, and will all change any time I have an improvement to the generation algorithm.

After experimenting with option 1, I'm currently leaning towards option 2, because I had previously contemplated an “all-is-cubes-math” crate split. I didn't complete it at the time because I was hoping for compilation time improvements, but testing did not show clear benefit — but this is a better reason to have one: making core algorithms available as part of the compilation process of the central game-mechanics crate.

The downside, of course, is that we have more crates to manage and more public-API-only boundaries.

[kpreid]

Crate split done in 52716b2.

[kpreid]

Commit fb61ca0 switches the light ray data from being Rust source code to being raw struct contents. This will hopefully be more efficient than generating lots of source code, but it may or may not suffice for the data structures we'll need to create. If it doesn't, we can switch back to source code, perhaps generated using uneval.

[kpreid]

Commit 18caabe adds the full build-time precomputation, and also makes the representation smaller (primarily by using i8 coordinates).