Do you not have a website for this sort of thing? honestly group-buy projects need structure to manage so you can get thousands of dollars instead of hundreds for doing the same work.

2008/9/2 bulia byak <buliabyak@...400...>:

On Tue, Sep 2, 2008 at 5:34 PM, <J.B.C.Engelen@...1578...> wrote:

...

Is this tool a sort of path-along-path with variable width?

Yes, and editable per node in node tool. Should be relatively easy to do with our LPEs. We already have a choice fixed profiles (triangle, ellipse etc) in Pen/Pencil tools.

So, what is the prize? :)

-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

---

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Tue, Sep 2, 2008 at 8:14 PM, Maximilian Albert <Anhalter42@...173...> wrote:

How do you plan to store the per-node information and retain it when the path is modified (especially with "simplify" and such, but also when nodes are inserted/deleted)? It can't be part of the LPE itself since it's path-specific.

Why, it can, it will be just a path-specific LPE, automatically constructed for each path and edited by node tool. I think we will need to store widths not per node, but as a list of length along path/width pairs, with length measured in percentages of the total length of subpath; this way it will be easily preserved during simplify and add/delete nodes. Such a profile will also be easily shareable to other paths, which may make perfect sense, even if their node composition is quite different.

Actually, now that I think of it, why tie this thing to nodes at all? Just provide a shortcut in the Node tool which would find out the point on path over which you're hovering your mouse (which may be a node, or a segment between nodes - does not matter), and adjust width up or down for that point. Even better and more generic! This way you will be able to fully edit profiles that were copy/pasted from another path and whose maxima/minima points do not coincide with your path's nodes.

The only gotcha is that we need some flexibility in the LPE in the algorithm which takes the length/width input and adjusts the list. For example, if you have width 1 at length 0.5 and request it to make width 2 at length 0.501, you will get a sharp hike, which is most likely not what the user wants. So, the algorithm must check if there already is a point "close enough" (definition may vary) to the requested point; if there is, change that point without adding a new one. If however a width change is requested "far enough" from the existing points, a new point is added to the list. At leadt, that should be the default behavior; later we may add some other shortcut which would allow us to add sharp width changes if necessary.

And finally, for the actual profile shape I think we should use a Spiro path for extra smoothness and natural flow. However, if we want to eventually support sharp width changes, we will need to store for each point its type - whether it is a smooth Spiro point or a cusp point.

bulia byak schrieb:

I think we will need to store widths not per node, but as a list of length along path/width pairs, with length measured in percentages of the total length of subpath

That's an excellent idea. Since I had something like Pajarico's other suggestion in mind (see different email), I was thinking about how to store per-node information. But separating the width info from nodes and storing it in the described way will make the LPE very powerful and flexible.

And finally, for the actual profile shape I think we should use a Spiro path for extra smoothness and natural flow. However, if we want to eventually support sharp width changes, we will need to store for each point its type - whether it is a smooth Spiro point or a cusp point.

I'm not sure if I understand you correctly here (in particular: what do you mean by "profile shape"?), but why not apply the LPE to any path whatsoever? The 2geom routines are flexible enough to make this possible. If you want it to be on top of a spiro path, just use LPE stacking.

Max

john cliff schrieb:

2008/9/3 Maximilian Albert <Anhalter42@...173... mailto:Anhalter42@...173...>

bulia byak schrieb:

 > I think we will need to store widths not per node, but as a list of
 > length along path/width pairs, with length measured in percentages
 > of the total length of subpath

That's an excellent idea. Since I had something like Pajarico's other
suggestion in mind (see different email), I was thinking about how to
store per-node information. But separating the width info from nodes and
storing it in the described way will make the LPE very powerful and
flexible.

Its an excellent idea until you make any change that substantially alters the path length, at which point all your widths 'slide' along the path when you didnt want them to...

Good point. An ad-hoc [1] correction could be to store the info in a way that more closely follows 2geom's way of storing path data. Namely, when we think of the path as parametrized by time, each node is on an integer time value. I.e., the initial node is at t=0, the next one at t=1 and so on. Thus a length-along-path value of 1.8 would represent a location on the segment between the second and third node (closer to the latter). This representation is much less susceptible to length adjustments and we can deal with node insertion/deletion more easily.

Still, since we need to catch events like node insertion/deletion and perform additional calculations for paths which have calligraphic LPE applied (as opposed to "regular" paths), I feel it might be worthwhile to encapsulate such paths in a separate SPItem. I don't know whether this is true but I thave the feeling that this would make the implementation more robust and extensible; any opinions from experts?

