OP, great work on this. While I can't run it, I appreciate that it's pretty bite-sized and easy to inspect.
Dealing with volumes is a big change, but interpolation of the affine transforms is not far off. Expose the matrix to the CLI and then one can wrap it with an interpolation script; or you can build that interpolation in. Maybe note the generation time in your README?
I spent many weekends in the mid-00's doing GPGPU for ElectricSheep-style Iterated Function systems, instead of the distributed ElectricSheep network [1]. That was C++ and CUDA. Your implementation is much easier to make sense of, albeit it smaller scope.
tangential question: does anyone know a way to call/use CUDA from graphics code? like directx or opengl (or whatever). as opposed to this code which is named "renderer" but doesn't draw to the screen...
Thanks for sharing. I don't see why there is an atomic add in the kernel there. It doesn't look like two separate threads should be able to modify the same pixel, based on the block/thread indices?
Thank you for providing a uv.lock file! I spent a good chunk of last month trying to get graphics research projects working that only provided requirements.txt (or not even that, e.g. the original Gaussian splatting paper), and it was hell to figure out how to undo all the bitrot.
7 comments
[ 2.2 ms ] story [ 44.2 ms ] threadDealing with volumes is a big change, but interpolation of the affine transforms is not far off. Expose the matrix to the CLI and then one can wrap it with an interpolation script; or you can build that interpolation in. Maybe note the generation time in your README?
I spent many weekends in the mid-00's doing GPGPU for ElectricSheep-style Iterated Function systems, instead of the distributed ElectricSheep network [1]. That was C++ and CUDA. Your implementation is much easier to make sense of, albeit it smaller scope.
[1] https://electricsheep.org