Hey all,
Sorry, I've been effectively offline for over a week, so I'm catching up. I feel like I'm spamming the mailing lists :)
Anyway, Aaron, I noticed that you made a branch for live effects. I've thought I little about this -- I was thinking perhaps we can all have a big friendly discussion about some of the ideas/features that would be required. (if there are any Xara developers on the list we'd love your comments on what worked and what didn't) If nothing else, so we don't overlap on any work.
Here are some thoughts that I've had, feel free to destroy at will :)
- Live Effects need to work with opening and saving a file, so they need to be stored somewhere. I was thinking we could add a "inkscape:live-effect" node in the defs section to define each live effect and read them when the file is opened.
- Live Effects should be triggered when the original objects are edited, so we need to mark who those are. Probably by node ID.
- If one of those nodes is deleted in the process of running the effect, then it should be stored in the live-effect node so that when re-running the effect it can be placed back on the canvas temporarily.
- We need to keep track of the objects that are created by the effect, so we can delete them before rerunning the effect. I think this could also be accomplished through a node ID.
- If any of the objects created by the live-effect are modified (ie moved) the live-effect is broken. I'm not sure if there should be some warning, or atleast a status bar message for this. I think it is simply to difficult to track the changes.
- We need a way for the effects themselves to mark which nodes they created or deleted in their execution. I'm thinking that we can just add a inkscape namespace attribute for the nodes. When we reparse the file, we'll look for those. Then, in the inx file, we can mark whether an effect is "live effects aware" to keep the basic case simple. We may be able to accomplish this through comparing the before and after documents, but that seems likely to cause error (perhaps Mental has some ideas on this?)
- I think that live effects should work for output and input extensions too. That way you could have an SVG document that you're working on constantly update the Postscript output copy that you want to have. Of course, this might be slow, but people will find it useful when they have 64-core computers :)
- To make the performance reasonable, I think that we'll need to keep parsed copies of the scripts cached. I think I know how to do this with the python libraries. There is already the load/unload mechanism in the extensions to facilitate this. After I finish the extensions dialog, I'll start working on this. (unless someone really knows how to do it, I'd be happy to let someone who knows what they're doing go ahead :)
Those are the things that I can think of right now. Comments and ideas are welcome!
--Ted
My comments, from the viewpoint of the plan we've worked out with Aaron:
- Live Effects need to work with opening and saving a file, so they need
to be stored somewhere. I was thinking we could add a "inkscape:live-effect" node in the defs section to define each live effect and read them when the file is opened.
Do you mean storing the code of the effect? We didn't yet plan on that, just using one of the predefined effects coded in Inkscape. Which one is used is specified in an extension attr. It's all compatible with SVG renderers, of couse, what they see is the path with that effect already applied.
- Live Effects should be triggered when the original objects are edited,
so we need to mark who those are. Probably by node ID.
It's already coded in SPShape which is the parent of shapes and paths. No need to use element ids, just each effected object stores its effect name and parameters and it's all automatically reapplied and updated.
- If one of those nodes is deleted in the process of running the effect,
then it should be stored in the live-effect node so that when re-running the effect it can be placed back on the canvas temporarily.
No, you seem to have quite a different idea of effects than we did. I will now forward my messages to Aaron explaining how our idea should work.
- We need to keep track of the objects that are created by the effect,
so we can delete them before rerunning the effect. I think this could also be accomplished through a node ID.
Our effects do not (yet) create any objects, just modifying existing paths. Effects that create objects (eg blends) would be the next step.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Sat, 18 Mar 2006, bulia byak wrote:
No, you seem to have quite a different idea of effects than we did. I will now forward my messages to Aaron explaining how our idea should work.
Yeah, I was thinking of something entirely different. I was thinking of taking the stuff on the effects menu and making it so that it would update live as you changed objects. So, something like the interpolation effect would change the lines as you adjust one of the paths.
Naming confusion. We'll probably not overlap anytime soon :)
--Ted
On 3/22/06, ted@...11... <ted@...11...> wrote:
Yeah, I was thinking of something entirely different. I was thinking of taking the stuff on the effects menu and making it so that it would update live as you changed objects. So, something like the interpolation effect would change the lines as you adjust one of the paths.
Hmm, but this is exactly what _our_ plan will deliver! :) (see the separate message with the "path effect" details). In fact, we started working on this with Aaron exactly because he authored most of the stuff in the Effects menu.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, 22 Mar 2006, bulia byak wrote:
On 3/22/06, ted@...11... <ted@...11...> wrote:
Yeah, I was thinking of something entirely different. I was thinking of taking the stuff on the effects menu and making it so that it would update live as you changed objects. So, something like the interpolation effect would change the lines as you adjust one of the paths.
Hmm, but this is exactly what _our_ plan will deliver! :) (see the separate message with the "path effect" details). In fact, we started working on this with Aaron exactly because he authored most of the stuff in the Effects menu.
Okay, perhaps I'm confused. The path effects stuff is adding operations that will execute when a path is edited. So, this would be like an effect, but limited only to single paths. I guess I think of this more like 'brushes'. So you can control how the path is drawn, by having a custom operation edit the path based on the core path. BTW, I'd love to see the caligraphy tool refactored in this way, so that you can move the line, adjust the tilt, all after the line had been drawn.
I guess what I didn't see in your write up was anyway to connect paths together, or to work on groups of objects. Both of those would really be required for anything to work with the Effects today.
As for making the path effects into scripts, I think that would be cool. I think that the only thing that would be required is having one "easy to use" entry point. Something like:
string mung_this (string in);
Where both of the strings are the list of points in the "SVG d style". Would that work with your guy's proposal? I may be missing the point, but is "brushes" a good name?
On an sorta unrelated note: It would be really cool if someone made a font where all the characters were a single path for use with this. Then you could write some text, and easily use a 'brush' on it.
--Ted
On 3/22/06, ted@...11... <ted@...11...> wrote:
Okay, perhaps I'm confused. The path effects stuff is adding operations that will execute when a path is edited. So, this would be like an effect, but limited only to single paths. I guess I think of this more like 'brushes'.
I'm not sure "brushes" is a good term. Its primary uses will be any effects that take a path and return another path. This includes all kinds of randomization, fractalizing, smoothing, rounding corners, distortions, etc. etc. It's not specifically for doing something to the stroke, which the "brush" implies. What it is is a generic path twister. The only prerequisite is for the object to be a path (or a shape, which is internally a path). That's why we call them Path Effects.
So you can control how the path is drawn, by having a custom operation edit the path based on the core path.
Not even "how it's drawn", but more generically "what other path is drawn instead, based on this source path".
BTW, I'd love to see the caligraphy tool refactored in this way, so that you can move the line, adjust the tilt, all after the line had been drawn.
Yes, eventually this fits into path effects as well. You take the source path and some parameters (widths array) and you create another path (variable-width stroke) to display instead.
I guess what I didn't see in your write up was anyway to connect paths together, or to work on groups of objects. Both of those would really be required for anything to work with the Effects today.
If an effect just depends on another path but maps source path to output 1:1 (e.g. envelope), then it's doable with the current implementation. You'll just need to make one of the effect params to be a link to the envelope path, and add listeners to update it when the envelope is edited.
If however your mapping is not 1:1 (e.g. blend), then the Path Effects are of little help. You need a new SPObject type for that, typically a derivative of a group with specialized properties. In fact, even envelopes are best implemented this way too, not as path effects, so that enveloping is possible not only on single paths but on groups. I have another plan for that, which you can read here:
http://wiki.inkscape.org/wiki/index.php/PerspectiveObject
As for making the path effects into scripts, I think that would be cool. I think that the only thing that would be required is having one "easy to use" entry point. Something like:
string mung_this (string in);
Where both of the strings are the list of points in the "SVG d style".
You also need a number of parameters, whose number and interpretation will vary by effect.
Would that work with your guy's proposal? I may be missing the point, but is "brushes" a good name?
No, see above :)
On an sorta unrelated note: It would be really cool if someone made a font where all the characters were a single path for use with this. Then you could write some text, and easily use a 'brush' on it.
Convert any text to path and combine the paths (in fact they are already combined, currently which needs to be have been fixed 100 years ago).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, 22 Mar 2006, bulia byak wrote:
On 3/22/06, ted@...11... <ted@...11...> wrote:
Okay, perhaps I'm confused. The path effects stuff is adding operations that will execute when a path is edited. So, this would be like an effect, but limited only to single paths. I guess I think of this more like 'brushes'.
I'm not sure "brushes" is a good term. Its primary uses will be any effects that take a path and return another path. This includes all kinds of randomization, fractalizing, smoothing, rounding corners, distortions, etc. etc. It's not specifically for doing something to the stroke, which the "brush" implies. What it is is a generic path twister. The only prerequisite is for the object to be a path (or a shape, which is internally a path). That's why we call them Path Effects.
So you can control how the path is drawn, by having a custom operation edit the path based on the core path.
Not even "how it's drawn", but more generically "what other path is drawn instead, based on this source path".
I see your point here, I was just looking for something that didn't have effects in the name. And, well, GIMP has a brush that draws with leaves :) Path Effects is fine, I don't think there'll be too much confusion.
BTW, I'd love to see the caligraphy tool refactored in this way, so that you can move the line, adjust the tilt, all after the line had been drawn.
Yes, eventually this fits into path effects as well. You take the source path and some parameters (widths array) and you create another path (variable-width stroke) to display instead.
I was thinking a little differently. Where the data would be the path and the pressure and tilt at each point on the path. Then you could generate the width and resulting path from there. Then, we could create some on canvas editing widgets to adjust tilt and pressure. It might be interesting when defining the API to assume that they'll always be there (pressure and tilt) and then set them to full and 0 degrees if the line doesn't have that information.
If however your mapping is not 1:1 (e.g. blend), then the Path Effects are of little help. You need a new SPObject type for that, typically a derivative of a group with specialized properties. In fact, even envelopes are best implemented this way too, not as path effects, so that enveloping is possible not only on single paths but on groups. I have another plan for that, which you can read here:
I wasn't thinking we'd need to go that complex. I thought just listening on the source paths. Kind of a 'loose' association instead of creating a new object. Though, a new object would solve some of the problems I had...
As for making the path effects into scripts, I think that would be cool. I think that the only thing that would be required is having one "easy to use" entry point. Something like:
string mung_this (string in);
Where both of the strings are the list of points in the "SVG d style".
You also need a number of parameters, whose number and interpretation will vary by effect.
Well, if we subclass from the Extension object, there is already a list of parameters. Currently the parameters are per-user, but I've designed it with the plan to go per-document and per-object with them.
On an sorta unrelated note: It would be really cool if someone made a font where all the characters were a single path for use with this. Then you could write some text, and easily use a 'brush' on it.
Convert any text to path and combine the paths (in fact they are already combined, currently which needs to be have been fixed 100 years ago).
That will give you the outline of the text in the font. I was thinking a font that will give you a path that is just the "line in the middle".
--Ted
ted@...11... wrote:
Yeah, I was thinking of something entirely different. I was thinking of taking the stuff on the effects menu and making it so that it would update live as you changed objects. So, something like the interpolation effect would change the lines as you adjust one of the paths.
Naming confusion. We'll probably not overlap anytime soon :)
The sooner we overlap the more fantastic things will be. I think the work that Bulia and I want to be doing is one of the necessary first steps for what you describe. Likewise for the DOM stuff Jon and Bob are working on.
Aaron Spike
One important thing is to keep an eye on SVG 1.2's vector effects. If we pattern our design after them as much as possible (so long as we maintain the usual invariants wrt. standards-compliant rendering), it will make it easier to use them to simulate SVG 1.2 vector effects in SVG <= 1.1 documents.
-mental
MenTaLguY wrote:
One important thing is to keep an eye on SVG 1.2's vector effects. If we pattern our design after them as much as possible (so long as we maintain the usual invariants wrt. standards-compliant rendering), it will make it easier to use them to simulate SVG 1.2 vector effects in SVG <= 1.1 documents.
Just a vague memory, but I thought Bulia and I had looked this over at the time and found that SVG 1.2 vector effects were quite different than what we are aiming to achieve with our live vector effects.
Aaron
On Mon, 20 Mar 2006 09:44:40 -0600, Aaron Spike <aaron@...749...> wrote:
MenTaLguY wrote:
One important thing is to keep an eye on SVG 1.2's vector effects. If we pattern our design after them as much as possible (so long as we maintain the usual invariants wrt. standards-compliant rendering), it will make it easier to use them to simulate SVG 1.2 vector effects in SVG <= 1.1 documents.
Just a vague memory, but I thought Bulia and I had looked this over at the time and found that SVG 1.2 vector effects were quite different than what we are aiming to achieve with our live vector effects.
They certainly should work differently. The question is -- can they be structured so that it's easy to simulate (visually) the results of SVG vector effects with them?
Maybe that's a moot point until we get live effects to the point where they can create objects, though.
-mental
participants (5)
-
unknown＠example.com -
Aaron Spike -
bulia byak -
MenTaLguY -
Ted Gould