Re: [Inkscape-devel] Idea for shape generation and morphing
Hello Bryce,
I have posted 12 screen shots of increasing complexity here:
http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphappletcaptures.html
Sliders modify control point lengths and angles (Mirror, Twist, CP1 and CP2). These are calculated from the turning angle of the turtle. Control point length default is 0.33333 * last distance travelled.
My other 2D version is a HyperCard stack written back in the early 1992. This outputs PostScript (Adobe Illustrator 3 file). It generates a host of other shapes (cogs, spirals, shells etc) and uses the same principle of "live" shapes, generated procedurally.
I have a 3D Nurbs version in C++ that works around spherical polyhedra but it's about seven years since I wrote the code and I'm still trying to untangle what I actually did :)
JB
Bryce Harrington wrote:
On Fri, Feb 23, 2007 at 04:47:13PM +0000, Jemima Bond wrote:
Hello. I have an idea for generating and morphing vector shapes using bezier curves and a turtle drawing routines. You can view this as an applet here:
http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphapplet.html
You will have to play around with the various sliders, combo boxes etc to get a feel of how the thing works. Un-check the "Skeleton" and "Control Point" boxes to see the bezier curve only.
Just thought I'd throw it into the inkscape pot. Thanks for your time.
Hi Jemima,
Would you mind posting some screenshots of this, for those of us that don't have Java installed?
THanks, Bryce
On Fri, Feb 23, 2007 at 10:10:31PM +0000, Jemima Bond wrote:
Hello Bryce,
I have posted 12 screen shots of increasing complexity here:
http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphappletcaptures.html
Sliders modify control point lengths and angles (Mirror, Twist, CP1 and CP2). These are calculated from the turning angle of the turtle. Control point length default is 0.33333 * last distance travelled.
My other 2D version is a HyperCard stack written back in the early 1992. This outputs PostScript (Adobe Illustrator 3 file). It generates a host of other shapes (cogs, spirals, shells etc) and uses the same principle of "live" shapes, generated procedurally.
I have a 3D Nurbs version in C++ that works around spherical polyhedra but it's about seven years since I wrote the code and I'm still trying to untangle what I actually did :)
Cool, that's really sweet. This looks similar in some ways to our star tool, but I like how much more 'spirography' this looks. Are you interested in implementing this (and/or the cogs/spirals/shells into Inkscape?)
Like bulia, I also wonder if this could be folded into the current star tool, to make it more powerful? If not, a new shape could be added, but that could be a lot more work. In any case, I'd be happy to give pointers for getting into the codebase if you'd like.
Bryce
Bryce Harrington wrote:
On Fri, Feb 23, 2007 at 10:10:31PM +0000, Jemima Bond wrote:
Hello Bryce,
I have posted 12 screen shots of increasing complexity here:
http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphappletcaptures.html
Sliders modify control point lengths and angles (Mirror, Twist, CP1 and CP2). These are calculated from the turning angle of the turtle. Control point length default is 0.33333 * last distance travelled.
My other 2D version is a HyperCard stack written back in the early 1992. This outputs PostScript (Adobe Illustrator 3 file). It generates a host of other shapes (cogs, spirals, shells etc) and uses the same principle of "live" shapes, generated procedurally.
I have a 3D Nurbs version in C++ that works around spherical polyhedra but it's about seven years since I wrote the code and I'm still trying to untangle what I actually did :)
Like bulia, I also wonder if this could be folded into the current star tool, to make it more powerful? If not, a new shape could be added, but that could be a lot more work. In any case, I'd be happy to give pointers for getting into the codebase if you'd like.
If this can't be folded into the star tool, at SCALE, Ted mentioned that we're wanting to implement new tools as extensions if possible. Ted, is this feasible for us to do at this point? Is the infrastructure where it would need to be for this to work? It's just a thought.
-Josh
Bryce Harrington wrote:
Like bulia, I also wonder if this could be folded into the current star tool, to make it more powerful? If not, a new shape could be added, but that could be a lot more work. In any case, I'd be happy to give pointers for getting into the codebase if you'd like.
I wonder if this wouldn't be a good place to start looking into pluggable tools. There are a number of things that I've seen pointing in this direction lately. Flood fill being another.
Ted, is the extensions system ready to start building up a mechanism for pluggable tools?
Aaron Spike
On Fri, Feb 23, 2007 at 04:32:45PM -0600, Aaron Spike wrote:
Bryce Harrington wrote:
Like bulia, I also wonder if this could be folded into the current star tool, to make it more powerful? If not, a new shape could be added, but that could be a lot more work. In any case, I'd be happy to give pointers for getting into the codebase if you'd like.
I wonder if this wouldn't be a good place to start looking into pluggable tools. There are a number of things that I've seen pointing in this direction lately. Flood fill being another.
Ted, is the extensions system ready to start building up a mechanism for pluggable tools?
Not a bad idea. I suspect in addition to support in the extensions system, we'd need to have a kind of 'Super Shape' that supports being scripted, or something.
An idea I've been kicking around for a while is something similar to Dia's Shape objects, which seems to correspond most closely to our (unfinished) SPSymbol object. Symbols are basically like groups, except they support some aspect-ratio preservation capabilities. Dia's shapes also include some dynamic information, like descriptive text, parameters, and so on; they also allow shape-specific dialogs to be associated with them. I wonder if all these ideas could be fitted together into a single solution? Being able to implement these different 'smart shapes' as extensions would be icing on the cake.
Bryce
On 2/23/07, Aaron Spike <aaron@...749...> wrote:
I wonder if this wouldn't be a good place to start looking into pluggable tools. There are a number of things that I've seen pointing in this direction lately.
I have nothing against pluggable tools in principle, but this one should really be added to the star tool. They are too similar to add anything new.
Flood fill being another.
And this one is just too generally useful to be a plugin. I think plugins should be for specialized tools that cover specialized needs.
bulia byak wrote:
On 2/23/07, Aaron Spike <aaron@...749...> wrote:
I wonder if this wouldn't be a good place to start looking into pluggable tools. There are a number of things that I've seen pointing in this direction lately.
I have nothing against pluggable tools in principle, but this one should really be added to the star tool. They are too similar to add anything new.
Flood fill being another.
And this one is just too generally useful to be a plugin. I think plugins should be for specialized tools that cover specialized needs.
Well, as much as I hate to use Illustrator as an example, everything in Illustrator is a plugin. All of the core tools, all of the effects, the dialogs, etc.
If there is no difference in terms of performance, would this still be bad in your eyes? If it's 100% transparent to the user, and if it could somehow cut down compile times, it makes sense for all of our existing tools to be refactored into plugins as well.
Note, none of the above may actually be practical... but I figured I'd ask (and point out the AI thing).
-Josh
On 2/23/07, Joshua A. Andler <joshua@...533...> wrote:
If there is no difference in terms of performance, would this still be bad in your eyes?
If there's no difference in performance AND in access to all the core functions that a tool might need, then I would not object, of course. But then, I would wonder why we are calling this a "plugin" :) Maybe just "standardizing and simplifying the tools API" would be a better description in that case.
bulia byak wrote:
On 2/23/07, Joshua A. Andler <joshua@...533...> wrote:
If there is no difference in terms of performance, would this still be bad in your eyes?
If there's no difference in performance AND in access to all the core functions that a tool might need, then I would not object, of course. But then, I would wonder why we are calling this a "plugin" :) Maybe just "standardizing and simplifying the tools API" would be a better description in that case.
Is there an argument for porting the whole UI to a high-level language? Since we're going to have a Javascript/DOM binding anyway, perhaps we should go the Mozilla route and implement the UI with it. My personal preference would be for Python though. Mozilla are doing that too, actually.
Regardless of preference, it would be invaluable when coming to writing animation UI, filter UI and so on. Also I can imagine the technical drawing versus graphic design split would be best met by a UI which can be refactored, extended or even forked without touching native code.
Dan
On Feb 23, 2007, at 3:25 PM, bulia byak wrote:
If there's no difference in performance AND in access to all the core functions that a tool might need, then I would not object, of course. But then, I would wonder why we are calling this a "plugin" :) Maybe just "standardizing and simplifying the tools API" would be a better description in that case.
Well... if things go according to the long-term plan, we'll have the core functions for sure. Performance might depend on a few factors, but should be close for most tools.
I think that we need to get existing tools cleaned up as far as their implementation goes so that they will come into line with the API we want to expose for plugins. Trying to plan that out will at least help us get some of the internal tools split out while at the same time giving plugins more core function access.
On Fri, 2007-02-23 at 19:25 -0400, bulia byak wrote:
On 2/23/07, Joshua A. Andler <joshua@...533...> wrote:
If there is no difference in terms of performance, would this still be bad in your eyes?
If there's no difference in performance AND in access to all the core functions that a tool might need, then I would not object, of course. But then, I would wonder why we are calling this a "plugin" :) Maybe just "standardizing and simplifying the tools API" would be a better description in that case.
Effectively, that would be what would be happening in the first pass. The nice part is that if we did this on top of the extensions system we'll make it easier to add the plugable tools later.
As far as work done, mostly investigation. But, don't let that stop someone from picking it up. Basically it would be making a subclass of the Extension class similar to Input, Output, Effect or Print. Basically defining and simplifying the tools API :)
--Ted
Well, as much as I hate to use Illustrator as an example, everything in Illustrator is a plugin. All of the core tools, all of the effects, the dialogs, etc.
If there is no difference in terms of performance, would this still be bad in your eyes? If it's 100% transparent to the user, and if it could somehow cut down compile times, it makes sense for all of our existing tools to be refactored into plugins as well. Note, none of the above may actually be practical... but I figured I'd ask (and point out the AI thing).
-Josh
If I may give here my opinion as a user, it would be better for me to have all the tools implemented as plugins for at least for 1 reason: updating these tools would be a lot more easier (download 1 or a few plugin files and paste them in a "plugin" folder, instead of downloading and reinstalling Inkscape). Also, users could choose what tools they want or don't want during installation (in case in the future there will be specialized tools, for example a codebar generator or something like that...)
Molumen
On Sun, Feb 25, 2007 at 07:33:28AM +0100, momo wrote:
If I may give here my opinion as a user, it would be better for me to have all the tools implemented as plugins for at least for 1 reason: updating these tools would be a lot more easier (download 1 or a few plugin files and paste them in a "plugin" folder, instead of downloading and reinstalling Inkscape).
I think this is one of those things that sounds good in theory but in practice is tough to pull off without incurring a great deal of complexity for everyone.
Also, users could choose what tools they want or don't want during installation (in case in the future there will be specialized tools, for example a codebar generator or something like that...)
I'm skeptical that users would actually want to bother choosing which tools to have during installation - I'd imagine they'd prefer to have them all installed, and be able to just pick and choose during usage.
I think I tend to agree with bulia on this - implementing specialty tools like barcode generators as plugins may make sense, but the core pieces and probably any non-trivial shape are still probably best done in the core.
Bryce
Hello,
Surfing across Sourceforge.net, I found Freeimage, it is some kind of library that could be used to support a lot of graphical formats. It's located here: http://freeimage.sourceforge.net/ It seems to be a mature project, it's already at version 3.9.3
From what I saw on the website, it supports the following formats:
BMP files [reading, writing] DDS files [reading] Dr. Halo files [reading] * only grayscale GIF files [reading, writing] HDR files [reading, writing] ICO files [reading, writing] IFF files [reading] JBIG [reading, writing] ** only via external plugin, might require a commercial license JNG files [reading] JPEG/JIF files [reading, writing] KOALA files [reading] LBM files [reading] Kodak PhotoCD files [reading] MNG files [reading] PCX files [reading] PBM files [reading, writing] PGM files [reading, writing] PNG files [reading, writing] PPM files [reading, writing] PhotoShop files [reading] Raw Fax G3 files [reading] SGI files [reading] Sun RAS files [reading] TARGA files [reading, writing] TIFF files [reading, writing] WBMP files [reading, writing] XBM files [reading] XPM files [reading, writing]
Also, it is used by many opensource and commercial applications on different platforms (mac, win, linux) Could it be useful to Inkscape?
Thanks! Molumen
Hi, I have a question about this future (star?) tool: could it be used to generate graphics of the same complexity as the one in the attachment? It would be really awesome to have an Open Source software capable of generating that kind of security design, used on cheques, diplomas, and other important papers.
Actually it reminds me this tool: http://www.oberonplace.com/products/securidesign/index.htm
Thanks! Molumen
----- Original Message ----- From: "Bryce Harrington" <bryce@...961...> To: "Jemima Bond" <jemima.bond@...663...> Cc: inkscape-devel@lists.sourceforge.net Sent: Friday, February 23, 2007 11:23 PM Subject: Re: [Inkscape-devel] Idea for shape generation and morphing
On Fri, Feb 23, 2007 at 10:10:31PM +0000, Jemima Bond wrote:
Hello Bryce,
I have posted 12 screen shots of increasing complexity here:
http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphappletcaptures.html
Sliders modify control point lengths and angles (Mirror, Twist, CP1 and CP2). These are calculated from the turning angle of the turtle. Control point length default is 0.33333 * last distance travelled.
My other 2D version is a HyperCard stack written back in the early 1992. This outputs PostScript (Adobe Illustrator 3 file). It generates a host of other shapes (cogs, spirals, shells etc) and uses the same principle of "live" shapes, generated procedurally.
I have a 3D Nurbs version in C++ that works around spherical polyhedra but it's about seven years since I wrote the code and I'm still trying to untangle what I actually did :)
Cool, that's really sweet. This looks similar in some ways to our star tool, but I like how much more 'spirography' this looks. Are you interested in implementing this (and/or the cogs/spirals/shells into Inkscape?)
Like bulia, I also wonder if this could be folded into the current star tool, to make it more powerful? If not, a new shape could be added, but that could be a lot more work. In any case, I'd be happy to give pointers for getting into the codebase if you'd like.
Bryce
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2007-02-25 at 07:21 +0100, momo wrote:
Hi, I have a question about this future (star?) tool: could it be used to generate graphics of the same complexity as the one in the attachment? It would be really awesome to have an Open Source software capable of generating that kind of security design, used on cheques, diplomas, and other important papers.
Not quite the same as graphics of the original message but very security like:
Take star tool. Set "Corners" to a large number (i.e. 51). Set "Rounded" to 0.25. Drag Base handle to other side of star.
Another alternative is to use the Tile Clones dialog with an offset center of rotation, see:
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Tiles-Tricks.html
It would be nice if the Tile Clones dialog had some option to allow one to take an object or group and create clones rotated around an arbitrary point (like the Rotation center handle). Perhaps a button on the Rotation tab that would specify that the Rotation center handle be used and that the Shift in X be set to -100% for columns and Shift in Y set to -100% for rows.
Examples of both are in the attached Inkscape SVGZ file.
Actually it reminds me this tool: http://www.oberonplace.com/products/securidesign/index.htm
Page won't load for me.
Thanks! Molumen
Tav
----- Original Message ----- From: "Bryce Harrington" <bryce@...961...> To: "Jemima Bond" <jemima.bond@...663...> Cc: inkscape-devel@lists.sourceforge.net Sent: Friday, February 23, 2007 11:23 PM Subject: Re: [Inkscape-devel] Idea for shape generation and morphing
On Fri, Feb 23, 2007 at 10:10:31PM +0000, Jemima Bond wrote:
Hello Bryce,
I have posted 12 screen shots of increasing complexity here:
http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphappletcaptures.html
Sliders modify control point lengths and angles (Mirror, Twist, CP1 and CP2). These are calculated from the turning angle of the turtle. Control point length default is 0.33333 * last distance travelled.
My other 2D version is a HyperCard stack written back in the early 1992. This outputs PostScript (Adobe Illustrator 3 file). It generates a host of other shapes (cogs, spirals, shells etc) and uses the same principle of "live" shapes, generated procedurally.
I have a 3D Nurbs version in C++ that works around spherical polyhedra but it's about seven years since I wrote the code and I'm still trying to untangle what I actually did :)
Cool, that's really sweet. This looks similar in some ways to our star tool, but I like how much more 'spirography' this looks. Are you interested in implementing this (and/or the cogs/spirals/shells into Inkscape?)
Like bulia, I also wonder if this could be folded into the current star tool, to make it more powerful? If not, a new shape could be added, but that could be a lot more work. In any case, I'd be happy to give pointers for getting into the codebase if you'd like.
Bryce
On 2/25/07, Tavmjong Bah <tavmjong@...8...> wrote:
Not quite the same as graphics of the original message but very security like:
Take star tool. Set "Corners" to a large number (i.e. 51). Set "Rounded" to 0.25. Drag Base handle to other side of star.
With these settings I get a circle and only one handle (SVN trunk). Am I doing something obviously wrong?
Alexandre
On Sun, 2007-02-25 at 12:41 +0300, Alexandre Prokoudine wrote:
On 2/25/07, Tavmjong Bah <tavmjong@...8...> wrote:
Not quite the same as graphics of the original message but very security like:
Take star tool. Set "Corners" to a large number (i.e. 51). Set "Rounded" to 0.25. Drag Base handle to other side of star.
With these settings I get a circle and only one handle (SVN trunk). Am I doing something obviously wrong?
Is the Polygon box unchecked in the Star Tool Controls?
Tav
On 2/25/07, Tavmjong Bah wrote:
With these settings I get a circle and only one handle (SVN trunk). Am I doing something obviously wrong?
Is the Polygon box unchecked in the Star Tool Controls?
Doh! That's it. Thanks a lot :)
Alexandre
participants (11)
-
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Daniel Pope -
Jemima Bond -
Jon A. Cruz -
Joshua A. Andler -
momo -
Tavmjong Bah -
Ted Gould