[WIP] Octree level of detail

[agurvich]

The octree would look a lot better if, instead of showing centers of mass, we showed subsets of the particle data.

closes #116 , closes #117

[agurvich]

ok, so I did this with one level which was the lowest hanging fruit. The idea being that rather than having the top level particle mesh contain centers of mass it just contained a decimated version of the entire dataset that's shown all the time.

Unfortunately, these particles are too small to see from a distance and you can't differentially make the particles bigger/smaller for individual nodes without associating them with individual nodes (a tautological statement). But, if we're associating them with individual nodes then we will have to have a framework for nodes having multiple layers of particles.

There's 2 ways to do that:

1. the klugey way that is not extendable, have an array of particle indices (w.r.t. to the decimated dataset) stored in each node that are visited when the node is opened/closed to make those (and only those) particles' radiusScale value larger/smaller. This would probably be slow since you'd have to loop through the index array and change each corresponding radiusScale value individually (vs. changing 1 number).
2. having a separate mesh for each particle associated with the node. then you could just update the PsizeMult for that mesh and scale all the necessary particles at once.

2 would be nice because then you're really just keeping track of additional meshes for each node. In principle then we could have each node have a list of meshes that we append to as we zoom in closer and closer (rather than having just a single mesh). only problem is that the number of meshes in the scene could balloon which could introduce performance issues (especially in the render loop when we have to loop over every mesh to update stuff.

[agurvich]

the easiest way to handle this would be for each node to have its own .ffly-like file that we could read slices of. But... because of the way .ffly files are structured (Coordinates_flat,Velocities_flat,scalar_field1,scalar_field2,...) this would be very difficult to do because we'd need to read with a stride. instead having individual files of just the flattened coordinates, the flattened velocities, and then each scalar field would make it very easy to read subsets of the particle data. So then each node would have a directory and in it would be ~a dozen files (depending on how many scalar fields you have).

This sounds like chaos but would simultaneously make it really easy to append to an octree i.e. for octree streaming for Gaia DR3 and other large datasets. I'm hesitant to do this before submitting the draft because it would really be ripping out the entire octree framework i spent the better part of 3 weeks working on and messing with it again.

[agurvich]

in my spare shower thought time, i've realized that if i just write my own binary reader without kaitai then i can just read substrings of .ffly files using clever byte offsets to get each of the field arrays I want. i'll probably want to start from scratch with a new branch/PR though.