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
Note that Pathfinder gains a lot of speed just by not having to break curves down into small lines, which adds a ton of vertices.
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.