> The demo at the top has some bad noise issues when the light is in small gaps, at least on my phone (which I don't think the article acknowledges).
Right at the end:
> The random jitter ensures that pixels next to each other don’t end up in the same band. This makes the result a little grainy which isn’t great. But I think looks better than banding… This is an aspect of the demo that I’m still not satisfied with, so if you have ideas for how to improve it please tell me!
Not only. There is an inherent aliasing effect with this method which is very apparent when the light is close to the wall.
I implemented a similar algorithm myself, and had the same issue. I did find a solution without that particular aliasing, but with its own tradeoffs. So, I guess I should write it up some time as a blog post.
However I don't have any issues with the demo in the middle (the hard shadows). So the artifacting has to be from the soft shadow rules, or from the "few extra tweaks".
The primary force behind real soft shadows is obviously that real lights are not point sources. I wonder how much worse the performance would be if instead of the first two (kinda hacky) soft shadow rules we instead replaced the light by maybe five lights that represent random points in a small circular light source. Maybe you'd get too much banding unless you used a much higher number of light sources, but at the very least it would be an interesting comparison to justify using the approximation
AFAIK (I have a similar soft shadows system based on SDFs) the reason the noise issues occur in small gaps is that the distance values become small there so the steps become small and you start ending up in artifact land. The workaround for this is to enforce a minimum step size of perhaps 0.5 - 2.0 pixels (depending on the quality of your SDF) so you don't get trapped like that - the author probably knows but it's not done by their sample code.
Small step sizes are doubly bad because low-spec shader models like WebGL and D3D9 have a limitation on the number of loop iterations, so no matter how powerful your GPU is the step loop will terminate somewhat early and produce results that don't resemble the ground truth.
Same goes for a few of the other images too, but not all of them.
The article would probably benefit from having figure captions below each image stating whether the image is interactive or not.
Or alternatively to figure captions about interactivity, showing some kind of symbol in one of the corners of each of the ones that are interactive. In that case, the intro should also mention that symbol and what it means before any images that have that symbol on it.
The demo at the top has some bad noise issues when the light is in small gaps, at least on my phone (which I don't think the article acknowledges).
The demo at the end has bad banding issues (which the article does acknowledge).
It seems like a cheat-ish improvement to both of these would be a blur applied at the end.
> The demo at the top has some bad noise issues when the light is in small gaps, at least on my phone (which I don't think the article acknowledges).
Right at the end:
> The random jitter ensures that pixels next to each other don’t end up in the same band. This makes the result a little grainy which isn’t great. But I think looks better than banding… This is an aspect of the demo that I’m still not satisfied with, so if you have ideas for how to improve it please tell me!
Ah I missed that, thanks. More than a little grainy for me but that might be a resolution/pixel ratio thing on my phone that could be tweaked out.
Not only. There is an inherent aliasing effect with this method which is very apparent when the light is close to the wall.
I implemented a similar algorithm myself, and had the same issue. I did find a solution without that particular aliasing, but with its own tradeoffs. So, I guess I should write it up some time as a blog post.
However I don't have any issues with the demo in the middle (the hard shadows). So the artifacting has to be from the soft shadow rules, or from the "few extra tweaks".
The primary force behind real soft shadows is obviously that real lights are not point sources. I wonder how much worse the performance would be if instead of the first two (kinda hacky) soft shadow rules we instead replaced the light by maybe five lights that represent random points in a small circular light source. Maybe you'd get too much banding unless you used a much higher number of light sources, but at the very least it would be an interesting comparison to justify using the approximation
AFAIK (I have a similar soft shadows system based on SDFs) the reason the noise issues occur in small gaps is that the distance values become small there so the steps become small and you start ending up in artifact land. The workaround for this is to enforce a minimum step size of perhaps 0.5 - 2.0 pixels (depending on the quality of your SDF) so you don't get trapped like that - the author probably knows but it's not done by their sample code.
Small step sizes are doubly bad because low-spec shader models like WebGL and D3D9 have a limitation on the number of loop iterations, so no matter how powerful your GPU is the step loop will terminate somewhat early and produce results that don't resemble the ground truth.
Same goes for a few of the other images too, but not all of them.
The article would probably benefit from having figure captions below each image stating whether the image is interactive or not.
Or alternatively to figure captions about interactivity, showing some kind of symbol in one of the corners of each of the ones that are interactive. In that case, the intro should also mention that symbol and what it means before any images that have that symbol on it.