Max

[1] Disclaimer: I haven't thought about it deeply; maybe it has flaws in some other respect.

bulia byak wrote:

On Wed, Sep 3, 2008 at 3:54 PM, Maximilian Albert <Anhalter42@...173...> wrote:

...

Good point. An ad-hoc [1] correction could be to store the info in a way that more closely follows 2geom's way of storing path data. Namely, when we think of the path as parametrized by time, each node is on an integer time value. I.e., the initial node is at t=0, the next one at t=1 and so on. Thus a length-along-path value of 1.8 would represent a location on the segment between the second and third node (closer to the latter). This representation is much less susceptible to length adjustments and we can deal with node insertion/deletion more easily.

I'm not excited about this. I would like to eliminate any binding to nodes completely. Nodes are awkward legacy, they should be hidden and not affect anything. All new tools we've been adding recently go in this direction: Tweak tool does not care about nodes; Spiros use nodes but they are much less clumsy than bezier nodes and easier to move around; Alt-drag node sculpting works best when you just have as many nodes as possible, ideally eliminating any difference between node and internode segment; etc.

Nodes are awkward legacy? I understand what you're talking about when it comes to tools hiding how they work... but I guess I'm trying to picture how the Live Pen would work when editing a "stroke" after the fact if one is not looking at nodes. Will there be on-canvas guides or helper paths (or something to that effect)?

As for bezier nodes being clumsy... Are you referring to click-dragging new nodes withe the bezier tool? If so, I'm with you... if that's not what you're talking about, would you please elaborate? Other than occasionally using the tablet to get an organic hand stroke, I create over 90% of my illustrations using the bezier tool to plot my nodes (with no dragging) and the node tool to tweak the nodes & handles. So I'm just kind of scared of the dissing of nodes that you're doing. ;)

I guess I look at this in a way that if I were to use this Live Pen tool, I would probably expect it to be tied to visual nodes... in the same way that on-canvas gradient editing works. Then again, my mindset and workflow is probably more along the lines of a technical illustrator, and as mentioned above I could see it potentially working with helper paths of some sort instead

-Josh.

On Wed, Sep 3, 2008 at 3:20 PM, john cliff <john.cliff@...400...> wrote:

Its an excellent idea until you make any change that substantially alters the path length, at which point all your widths 'slide' along the path when you didnt want them to...

Often, this is more or less what you need anyway. It's for artistic use more than technical, and artistic curves have few cusps, and when they do, it's less important where exactly are they and whether they are exactly coordinated with changes in the width. In any case, with width adjustable at any point, you can always tweak the shape back into what you want. Also, the LPE can provide special calls for inserting/deleting segments on the path, which would shift all points so that those length/width pairs that are not affected remain physically where they are; for example, Pen tool can use it when it continues an existing variable-width path.

On Wed, Sep 3, 2008 at 3:15 PM, Maximilian Albert <Anhalter42@...173...> wrote:

...

And finally, for the actual profile shape I think we should use a Spiro path for extra smoothness and natural flow. However, if we want to eventually support sharp width changes, we will need to store for each point its type - whether it is a smooth Spiro point or a cusp point.

I'm not sure if I understand you correctly here (in particular: what do you mean by "profile shape"?),

It's the pattern path stretched along the skeleton path. It is generated automatically from the list of length/width pairs. I was just saying that the best way to do this generation is to let a Spiro go through the points, each point corresponding to one length/width pair.

but why not apply the LPE to any path whatsoever? The 2geom routines are flexible enough to make this possible. If you want it to be on top of a spiro path, just use LPE stacking.

Of course. For arbitrary profile paths, we have the regular Pattern on Path LPE. But this one is just a specialization of that, it stores a list of length/width pairs, not the profile path itself, and regenerates the profile path when this data changes.

On Tuesday 02 September 2008, bulia byak wrote:

On Tue, Sep 2, 2008 at 5:34 PM, <J.B.C.Engelen@...1578...> wrote:

...

Is this tool a sort of path-along-path with variable width?

Yes, and editable per node in node tool. Should be relatively easy to do with our LPEs.

One open-sourced implementation can be found in Synfigstudio already, for those new to synfig, it's described at the bottom of http://synfig.org/Creating_Shapes While Synfig is still less stable than Inkscape, it has some very nice features that are great for stills as well.

Daniel