Hi all,
I've unhidden the sketch lpe. I decided to remove the "construction line" feature in this effect (it used to place the tangent lines randomly along the input path).
My feeling was that the placement should either be tuned by hand, or guessed from curvature extrema or something... Anyway, I felt it was not good enough as is, and would eventually be worth a separate effect (the issue with independant effect is that you need to apply 2 effects on the *same* source path, which is not possible atm --- but no doubt this will come sooner or later! ;-)
Anyone having an opinion about this feature or it's eventual splitting in a separate effect?
By the way, my dream is that we could import or mimic Blender's 'node' system into inkscape: the effect editor would be a window within which each effect would be a little box with input and output slots (+ input fields + an eventual small window to show the result of the effect), and you would be free to connect ones with others, defining not only a pipeline, but a full graph with parallel ways, etc... You generally end up with a nice plate of noodles, but it's very powerfull. Notice the same thing could be used for both lpe and filters effects.
Cheers, jfb.
On Mon, Apr 20, 2009 at 3:09 PM, jf barraud wrote:
By the way, my dream is that we could import or mimic Blender's 'node' system into inkscape: the effect editor would be a window within which each effect would be a little box with input and output slots (+ input fields + an eventual small window to show the result of the effect), and you would be free to connect ones with others, defining not only a pipeline, but a full graph with parallel ways, etc... You generally end up with a nice plate of noodles, but it's very powerfull. Notice the same thing could be used for both lpe and filters effects.
http://wiki.inkscape.org/wiki/index.php/SpecFilterEffectDialog by verbalshadow :)
Alexandre
On Mon, Apr 20, 2009 at 8:09 AM, jf barraud <jf.barraud@...400...> wrote:
I've unhidden the sketch lpe. I decided to remove the "construction line" feature in this effect (it used to place the tangent lines randomly along the input path).
I think I will rather miss this. It added a recognizable style to your sketches :)
Can you please restore it, if only as a separate LPE? At least then I would be able to apply it to a copy of the path to get the same effect as before.
By the way, my dream is that we could import or mimic Blender's 'node' system into inkscape: the effect editor would be a window within which each effect would be a little box with input and output slots (+ input fields + an eventual small window to show the result of the effect), and you would be free to connect ones with others, defining not only a pipeline, but a full graph with parallel ways, etc... You generally end up with a nice plate of noodles, but it's very powerfull. Notice the same thing could be used for both lpe and filters effects.
That would be awesome, though it's a lot of coding to do.
On Mon, Apr 20, 2009 at 9:14 PM, bulia byak wrote:
I decided to remove the "construction line" feature in this effect (it used to place the tangent lines randomly along the input path).
I think I will rather miss this. It added a recognizable style to your sketches :)
Bow that you say it I think I'd rather join your chorus :)
Alexandre
On Mon, 2009-04-20 at 23:01 +0400, Alexandre Prokoudine wrote:
On Mon, Apr 20, 2009 at 9:14 PM, bulia byak wrote:
I decided to remove the "construction line" feature in this effect (it used to place the tangent lines randomly along the input path).
I think I will rather miss this. It added a recognizable style to your sketches :)
Bow that you say it I think I'd rather join your chorus :)
Another +1 to the revival of construction lines :)
Hehe, Thanks! it's nice to see people care about it :-) It's easy to restore, it is rather hidden from the compiler than actually removed...
The point is that if we add it, we'll have to keep it forever... even if better solutions show up (i.e. either we split before the release, or never). In an ideal world, I think you would like the strokes and the construction lines to have a different style (color, witdth...), so being separate.
On the other hand, there could be "default" construction lines right in the sketch effect, and if one is not happy with them, one could use a more sophisticated effect (we already have a "tangent line effect"). Moreover, it is computationnally more efficient to do both at once.
Hm, so maybe keeping them is not that bad.
In all cases, the random placement looks just too bad, particularily when there are straight lines in the path. I'll try to emprove that, and see what I can end up with (if you have any suggestion about the placement of such lines, please let me know!).
so maybe the best is to keep it hidden for a moment, try to emprove it, and re-enable it when I'll be more happy with it (or get tired of it ;-) )..
Cheers, jfb.
2009/4/20 Joshua A. Andler <scislac@...400...>
On Mon, 2009-04-20 at 23:01 +0400, Alexandre Prokoudine wrote:
On Mon, Apr 20, 2009 at 9:14 PM, bulia byak wrote:
I decided to remove the "construction line" feature in this effect (it
used
to place the tangent lines randomly along the input path).
I think I will rather miss this. It added a recognizable style to your sketches :)
Bow that you say it I think I'd rather join your chorus :)
Another +1 to the revival of construction lines :)
Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
ok, I restored construction lines (with minor modifications detailed below). The beginning of this was that I was trying to simplify the UI, and I end up with one more button than before!! I should stop simplifying things, or they'll quickly run out of control ;-)
for those intersted in more details: Each component of the input path used to carry the same number of construction lines. This was (not intentional and) terrible in the case of short components. So this number is now dispatched over the entire path. Moreover, placement randomness did not have it's own random generator, which was kind of a bug: it is now fixed, with the extra by-product of a new parameter that let you interpolate between regular and purely random placement.
I did several experiment trying to improve placement, but could not find good heuristics yet... Curvature does not seem to be the right thing to look at: it's not that intuitive, getting rid of scale dependency is not straightforward, and of course it has numerical stability issues and slows every thing down. Maybe intertia momentum of the overall picture, or of some piece of it is a better strategy. Anyway, should we have an enhanced placement strategy, I think it would be proposed as an alternative to the purely random thing, but would not replace it --- so it's more or less safe to restore the random thing ---.
After all, random placement is not that bad, if you bear to click sufficiently many times on the dice until you're happy with the result (and eventually to split your input to separate regions with or without construction lines...)
Cheers, jfb.
On Wed, Apr 22, 2009 at 4:28 PM, jf barraud wrote:
Hi,
ok, I restored construction lines (with minor modifications detailed below).
AWWW! WE LUV YOU! :)
The beginning of this was that I was trying to simplify the UI, and I end up with one more button than before!! I should stop simplifying things, or they'll quickly run out of control ;-)
Then you will have to update your excellent illustration for that LPE :)
P.S. Do you think Dynastroke could make it to 0.47?
Alexandre
Thanks!
About dynastroke lpe, I ponder if it's a goood idea to include in any release at all!
In other words, I doubt doing this as lpe is the good way to go. We definitely need to have path with variable and editable width as full inscape citizen, i.e. regular inkscape objects. A simple menu to convert a regular path to a enhenced one would then be more powerfull than the actual lpe.
However, if we release it and for compatibility reasons, we would have to maintain this lpe for ever, although it became useless...
I think the best way to go is to develop such enhenced paths in 2geom, with basic edition capabilities, and then import them into inkscape as regular objects. (this is one reason why I did not try to polish it at all and left it quiet experimental).
Developping the dynastroke lpe was not useless however: 1- we can still play with it although we know it won't be here for ever, (but I think we should not release it) 2- as a first prototype, it did help me clarify some ideas about the way 'dynamic paths' should be done in 2geom.
Do other agree? Johan?
Cheers, jfb.
On Thu, Apr 23, 2009 at 6:14 PM, jf barraud <jf.barraud@...400...> wrote:
About dynastroke lpe, I ponder if it's a goood idea to include in any release at all!
In other words, I doubt doing this as lpe is the good way to go. We definitely need to have path with variable and editable width as full inscape citizen, i.e. regular inkscape objects.
Regardless of how we represent this in the UI, in SVG it must still be a path. And that means we will still use our SVG extensions for LPE, simply because we have nothing better, and I don't think we need anything else. If it is a LPE at the bottom level, I think it will work adequately. At the UI level, we can treat it differently if needed, just like the Node tool treats Spiro paths a little differently now.
participants (4)
-
Alexandre Prokoudine -
bulia byak -
jf barraud -
Joshua A. Andler