Unsurprisingly, it turns out that other people had already thought of applying the multi-pass technique on GPU, but the idea is not very widely known.
The demoscene is particularly insular, but even within the field of computing in general it seems that there is not a lot of knowledge diffusion between all the different areas, leading to some reinventions (often with distinct terminology.)
Played around with the code to implement a little bit of SIMD. Was able to squeeze out a decent improvement, ~250 fps avg, ~140 low, ~333 high (on an m4). Looks pretty straightforward to do threading with as well. Cool stuff! Could work to bring more gpu stuff back down to the cpu.
Tl;dr: SDFs are really slow but cool because they can compactly define complex stuff; demoscene uses it. Sort of the functional programming to trad renderings OOP. Would be cool if it was faster. Optimizing an algorithm for CPU rendering using recursive divide and conquer, 1 core with one object gets 50 fps. 100 fps if you lerp a 10x10 pixel patch instead of doing 1 pixel. Algorithm isn’t optimized, fully. Also, turns out the author’s idea is previously known but somewhat obscure, it is referred to as “cone marching”
Holy crap! The demo is hitting 30 FPS from certain angles, on my decade-old CPU
"I'm making a game engine based on dynamic signed distance fields (SDFs)"
That project is for GPU and it works by caching SDFs as marching cubes, with high resolution near the camera and low resolution far away, to build huge worlds out of arbitrary numbers of SDF edits.
So it probably wouldn't stack with these CPU optimizations that directly render the SDF at all.
Unsurprisingly, it turns out that other people had already thought of applying the multi-pass technique on GPU, but the idea is not very widely known.
The demoscene is particularly insular, but even within the field of computing in general it seems that there is not a lot of knowledge diffusion between all the different areas, leading to some reinventions (often with distinct terminology.)
Played around with the code to implement a little bit of SIMD. Was able to squeeze out a decent improvement, ~250 fps avg, ~140 low, ~333 high (on an m4). Looks pretty straightforward to do threading with as well. Cool stuff! Could work to bring more gpu stuff back down to the cpu.
Tl;dr: SDFs are really slow but cool because they can compactly define complex stuff; demoscene uses it. Sort of the functional programming to trad renderings OOP. Would be cool if it was faster. Optimizing an algorithm for CPU rendering using recursive divide and conquer, 1 core with one object gets 50 fps. 100 fps if you lerp a 10x10 pixel patch instead of doing 1 pixel. Algorithm isn’t optimized, fully. Also, turns out the author’s idea is previously known but somewhat obscure, it is referred to as “cone marching”
Holy crap! The demo is hitting 30 FPS from certain angles, on my decade-old CPU
Readers might also enjoy this: https://www.youtube.com/watch?v=il-TXbn5iMA
"I'm making a game engine based on dynamic signed distance fields (SDFs)"
That project is for GPU and it works by caching SDFs as marching cubes, with high resolution near the camera and low resolution far away, to build huge worlds out of arbitrary numbers of SDF edits.
So it probably wouldn't stack with these CPU optimizations that directly render the SDF at all.