It's not area calculation that causes minification problems. It's the need to account for arbitrary numbers of Bézier curves per pixel. There's also the requirement for dynamic polygon dilation so ensure that pixels near curve extrema are antialiased correctly at all scales.
-
-
Replying to @EricLengyel @batmansmk and
It sums exact-area calculation for all line segments, similar to Pathfinder 3 and font-rs (and libart before then). Right now it's flattening Bézier to lines on CPU, but I want to move that to GPU, using my new near-optimum flattening algorithm.
1 reply 0 retweets 3 likes -
Replying to @raphlinus @EricLengyel and
Piet-metal is at heart a software renderer that happens to be running on GPU, as a compute kernel. It has little resemblance to Loop-Blinn or any other technique running in the rasterization pipeline (nor their performance and quality issues).
1 reply 0 retweets 2 likes -
Replying to @raphlinus @batmansmk and
When you say flattening, does that mean calculating a straight line inside a pixel's footprint? Am I correct in concluding that rendering text in a 3D environment (where glyph size and perspective could be changing at 60 fps) is not one of your design goals?
1 reply 0 retweets 0 likes -
Replying to @EricLengyel @batmansmk and
Flattening just means converting to polyline (given a tolerance). Being able to animate glyph size (and variable font params) at 60fps is absolutely a goal (which is the main reason this needs to move to GPU), but for now 3D is not a major focus of mine.
1 reply 0 retweets 2 likes -
Replying to @raphlinus @EricLengyel and
My flattening algorithm is kinda good, see https://raphlinus.github.io/graphics/curves/2019/12/23/flatten-quadbez.html …. I have this working for cubic Béziers too (demo at https://levien.com/tmp/flatten.html …) but haven't written that up yet.
2 replies 1 retweet 4 likes -
Replying to @raphlinus @EricLengyel and
I'm also looking at using Green's Theorem to do per-pixel exact area on quadratic Béziers, but not sure yet whether that's a win compared with going through polyline first.
1 reply 0 retweets 1 like -
Replying to @raphlinus @batmansmk and
So right now, is your compute shader basically running a conventional scan-line algorithm on a bunch of polylines and writing to multiple pixels in the same GPU thread?
1 reply 0 retweets 0 likes -
Replying to @EricLengyel @batmansmk and
This is going to be hard to fit into tweets. No, it's got a pass making a command list per tile, then a render pass that runs those commands for all pixels in the (16x16) tile. To fill a shape, there's one command per line segment (accumulating signed based on exact-area... 1/3
1 reply 0 retweets 2 likes -
Replying to @raphlinus @EricLengyel and
...calculation), then a command that converts the signed area into an alpha value for blending. Currently each thread computes 1 pixel, and currently all pixels in the tile do the same computation; in this way it's a lot like Nehab&Hoppe. But I'm going to tweak both of... 2/3
1 reply 0 retweets 0 likes
...those based on some experiments showing some potential gains. Another major goal is to do blend groups and soft masks in the compute kernel, avoiding memory bandwidth costs for overdraw. Spinel is one of the main insipirations for those ideas. 3/3
-
-
Replying to @raphlinus @EricLengyel and
My conclusion: nowadays cool devs doing cool stuff with fonts are all doing it on the GPU :)
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.