<div dir="ltr">Hi all,<br><br>So this mailing list seems to be more for the weekly reports, but I think it's easier to talk about planning in email, especially since it's diffcult to align schedules and I think we can have more detailed discussions this way. Please don't hesitate to comment if there are any glaring flaws or things I need to take into account :P<br><br>First of all, after Brecht has told me about how CUDA does interpolation, I do not think the current approach of having a dedicated SparseTile struct is viable anymore. The sparse grid will need to be changed to a flat array of floats/float4s/etc. Changing this and all dependant code shouldn't be difficult or take too long, and will actually make some parts of the code much cleaner.<br><br>So now dense grids are transformed from some X x Y x Z grid to a long, thin N x TILE_SIZE x TILE_SIZE sparse grid, where N is the number of active tiles * TILE_SIZE. Because of this configuration, neighbor tiles in the sparse grid are not necessarily neighbor tiles in the real image, so there must be a way of getting the real voxel neighbors since they are needed for interpolating at the boundaries of a tile.<br><br><div>The way suggested by Brecht (or at least my interpretation of his suggestion, I might be wrong) is to give every tile a pad containing its real neighbors. Thus, each "tile", instead of being an 8x8x8 grid for example, is now a 9x9x9 grid or larger, depending on how wide a sample the interpolation requires. There is quite a lot of voxel duplication using this method though, and it will have a large impact on the memory usage, since for example, just a 9x9x9 grid is already around 1.5x larger than an 8x8x8 grid.</div><br>If any of this doesn't seem right or there is a better approach or there are other functions I need to take into account that will require sparse lookup support, I would really appreciate your comments :)<br><br>Best regards,<br>Geraldine<br><br></div>