Bulia, this morning there was another path parsing bug in the tracker and so there is another patch.
I have a path parsing question that I do not think is answered by the svg spec.
All commands may be followed by any number of sets of parameters. So L0,0 3,4 7,2 is actually L0,0 L3,4 L7,2 Moveto implies Lineto. So M0,0 3,4 7,2 is actually M0,0 L3,4 L7,2
How should one interpret this: L0,0 L3,4 L7,2 Z 1,5
It would seem to me that it should be L0,0 L3,4 L7,2 Z M0,0 L1,5
Because Moveto implies Lineto and Closepath should imply Moveto because the spec says that any following commands begin a new subpath at the previous subpaths initial point.
Answers?
Aaron Spike
aaron@...749... wrote:
How should one interpret this: L0,0 L3,4 L7,2 Z 1,5
It would seem to me that it should be L0,0 L3,4 L7,2 Z M0,0 L1,5
Of course, what I really meant was this.
How should one interpret this: M0,0 L3,4 L7,2 Z 1,5
It would seem to me that it should be M0,0 L3,4 L7,2 Z M0,0 L1,5
Aaron Spike
On 5/13/05, aaron@...749... <aaron@...749...> wrote:
Bulia, this morning there was another path parsing bug in the tracker and so there is another patch.
Heh, you seem to attract them :) Thanks, committed.
How should one interpret this: L0,0 L3,4 L7,2 Z 1,5
I think it's just invalid. Both Batik and Adobe complain on this and render nothing.
Because Moveto implies Lineto and Closepath should imply Moveto because the spec says that any following commands begin a new subpath at the previous subpaths initial point.
Well, that seems far-fetched to me. Z does not "imply" moveto, it just starts a new subpath in the current point.
I just had an idea for an extension that you might be interested in: blending paths. As you already have all the code for parsing and writing paths in your Python extensions, and since you can borrow the blending algorithm from Skencil (which is itself in Python), I think it would be easy for you - and very useful until we have a "proper" internal implementation of blends (which requires a lot of work).
bulia byak wrote:
I think it's just invalid. Both Batik and Adobe complain on this and render nothing.
Then I'll leave it alone.
I just had an idea for an extension that you might be interested in: blending paths. As you already have all the code for parsing and writing paths in your Python extensions, and since you can borrow the blending algorithm from Skencil (which is itself in Python), I think it would be easy for you - and very useful until we have a "proper" internal implementation of blends (which requires a lot of work).
Sounds fun. Though it might be greatly beyond my mathematical powers. I'll look for tho code in skencil. Can I get a proper definition of what blend really means graphically? Is it like the in between effects of animating path data like in Beez?
Aaron Spike
bulia byak wrote:
How should one interpret this: L0,0 L3,4 L7,2 Z 1,5
I think it's just invalid. Both Batik and Adobe complain on this and render nothing.
Of course this example is also invalid because it doesn't begin with a moveto. I corrected myself in a follow up message that hasn't come through quite yet.
Aaron Spike
bulia byak wrote:
I just had an idea for an extension that you might be interested in: blending paths. As you already have all the code for parsing and writing paths in your Python extensions, and since you can borrow the blending algorithm from Skencil (which is itself in Python), I think it would be easy for you - and very useful until we have a "proper" internal implementation of blends (which requires a lot of work).
Ok, there is something called "interpolate" in my latest effects package. I decided not to use/or read any code from Skencil. It may or may not work. I may make a few variations if there are some suggestions. But this just isn't going to be as cool until the internal implementation comes along and makes "live" blends.
Give it a try and let me know what you think.
Aaron Spike
On 5/14/05, aaron@...749... <aaron@...749...> wrote:
Ok, there is something called "interpolate" in my latest effects package. I decided not to use/or read any code from Skencil. It may or may not work. I may make a few variations if there are some suggestions. But this just isn't going to be as cool until the internal implementation comes along and makes "live" blends.
Thanks!!! That was fast :)
Actually it's hard to say how well your interpolation works, because it only produces one intermediate path. Can you take the number of steps as a parameter, and create the specified number of equidistant steps? Then it will be easy to see how good is your algorithm based on how smooth and natural is the transition.
Still I noticed one problem: load the attached file, select the left and then right path, and interpolate at 0.9. The result is close to the left path but only half as long, the bottom half is missing.
bulia byak wrote:
Actually it's hard to say how well your interpolation works, because it only produces one intermediate path. Can you take the number of steps as a parameter, and create the specified number of equidistant steps? Then it will be easy to see how good is your algorithm based on how smooth and natural is the transition.
Absolutely, that was one variation I thought of. I will do this right away. Interpolation Time will only mater if the number of steps is set to 1.
Still I noticed one problem: load the attached file, select the left and then right path, and interpolate at 0.9. The result is close to the left path but only half as long, the bottom half is missing.
Have you tried blend groups in Skencil? I played with it for a few minutes to see what it was you were talking about. Skencil truncates the interpolation at the shortest path. I don't like it either. But it made sense to me because of the requirements for animating "d" attributes of SVG paths. SVG requires that the source and destination path data contain the same number of segments and have the same commands in the same positions. (At least that is what I remember from when I last checked but that was a few years ago when I was editing SVG exclusively in notepad.exe.) This first draft interpolator one ups that requirement and works even if the segments aren't the same type (though it ignores A and Q nodes for the time being). I would be happy to make this work with paths of varrying lengths but I will need some help thinking up the best way to do it. Suggestions (and patches) welcome. :)
Aaron Spike
aaron@...749... wrote:
bulia byak wrote:
Actually it's hard to say how well your interpolation works, because it only produces one intermediate path. Can you take the number of steps as a parameter, and create the specified number of equidistant steps? Then it will be easy to see how good is your algorithm based on how smooth and natural is the transition.
Absolutely, that was one variation I thought of. I will do this right away. Interpolation Time will only mater if the number of steps is set to 1.
Done.
Aaron Spike
Very cool aaron, seems to work well. good to see the potential of extensions already being exploited.
--- aaron@...749... wrote:
aaron@...749... wrote:
bulia byak wrote:
Actually it's hard to say how well your interpolation works,
because
it only produces one intermediate path. Can you take the number of steps as a parameter, and create the specified number of
equidistant
steps? Then it will be easy to see how good is your algorithm
based on
how smooth and natural is the transition.
Absolutely, that was one variation I thought of. I will do this
right
away. Interpolation Time will only mater if the number of steps is
set
to 1.
Done.
Aaron Spike
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
On 5/14/05, aaron@...749... <aaron@...749...> wrote:
aaron@...749... wrote:
bulia byak wrote:
Actually it's hard to say how well your interpolation works, because it only produces one intermediate path. Can you take the number of steps as a parameter, and create the specified number of equidistant steps? Then it will be easy to see how good is your algorithm based on how smooth and natural is the transition.
Absolutely, that was one variation I thought of. I will do this right away. Interpolation Time will only mater if the number of steps is set to 1.
Done.
Thanks, works excellent - though only for equal-nodes paths. To equalize the number of nodes, I would try this:
1 find which path has less nodes
2 on that path's memory copy, find which nodes are farthest apart, and divide the line or curve between them in two (see sp_nodepath_line_midpoint for the formula)
3 repeat 2 until the paths have the same number of nodes, then interpolate
The distance between nodes in 2 is ideally calculated as "distance along path", here's the formula: http://www.cit.gu.edu.au/~anthony/info/graphics/bezier.curves
On 5/14/05, bulia byak <buliabyak@...400...> wrote:
The distance between nodes in 2 is ideally calculated as "distance along path", here's the formula: http://www.cit.gu.edu.au/~anthony/info/graphics/bezier.curves
Actually, for the purpose of comparing lengths, you don't need all that math. Just sum the length of both Bezier handles that define the segment, plus the distance between the ends of these handles (in other words, sum the three of the four sides of the quadrilateral into which the bezier curve is inscribed). This is a good first approximation of the curve length, at least it should be sufficient for comparing lengths of segments.
bulia byak wrote:
On 5/14/05, bulia byak <buliabyak@...400...> wrote:
The distance between nodes in 2 is ideally calculated as "distance along path", here's the formula: http://www.cit.gu.edu.au/~anthony/info/graphics/bezier.curves
Actually, for the purpose of comparing lengths, you don't need all that math. Just sum the length of both Bezier handles that define the segment, plus the distance between the ends of these handles (in other words, sum the three of the four sides of the quadrilateral into which the bezier curve is inscribed). This is a good first approximation of the curve length, at least it should be sufficient for comparing lengths of segments.
I'm sure that would be faster and I may have to resort to it. I think that website leaves something to be desired. At least it does for me.
As far as I can tell the code in the Gravensen approximation does not implement what the description says. It is basically what you describe above.
The code in the Simpson method uses a point2d struct right in an equation. Since I don't know C, I don't know exactly what that means, but it seems to be nonsense. And now that I have something implmented It tries to sqrt a negative number in the "balf" function. I don't know enough math to figure out how the implementation is wrong.
So I think I will do just as you suggest. I still wouldn't mind having a good bezier arc length function sitting around for use in future projects. So if anyone would be willing to take a look at my Simpson approximation code and tell me what is wrong, I would much appreciate it.
Oh, and did you try the interpolation extension with paths of multiple subpaths?
Aaron Spike
On 5/14/05, aaron@...749... <aaron@...749...> wrote:
I'm sure that would be faster and I may have to resort to it. I think that website leaves something to be desired. At least it does for me.
Sorry, it wasn't that I recommended that site specifically, I just did a quick googling and gave you the first one which seemed to contain all the math and code. You might try to google up something better.
Also we have curve length code somewhere deep in livarot/, but it's not trivial to find it there.
So I think I will do just as you suggest. I still wouldn't mind having a good bezier arc length function sitting around for use in future projects. So if anyone would be willing to take a look at my Simpson approximation code and tell me what is wrong, I would much appreciate it.
Yes, especially remembering that sometime someone will convert your Python into C++ for the proper internal implementation. It's wonderful to have the extensions thing as a quick testbed for ideas that can be used even by those who don't know Inkscape code.
Oh, and did you try the interpolation extension with paths of multiple subpaths?
Yes, so long as the number of nodes is the same, works fine.
bulia byak wrote:
On 5/14/05, aaron@...749... <aaron@...749...> wrote:
So I think I will do just as you suggest. I still wouldn't mind having a good bezier arc length function sitting around for use in future projects. So if anyone would be willing to take a look at my Simpson approximation code and tell me what is wrong, I would much appreciate it.
Yes, especially remembering that sometime someone will convert your Python into C++ for the proper internal implementation. It's wonderful to have the extensions thing as a quick testbed for ideas that can be used even by those who don't know Inkscape code.
Oooh, scary. They'll have a little optimization to do, I think. And I couldn't agree more on the importance of the extension mechanism in this reguard. Its usefulness is compounded by the design that lets it be completely language agnostic. Much power. Huge Audience.
Oh, and did you try the interpolation extension with paths of multiple subpaths?
Yes, so long as the number of nodes is the same, works fine.
Please download the latest version. It should no longer have this limitation. Thanks for your help.
Aaron Spike
On 5/14/05, aaron@...749... <aaron@...749...> wrote:
Please download the latest version. It should no longer have this limitation. Thanks for your help.
Excellent, subdivision works now. Generally the results are very good, but there's one glitch illustrated by the attached file: the left path has 2 nodes and the right one 3, so the left one is subdivided, but interpolation gives wrong length and direction of the bezier handle at the bottom node near the left path (i.e. the points A and B have too different bezier handles, so there's a visible gap there). This may be caused by some error in the subdivision function (the top and middle nodes in the subdivied path seem to be OK, it's only the bottom one that is off).
bulia byak wrote:
On 5/14/05, aaron@...749... <aaron@...749...> wrote:
Please download the latest version. It should no longer have this limitation. Thanks for your help.
Excellent, subdivision works now. Generally the results are very good, but there's one glitch illustrated by the attached file: the left path has 2 nodes and the right one 3, so the left one is subdivided, but interpolation gives wrong length and direction of the bezier handle at the bottom node near the left path (i.e. the points A and B have too different bezier handles, so there's a visible gap there). This may be caused by some error in the subdivision function (the top and middle nodes in the subdivied path seem to be OK, it's only the bottom one that is off).
Ah yes, I see. I will look at that. Side note. I can't run the interpolate script on the file you sent me. It fails with an xml namespace error. strange.
Also opening an svg created on such a large screen makes me wonder. Could Inkscape be taught to open maximized if the window size stored in the document is larger than the screen? I find windows that are larger than my screen difficult to work with. I wonder if other people feel that way too.
Aaron Spike
On 5/15/05, aaron@...749... <aaron@...749...> wrote:
Ah yes, I see. I will look at that. Side note. I can't run the interpolate script on the file you sent me. It fails with an xml namespace error. strange.
Yes, same for me. Some Python parser error. Just copy/paste the two paths into a separate document and it works.
Also opening an svg created on such a large screen makes me wonder. Could Inkscape be taught to open maximized if the window size stored in the document is larger than the screen? I find windows that are larger than my screen difficult to work with. I wonder if other people feel that way too.
Usually I just doubleclick the window titlebar, problem solved :)
But I agree that this might be a useful tweak. Could you please file a RFE for it.
bulia byak wrote:
Usually I just doubleclick the window titlebar, problem solved :)
I learned a new trick, thanks.
Well that was just a typo. It is amazing what one character can do. http://www.ekips.org/comp/inkscape/inx/interpbug.png
Aaron Spike
I lost a week trying to wrap my head around a proper method of approximating arc length. But I now have a prototype of the smoother path blending method that Bulia suggested on IRC last weekend. It might even work. (At least it doesn't seem to raise any exceptions.)
Bulia please try it out and let me know if it does what you suggested.
In the Interpolate dialog, method 1 is the old method of splitting the smaller path until it has the same number of segments as the larger. Method 2 divides both paths so that the length (relative to the whole) of corresponding segments is equal.
Aaron Spike
On 5/23/05, aaron@...749... <aaron@...749...> wrote:
I lost a week trying to wrap my head around a proper method of approximating arc length. But I now have a prototype of the smoother path blending method that Bulia suggested on IRC last weekend. It might even work. (At least it doesn't seem to raise any exceptions.)
Bulia please try it out and let me know if it does what you suggested.
Thank you, it works perfectly as I imagined it to, and gives much better results overall than the old method, with no unexplicable stretches of twists. Just what a human designer would draw as an interpolation without knowing where the nodes are. So I think we can just remove method 1 (unless someone prefers it, of course).
The only bad news is that I then tried Xara and found that it apparently uses the same algorithm 2. And I thought I invented something new :)
Now, for total happiness, the only thing missing is non-linear interpolation. Don't worry, it's easy :) Just rename the "Interpolation Time" parameter into "Exponent", with the default of 0, and use the formula
power = exponent >= 0? (1 + exponent) : 1/(1 - exponent)
effective_t = real_t ^ power
where real_t is the actual interpolation value for a given step (e.g. 1/20 for the first step of a 20-step blend), measured from 0 to 1; and effective_t is the value which you will use in the interpolating formulas instead of real_t for that step. The exponent of 0 gives linear interpolation (same as now); positive exponents shift the blend towards one of the paths, negative ones towards the other.
bulia byak wrote:
Thank you, it works perfectly as I imagined it to, and gives much better results overall than the old method, with no unexplicable stretches of twists. Just what a human designer would draw as an interpolation without knowing where the nodes are. So I think we can just remove method 1 (unless someone prefers it, of course).
Well, I'm no designer but I find the unexplicable stretches and twists to be visually interesting, so I think I will leave method one for now unless someone puts up a pretty hefty fight. But if I am going to leave it, the difference should probably be explained. I think this might best be done by adding the possibility of slightly longer explanitory paragraphs on the effect dialog. I think other effects could benefit from that also.
Now, for total happiness, the only thing missing is non-linear interpolation. Don't worry, it's easy :) Just rename the "Interpolation Time" parameter into "Exponent", with the default of 0, and use the formula
That was very easy, just as you said. I made the change and uploaded the tarball again. I'm still wondering, what are reasonable upper and lower bounds for the exponent?
Before we commit to "total happieness" I'd like to take a look at blending styles. Some blending is probably impossible like belnding a linear gradient into a radial gradient. Other blending will be necessarily arbitrary. I'd love to hear ideas or oppinions that anyone has.
Lastly, on IRC this weekend I chatted with ScislaC. He is actually using this effects stuff for artistic purposes. :) Check out his deviantart page. He mentioned a desire to warp and bend the path blends to fill curvy shapes. He would probably have to explain himself. But if anyone has ideas for making that possible, I'd be happy to listen.
Aaron Spike
bulia byak wrote:
Thank you, it works perfectly as I imagined it to, and gives much better results overall than the old method, with no unexplicable stretches of twists. Just what a human designer would draw as an interpolation without knowing where the nodes are. So I think we
can
just remove method 1 (unless someone prefers it, of course).
aaron spike wrote:
Well, I'm no designer but I find the unexplicable stretches and twists to be visually interesting, so I think I will leave method one for now unless someone puts up a pretty hefty fight. But if I am going to
leave
it, the difference should probably be explained. I think this might
best
be done by adding the possibility of slightly longer explanitory paragraphs on the effect dialog. I think other effects could benefit from that also.
Yes, please do leave method one as well. It is great for when you need "less than mathematically perfect" results.
Lastly, on IRC this weekend I chatted with ScislaC. He is actually
using
this effects stuff for artistic purposes. :) Check out his deviantart page. He mentioned a desire to warp and bend the path blends to fill curvy shapes. He would probably have to explain himself. But if anyone has ideas for making that possible, I'd be happy to listen.
Yeah, this stuff is great! I have many plans for it artistically. To see my "test" with it it's at: http://www.deviantart.com/view/18498697/ (warning, not really, but slightly explicit)
First off, my example screenshot: http://www.scislac.com/inkscape/interp-guide.png. For the results, which is actually the top of the screenshot, I did a hack job using the "cut path" operation, which is undesirable because there is then loss of actual path data. The bottom has the guides I'd want to "warp" to, and since cutting was involved the top is only somewhat close to how it should turn out (as warping wouldn't actually remove any segment of the path).
So after talking with Aaron this weekend, his idea of warp is better than what my idea of "guided interpolation" was. I had originally asked if it would be possible to have "guides" that would influence the boundaries of the interpolation. The example would be you have two lines that are interpolated. The edges of all steps in between are dictated by the ends of the lines (giving straight edges to two sides of the interpolated shapes... well, specifically lines give that straight edge effect). I had asked if it was possible to make it so "guides" could give those straight edges curvature. The main hangup there is determining which are the guides and which are the objects to be interpolated. The only thing I could think of to remedy that would be to acknowledge the order of selection, using the last two selected as guides. Either way, just a general "warp to shape" would be more desirable over all as it wouldn't require the use of interpolation then.
Bulia or anyone else have any thoughts of how to accomplish a warp to shape or fill shape kind of effect? One great parameter to have would be to add a buffer zone/empty boundary from the guides that could be set with any of the regular units (so it didn't necessarily have to warp to the exact boundary/guide, but could do it w/ a 3px buffer from the guide for example). Additionally, if it would properly interact with both a path w/ subpaths or a groups of paths that would be desirable (unlike how all the Booleans require me to subpath more than one object of anything I want to work with).
-Josh
I was looking on Google to see what sort of warping effects exist. Warping with a mesh would give you ultimate control. But there isn't any way to do that with a scripting extension like I've been working with. It would have to be internal.
Aaron Spike
On Mon, 2005-05-23 at 14:07 -0500, aaron@...749... wrote:
I was looking on Google to see what sort of warping effects exist. Warping with a mesh would give you ultimate control. But there isn't any way to do that with a scripting extension like I've been working with. It would have to be internal.
Is the reason for this because you'd need on canvas handles?
--Ted
Ted Gould wrote:
On Mon, 2005-05-23 at 14:07 -0500, aaron@...749... wrote:
I was looking on Google to see what sort of warping effects exist. Warping with a mesh would give you ultimate control. But there isn't any way to do that with a scripting extension like I've been working with. It would have to be internal.
Is the reason for this because you'd need on canvas handles?
Yeah. You could probably do some sort of specialized deforms with numeric parameters. But to do something really cool you would need to have some sort of on canvas handles or mesh or bendable bezier bounding box. (I'm sure this would require a bunch of crazy math too.) Perhaps there will be a way to get this sort of input with the internal scripting interfaces.
Aaron Spike
participants (6)
-
unknown＠example.com -
aaron＠...749... -
bulia byak -
John Cliff -
Joshua A. Andler -
Ted Gould