31–40 of 86 posts
A note for other readers: this is a lot more impressive with 'WebGPU' available.
(Android 14, Android WebView/Chrome 127)
Fantastic article, exactly my kinda thing :) One significant limitation here is that the polygon needs to have constant colour, unfortunately.
Ahh yes, for exact filtering it does need to be constant colour. I'm looking into seeing whether it can be done for gradients. However in practice, it works quite well visually to compute the "average color of the polygon" for each piecewise section, and blend those together.
There's also this work on analytic antialiasing by Michael Mccool: https://www.researchgate.net/publication/2524514_Analytic_An...
Earlier quoted context omitted.
It literally means that you take a box-shaped piece of the polygon, ie. the intersection of the polygon and a box (a square, in this case the size of one pixel). And do this for each pixel as they’re processed by the rasterizer. If you think of a polygon as a function from R^2 to {0, 1}, where every point inside the polygon maps to 1, then it’s just a signal that you can apply filters to.
But as I understand it, the article is about rasterization, so if we filter after rasterization, the sampling has already happened, no? In other words: Isn't this about using the intersection of polygon x square instead of single sample per pixel rasterization?
I am quite convinced that if the goal is the best possible output quality, then the best approach is to analytically compute the non-overlapping areas of each polygon within each pixel. Resolving all contributions (areas) together in the same single pass for each pixel.
It can be surprising at first, but when you analytically compute the area of non-overlapping parts of a pixel (i.e., use Box Filtering) you can introduce high frequencies that cause visible aliasing artifacts that will never go away. This is also true if you are using sub-sampling of a pixel, taking point samples and averaging them, no matter how many samples you take.
You can see the aliasing I’m talking about in the example at the top of the article, the 3rd one is the Box Filter - equivalent to computing the area of the polygons within each pixel. Look closely near the center of the circle where all the lines converge, and you can see little artifacts above and below, and to the left and right of the center, artifacts that are not there in the “Bilinear Filter” example on the right.
Fantastic article, exactly my kinda thing :) One significant limitation here is that the polygon needs to have constant colour, unfortunately.
Anything is constant colour if you dice it up into small enough pieces! :-)
We do have a plan for conflation free compositing[1] which should closely approximate the quality of the samples here. That in turn depends on sparse strips[2], though a degraded performance experiment could be done to validate the quality outcomes. Sparse strips in turn depend on high performance segmented sort[3].
The analytic approach to path overlaps is intriguing, but I think it will be very challenging to implement efficiently on GPU. I'm looking forward to seeing what results.
[1]: https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/Con...
[2]: https://docs.google.com/document/d/16dlcHvvLMumRa5MAyk2Du_Ms...
[3]: https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/A.2...
> This is equivalent to applying a box filter to the polygon, which is the simplest form of filtering. Am I the only one who has trouble understanding what is meant by this? What is the exact operation that's referred to here? I know box filters in the context of 2D image filtering and they're straightforward but the concept of applying them to shapes just doesn't make any sense to me. Can someone clarify?
Earlier quoted context omitted.
I've been researching this field for 20 years (I'm one of the developers of AmanithVG). Unfortunately, no matter how fast they are made, all the algorithms to analytically decompose areas involve a step to find intersections and therefore sweepline approaches that are difficult to parallelize and therefore must be done in CPU. However, we are working on it for the next AmanithVG rasterizer, so I'm keeping my eyes ope…
I believe Vello does this for AA (though I can't find the source now), and it's very fast, running on the GPU via compute shaders.