Powerstroke presentation at LGM 2012
Hi all, Quick note to tell that I uploaded my presentation about Powerstroke on our wiki.
http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation
I'm sad I had to leave so early and had no time for the party :'( :'(
Ciao, Johan
On 05/08/2012 07:01 AM, jbc.engelen@...2592... wrote:
Hi all, Quick note to tell that I uploaded my presentation about Powerstroke on our wiki.
http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation
Any reference papers on the algorithms used in the Powerstroke implementation?
Johan (and others),
In looking at your slides I see that you added two new types of joins... how useful would these be to have as part of the SVG standard? I think the Extrapolated join might be easy to add; the Spiro less so.
Tav
On Tue, 2012-05-08 at 01:01 +0200, jbc.engelen@...2592... wrote:
Hi all, Quick note to tell that I uploaded my presentation about Powerstroke on our wiki.
http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation
I'm sad I had to leave so early and had no time for the party :'( :'(
Ciao, Johan
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Replying from phone, sorry if short. Extrapolated would rock imho. The segment limit the lpe uses is quite frustrating though when getting creative, otherwise it's really awesome.
Cheers, Josh On May 7, 2012 11:27 PM, "Tavmjong Bah" <tavmjong@...8...> wrote:
Johan (and others),
In looking at your slides I see that you added two new types ofjoins... how useful would these be to have as part of the SVG standard? I think the Extrapolated join might be easy to add; the Spiro less so.
TavOn Tue, 2012-05-08 at 01:01 +0200, jbc.engelen@...2592... wrote:
Hi all, Quick note to tell that I uploaded my presentation about Powerstroke
on our wiki.
http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation
I'm sad I had to leave so early and had no time for the party :'( :'(
Ciao, Johan
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2012-05-07 at 23:37 -0700, Josh Andler wrote:
Replying from phone, sorry if short. Extrapolated would rock imho. The segment limit the lpe uses is quite frustrating though when getting creative, otherwise it's really awesome.
We just discussed this at the SVG Working Face-to-face meeting (I called in). There is support for adding the extrapolated version to the spec. Two small hiccups... one, a couple people asked for the exact mathematical formula to use to find the curvature of the last point (could you supply this?), and two, current rendering libraries that browsers use don't support this so it would have to be added (or simulated via a fill). A miter limit would have to be included to prevent the join from getting too long.
Tav
On Tue, May 8, 2012 at 7:57 AM, Tavmjong Bah <tavmjong@...8...> wrote:
We just discussed this at the SVG Working Face-to-face meeting (I called in). There is support for adding the extrapolated version to the spec. Two small hiccups... one, a couple people asked for the exact mathematical formula to use to find the curvature of the last point (could you supply this?), and two, current rendering libraries that browsers use don't support this so it would have to be added (or simulated via a fill). A miter limit would have to be included to prevent the join from getting too long.
Johan would be the one who knows the math behind it. Hopefully he will chime in with it when he gets back from his business trip next week (he didn't expect to be online/available during it).
Related to support, in Inkscape it's currently simulated by a fill (since the lpe is an actual filled object).
The LPE does have a miter feature, but the interpolation method currently gets limited more quickly by the number of segments it uses for the calculation (I would like to see that number bumped up just a little, and leave it to miter to limit).
Cheers, Josh
On 8-5-2012 16:57, Tavmjong Bah wrote:
On Mon, 2012-05-07 at 23:37 -0700, Josh Andler wrote:
Replying from phone, sorry if short. Extrapolated would rock imho. The segment limit the lpe uses is quite frustrating though when getting creative, otherwise it's really awesome.
We just discussed this at the SVG Working Face-to-face meeting (I called in). There is support for adding the extrapolated version to the spec. Two small hiccups... one, a couple people asked for the exact mathematical formula to use to find the curvature of the last point (could you supply this?), and two, current rendering libraries that browsers use don't support this so it would have to be added (or simulated via a fill).
Nice to hear people are interested in powerstroke's feature that I am most proud of :-)
The extrapolation does not use the curvature of the path, but the path's direction instead. The direction of the path is then rotated 90 degrees to get the normal, which is then used to simply mirror the path itself to obtain the extrapolation. The direction is easily calculated from the derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); something like that must be already used to draw the standard SVG miter.
A word of caution: my method of extrapolating might be harder computationally than necessary. This mirroring+intersection was the first thing that popped in my head (*) when thinking up the extrapolation concept, but perhaps there are other easier and just as visually pleasing methods. I do not know how normal strokes are rendered, and have no clue of what is feasible in terms of computational effort. One of the responses to my presentation at LGM was to try and use the curvature of the path and extrapolate with circles. I have not yet tried this...
(*) well, actually, my first idea was to just take the values of the bezier curve beyond its normal [0..1] domain. But I remember that this didn't really work very intuitively if at all.
So... how do other programs draw thick stroked lines? Surely, I am not the first to think of this.
Cheers, Johan
On Thu, 2012-05-17 at 23:53 +0200, Johan Engelen wrote:
On 8-5-2012 16:57, Tavmjong Bah wrote:
On Mon, 2012-05-07 at 23:37 -0700, Josh Andler wrote:
Replying from phone, sorry if short. Extrapolated would rock imho. The segment limit the lpe uses is quite frustrating though when getting creative, otherwise it's really awesome.
We just discussed this at the SVG Working Face-to-face meeting (I called in). There is support for adding the extrapolated version to the spec. Two small hiccups... one, a couple people asked for the exact mathematical formula to use to find the curvature of the last point (could you supply this?), and two, current rendering libraries that browsers use don't support this so it would have to be added (or simulated via a fill).
Nice to hear people are interested in powerstroke's feature that I am most proud of :-)
The extrapolation does not use the curvature of the path, but the path's direction instead. The direction of the path is then rotated 90 degrees to get the normal, which is then used to simply mirror the path itself to obtain the extrapolation. The direction is easily calculated from the derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); something like that must be already used to draw the standard SVG miter.
Ah, this explains why my first attempt at creating a demo image didn't look quite right and when I used circular arcs it looked better. When there is a large change in the rate of curvature along a path I don't think mirroring give's the best looking results. I think you want to keep the curvature constant or even the first and second derivatives constant (although the latter would be tougher to implement). When I get a chance, I'll create some tests.
A word of caution: my method of extrapolating might be harder computationally than necessary. This mirroring+intersection was the first thing that popped in my head (*) when thinking up the extrapolation concept, but perhaps there are other easier and just as visually pleasing methods. I do not know how normal strokes are rendered, and have no clue of what is feasible in terms of computational effort. One of the responses to my presentation at LGM was to try and use the curvature of the path and extrapolate with circles. I have not yet tried this...
(*) well, actually, my first idea was to just take the values of the bezier curve beyond its normal [0..1] domain. But I remember that this didn't really work very intuitively if at all.
So... how do other programs draw thick stroked lines? Surely, I am not the first to think of this.
Hmm, anybody with other drawing programs to check? It could be that the PostScript standard became the de facto standard for this.
Tav
On 18-05-12 07:30, Tavmjong Bah wrote:
...
The extrapolation does not use the curvature of the path, but the path's direction instead. The direction of the path is then rotated 90 degrees to get the normal, which is then used to simply mirror the path itself to obtain the extrapolation. The direction is easily calculated from the derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); something like that must be already used to draw the standard SVG miter.
Ah, this explains why my first attempt at creating a demo image didn't look quite right and when I used circular arcs it looked better. When there is a large change in the rate of curvature along a path I don't think mirroring give's the best looking results. I think you want to keep the curvature constant or even the first and second derivatives constant (although the latter would be tougher to implement). When I get a chance, I'll create some tests.
Keeping both the first and second derivatives constant would indeed be hard (as in, impossible in general), but keeping their magnitude constant might be doable. In fact, this is probably equivalent to keeping the curvature constant. If I am not mistaken (with at least Wikipedia to back me up), the curvature can be defined as the magnitude of the second derivative in the arc-length parametrization.
Now, if you keep the magnitude of the first derivative the same, then you're essentially using a (scaled) arc-length parametrization. So if you then also keep the magnitude of the second derivative the same, then you're keeping the curvature the same. (Similarly, if you keep the curvature the same, there should be a parametrization such that, etc., etc.)
Assuming you use the above or some other (direct) formula to find the curvature at the end, extending the curve with constant curvature is then relatively easy. It will be a circle arc with radius 1/K (with K the curvature). The center of the circle is easy to find (normal to the curve at a distance of 1/K). You then just need to find the intersection with the other side (which is just a matter of intersecting two circles and choosing between two intersection points) and figure out a way to encode the result (but you're probably doing this all with SBasis curves anyway, so that shouldn't really be a problem). If you need more details, just ask.
On Fri, 2012-05-18 at 10:18 +0200, Jasper van de Gronde wrote:
On 18-05-12 07:30, Tavmjong Bah wrote:
...
The extrapolation does not use the curvature of the path, but the path's direction instead. The direction of the path is then rotated 90 degrees to get the normal, which is then used to simply mirror the path itself to obtain the extrapolation. The direction is easily calculated from the derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); something like that must be already used to draw the standard SVG miter.
Ah, this explains why my first attempt at creating a demo image didn't look quite right and when I used circular arcs it looked better. When there is a large change in the rate of curvature along a path I don't think mirroring give's the best looking results. I think you want to keep the curvature constant or even the first and second derivatives constant (although the latter would be tougher to implement). When I get a chance, I'll create some tests.
Keeping both the first and second derivatives constant would indeed be hard (as in, impossible in general), but keeping their magnitude constant might be doable. In fact, this is probably equivalent to keeping the curvature constant. If I am not mistaken (with at least Wikipedia to back me up), the curvature can be defined as the magnitude of the second derivative in the arc-length parametrization.
Now, if you keep the magnitude of the first derivative the same, then you're essentially using a (scaled) arc-length parametrization. So if you then also keep the magnitude of the second derivative the same, then you're keeping the curvature the same. (Similarly, if you keep the curvature the same, there should be a parametrization such that, etc., etc.)
Assuming you use the above or some other (direct) formula to find the curvature at the end, extending the curve with constant curvature is then relatively easy. It will be a circle arc with radius 1/K (with K the curvature). The center of the circle is easy to find (normal to the curve at a distance of 1/K). You then just need to find the intersection with the other side (which is just a matter of intersecting two circles and choosing between two intersection points) and figure out a way to encode the result (but you're probably doing this all with SBasis curves anyway, so that shouldn't really be a problem). If you need more details, just ask.
My brain was obviously still sleeping when I replied... substitute second derivative for first derivative and third derivative for second in my last email. And I meant an 'or' instead of an 'and'. In other words, the simplest thing to do is to use the curvature at the end of the line to extend the curve; a perhaps better, but more difficult option, is to instead use the derivative of the curvature.
participants (6)
-
unknown＠example.com -
Jasper van de Gronde -
Johan Engelen -
Josh Andler -
Just Fill Bugs -
Tavmjong Bah