Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I've done a library for vector graphics on the GPU which works pretty well for my uses:
https://github.com/audulus/vger
and a rust version:
https://github.com/audulus/vger-rs
(which powers my rust GUI library: https://github.com/audulus/rui)
Here's the approach for rendering path fills. From the readme:
> The bezier path fill case is somewhat original. To avoid having to solve quadratic equations (which has numerical issues), the fragment function uses a sort-of reverse Loop-Blinn. To determine if a point is inside or outside, vger tests against the lines formed between the endpoints of each bezier curve, flipping inside/outside for each intersection with a +x ray from the point. Then vger tests the point against the area between the bezier segment and the line, flipping inside/outside again if inside. This avoids the pre-computation of Loop-Blinn, and the AA issues of Kokojima.
It works pretty well, and doesn't require as much preprocessing as the code in the article. Also doesn't require any GPU compute (though I do use GPU compute for some things). I think ultimately the approach in the article (essentially Piet-metal, aka tessellating and binning into tiles) will deliver better performance, and support more primitives, but at greater implementation complexity. I've tried the Piet-metal approach myself and it's tricky! I like the simpler Shadertoy/SDF inspired approach :)
Signed distance fields only work well for relatively simple characters.
If you have highly detailed characters like Chinese or emojis, you need larger resolution to faithfully represent every detail. One way to get around excessive memory requirements is to store the characters in their default vector forms and only render the required characters on demand, but then you might as well render them at the required pixel resolution and do away with the additional complexity of SDF rendering.
SDFs are still useful though if you have to render text at many different resolutions, for example on signs in computer games, as seen in the original paper https://steamcdn-a.akamaihd.net/apps/valve/2007/SIGGRAPH2007...
In the past, SDFs also had problems with sharp corners, which has been solved in https://github.com/Chlumsky/msdfgen
You can approximate the Bézier curves with circular arcs and store those in the "SDF" instead. https://github.com/behdad/glyphy
GPU vector graphics library I released a few years ago: https://github.com/styluslabs/nanovgXC - basically a new backend for nanovg that supports arbitrary paths. Coverage calculation (for analytic antialiasing) is explained a bit here: https://github.com/styluslabs/nanovgXC/blob/master/src/nanov...
I've done a library for vector graphics on the GPU which works pretty well for my uses:
https://github.com/audulus/vger
and a rust version:
https://github.com/audulus/vger-rs
(which powers my rust GUI library: https://github.com/audulus/rui)
Here's the approach for rendering path fills. From the readme:
> The bezier path fill case is somewhat original. To avoid having to solve quadratic equations (which has numerical issues), the fragment function uses a sort-of reverse Loop-Blinn. To determine if a point is inside or outside, vger tests against the lines formed between the endpoints of each bezier curve, flipping inside/outside for each intersection with a +x ray from the point. Then vger tests the point against the area between the bezier segment and the line, flipping inside/outside again if inside. This avoids the pre-computation of Loop-Blinn, and the AA issues of Kokojima.
It works pretty well, and doesn't require as much preprocessing as the code in the article. Also doesn't require any GPU compute (though I do use GPU compute for some things). I think ultimately the approach in the article (essentially Piet-metal, aka tessellating and binning into tiles) will deliver better performance, and support more primitives, but at greater implementation complexity. I've tried the Piet-metal approach myself and it's tricky! I like the simpler Shadertoy/SDF inspired approach :)
I've done a library for vector graphics on the GPU which works pretty well for my uses:
https://github.com/audulus/vger
and a rust version:
https://github.com/audulus/vger-rs
(which powers my rust GUI library: https://github.com/audulus/rui)
Here's the approach for rendering path fills. From the readme:
> The bezier path fill case is somewhat original. To avoid having to solve quadratic equations (which has numerical issues), the fragment function uses a sort-of reverse Loop-Blinn. To determine if a point is inside or outside, vger tests against the lines formed between the endpoints of each bezier curve, flipping inside/outside for each intersection with a +x ray from the point. Then vger tests the point against the area between the bezier segment and the line, flipping inside/outside again if inside. This avoids the pre-computation of Loop-Blinn, and the AA issues of Kokojima.
It works pretty well, and doesn't require as much preprocessing as the code in the article. Also doesn't require any GPU compute (though I do use GPU compute for some things). I think ultimately the approach in the article (essentially Piet-metal, aka tessellating and binning into tiles) will deliver better performance, and support more primitives, but at greater implementation complexity. I've tried the Piet-metal approach myself and it's tricky! I like the simpler Shadertoy/SDF inspired approach :)