This doesn’t look resolution independent. Is there a reason for that?
-
-
-
Replying to @mrdoob
It’s breaking down curves into small lines, not keeping them as curves.
1 reply 0 retweets 0 likes -
Replying to @pcwalton
Oh, right. We'll cross that bridge when we come to it. For now, there is a ton of SVG spec to support.
1 reply 0 retweets 1 like -
@pcwalton this is useful for generating geometries. For resolution independent rendering, the conversion to the following approach shouldn't be difficult. https://threejs.org/examples/webgl_shaders_vector.html …1 reply 0 retweets 2 likes -
Replying to @BlurSpline @mrdoob
Interesting, looks like you’re tessellating the convex hulls. Is that a constrained Delaunay triangulation?
1 reply 0 retweets 0 likes -
Looks like it’s modified ear-clipping, based onhttps://github.com/mapbox/earcut
1 reply 0 retweets 0 likes -
Ah. That’s O(n^2) and won’t handle self-intersecting paths, which are extremely common in the real world :(
2 replies 0 retweets 0 likes -
It's much faster than O(n^2) in practice (because of hashed lookups). About 7–8x faster than libtess for us, while being more resilient. For self-intersections, while we handle that by preprocessing on the server, I'm working on a client-side "fixing" libhttps://github.com/mapbox/polysnap
1 reply 0 retweets 0 likes -
Why not do trapezoidation instead? In my tests, Pathfinder’s tessellator outperformed earcut by a lot, while simultaneously needing nothing special to handle self intersections.
3 replies 0 retweets 0 likes
Looking at polysnap, that’s sort of doing what Pathfinder does, but polysnap is probably slower because Pathfinder can bubble sort the active edge list to detect intersections on the fly without needing a prepass.
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.