Haven't measured. If you keep re-rendering text, then probably not.
-
-
Replying to @EricLengyel @batmansmk and
The piet-metal algorithms will probably be similarly fast and high quality, and will be open source, but I haven't seriously started in on font rendering yet. Also Pathfinder 3 is up there.
1 reply 0 retweets 0 likes -
Replying to @raphlinus @batmansmk and
There are situations in which many approaches break down rather badly, but they’re largely ignored until you see the failure case. For example, most algorithms don’t handle minification well and thus have aliasing problems in 3D environments. Claims of quality are often oversold.
1 reply 0 retweets 1 like -
Replying to @EricLengyel @batmansmk and
Both piet-metal and Pathfinder 3 do exact-area calculation, and don't depend on hardware for antialiasing. Also, piet-metal pays special attention to doing alpha blending in a linear color space. My goals include better quality than people currently expect.
1 reply 0 retweets 2 likes -
Replying to @raphlinus @batmansmk and
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.
2 replies 0 retweets 2 likes -
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
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.
-
-
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 - 3 more replies
New conversation -
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.