> elaborate 3d scenes built up out mostly out of distance field primitives, a stunning demonstration of the power and flexibility of the technique.<p>Also a demonstration of how slow that technique is. I can run stunning games with entire cities of buildings and people and cars and mountains in the distance and trees and grass and clouds all running at 60fps or faster. Or I can run some SDF that runs at 0.2 to 3 fps on the same machine.<p>Don't get me wrong, I'm blown away by those shaders but they aren't remotely performant.<p>This particular technique might be okay but you'd still arguably be better running it on 4 quads that make a frame. There's no reason you want to be computing pixels in the middle of the frame where there is no shadow.
Fun fact: iOS app icons are not rounded rectangles (rectangles with 90 degree arc corners) but squircles, which are roughly superellipses with n=5. The linked Wikipedia articles also remark this.
See also the great article from 2001 by Michael Herf (these days best known for f.lux): <a href="http://stereopsis.com/shadowrect/" rel="nofollow">http://stereopsis.com/shadowrect/</a>
Why again are explicit `min` and `max` faster? Is that GLSL specific, and (unlike say C++, where std::min and std::max are just `if (__a < __b) return __a; return __b;`) the compiler won't be able to turn a one-line conditional into an ARB MIN or MAX instruction?
It really gives me great pleasure to find gems like this article on HN. I can't see a future in which I'd otherwise gained the insights I've now gained through reading (your?) piece about the complexity of blurring complex shapes. Thanks for that.
Nice article! I have a couple of questions.<p>> [reciprocal square root] it is particularly well supported in SIMD and GPU and is generally about the same speed as simple division.<p>Curious, Raph - why is the erf using f64? Reciprocal square root is well supported for single precision, but not double precision. And the spline fit constants in there are single precision anyway. I’m guessing it’d be a lot faster with no harmful effects as f32. (Seems to work fine on ShaderToy BTW).<p>Also curious if erf() might be overkill? Did you compare to using a smoothstep()? What are the quality indicators you’re looking for? It seems like I get very close to the same results as your erf approximation if I use smoothstep(0., blurwidth, sqrt(d)) where d is the SDF distance to the box. (With the added benefit that I automatically have a strict bound on the blur.)