Funny. I referenced this exact article yesterday and implemented N-Closest.
There was a surprising amount of parameters to fiddle with. Especially since I experimented with adjusting the N depending on the distance of the matches.
I wanted to implement ordered dithering to convert images to the c64.
I think dithering looks best when there are only 2 colors involved the mix, but the palette is a bit wonky so a lot of colors are hard to represent well.
An issue I noticed was that when the top 2 candidates in a gradient flipped from A,B to B,A as the gradient moved closer to B, was that the checker pattern would get an ugly seam of double pixels, like ABABABBABABA.
I’ll experiment more with manually selecting pairs of colors that mix well and generate gradient ramps from them. Then I can pre-quantize the image and use a predetermined dither pattern for each mix. Should also allow for more artistic control.
Light sources in video games and such. If you have a light source with a very large falloff range illuminating a large area, you'll have noticable steps in the gradient.
Ordered dithering is a very cheap solution to this.
Truly random per-frame noise looks bad and grainy (imho), but various noise functions work well, yes.
Many implementations just sample some noise texture, possibly because that's cheaper - but hardware is so fast nowadays that even sampling some non-trivial noise function many times per pixel hardly registers.
A deferred 2.5D renderer I wrote some while ago just does this screen-wide on the entire framebuffer in a post process step and that pretty much hides all banding already:
You might call this random noise (though it's static). It's enough if you're operating in high precision framebuffers for most rendering steps, and will do a decent job at hiding banding when things are downsampled to whatever the screen supports.
If you can't afford to just rgba16float everything you might have to be smarter about what you do on an individual light level. Probably using some fancier noise/making sure overlapping lights don't amplify the noise.
Shallow color gradients (e.g. blue sky or anime) result in visible banding on 8bpc displays, which is a large fraction of displays.
Ordered dithering is GPU-friendly, so it's useful to reduce higher-bpc content to those display formats without introducing banding.
Any time you want a sequence to be deterministic, seem familiar, and also have a roughly even mix of element types. Think shuffling playlists, ordering search results, etc.
I would think that it would only be beneficial on devices that don't maintain a full frame rendering buffer or if they wanted to do partial updates.
If the full frame is maintained with more values then quite a lot of things like Floyd Steinberg optimize well enough to be integrated with a full frame update.
There was a surprising amount of parameters to fiddle with. Especially since I experimented with adjusting the N depending on the distance of the matches.
I wanted to implement ordered dithering to convert images to the c64.
I think dithering looks best when there are only 2 colors involved the mix, but the palette is a bit wonky so a lot of colors are hard to represent well.
An issue I noticed was that when the top 2 candidates in a gradient flipped from A,B to B,A as the gradient moved closer to B, was that the checker pattern would get an ugly seam of double pixels, like ABABABBABABA.
I’ll experiment more with manually selecting pairs of colors that mix well and generate gradient ramps from them. Then I can pre-quantize the image and use a predetermined dither pattern for each mix. Should also allow for more artistic control.
https://m.youtube.com/watch?v=kT4p1GXq4HY
Ordered dithering is a very cheap solution to this.
Many implementations just sample some noise texture, possibly because that's cheaper - but hardware is so fast nowadays that even sampling some non-trivial noise function many times per pixel hardly registers.
A deferred 2.5D renderer I wrote some while ago just does this screen-wide on the entire framebuffer in a post process step and that pretty much hides all banding already:
You might call this random noise (though it's static). It's enough if you're operating in high precision framebuffers for most rendering steps, and will do a decent job at hiding banding when things are downsampled to whatever the screen supports.If you can't afford to just rgba16float everything you might have to be smarter about what you do on an individual light level. Probably using some fancier noise/making sure overlapping lights don't amplify the noise.
As screen resolution and density increases, dithering could even replace transparency as long as you don't look close enough.
If the full frame is maintained with more values then quite a lot of things like Floyd Steinberg optimize well enough to be integrated with a full frame update.