On Fri, Feb 20, 2009 at 5:48 AM, G33K <g99999k@...2136...> wrote:

Hello, I am very interested in the PerspectiveObject feature that is mentioned in the roadmap for milestone 15 / Inkscape 0.49. Has the implementation already started?

Not quite, but meanwhile, we have a 3D box, and in devel version, perspective LPE which is very close to that old plan (live-updated, path-transforming to fit a perspective, but only linear without curves). This all needs work, however, so if you can help out that would be great!

In the meantime, I'd like to try and fix the Python implemented envelope effect. It looks like it's only using the corners of the envelope for the perspective, but doesn't take any curved sides into account. Can someone tell me in which directory I can find the source code for that one?

it's in share/extensions/perspective.py, but how can you combine curved sides with perspective? Isn't it mutually exclusive?

I finished porting my old Bezier enveloping function from Batik/Java to Inkscape/Python. I'll call it "Bezier Envelope".

It takes an arbitrary path (the "letter") and a 4-sided path (the "envelope") as input, and then attempts to squeeze the letter into the envelope by rearranging all anchor and handle points of the letter's path. That means the path is not broken down any further, so a rough letter might not fit into a detailed envelope. Otherwise, it works pretty well.

A detailed description and lots of comments are included with the Python script. It would be cool if someone could help to improve precision and usability... Maybe some of the PerspectiveObject fans?

The most important improvements would be to find or a better bounding box function (this must exist somewhere), and to convert lines and quads to cubics (probably exists somewhere too), because currently the extension only works with cubic paths.

Check it out if you like, and tell me what is still needed to include it in the regular Inkscape distribution.

Cheers to everyone, Gerrit

On Thu, 9 Apr 2009 13:49:46 -0500 Terry Brown <terry_n_brown@...36...> wrote:

...

I finished porting my old Bezier enveloping function from Batik/Java to Inkscape/Python. I'll call it "Bezier Envelope".

Sounds good - where do you get the ffgeom module it requires?

Whoops - I see it's in the devel. version.

Still didn't get output though, always got "Unsupported segment type L", or is that because my devel. version is stale?

Cheers -Terry

On Thu, 09 Apr 2009 12:13:13 -0700 "G33K" <g99999k@...2136...> wrote:

About the ffgeom import, I copied that from another extension. I'm not sure if it's needed, but I seem to recall that some math stuff wouldn't work without that line.

Sadly, the envelope can currently only work with cubic bezier curves (C type). Otherwise, you'll get that exception (Like for L, a straight line segment). Try to tweak your envelope so that all 4 sides are cubics, maybe then it will work.

Ok, also you have to select the letter first, and then the envelope. Yep, I bent all 4 sides of the envelope, but instead of the "Unsupported segment type L" error I now get:

Traceback (most recent call last): File "/home/tbrown/.inkscape/extensions/bezierenvelope.py", line 305, in <module> e.affect() File "/mnt/usr1/usr1/home/tbrown/.inkscape/extensions/inkex.py", line 154, in affect self.effect() File "/home/tbrown/.inkscape/extensions/bezierenvelope.py", line 98, in effect morphElement( letterElement, envelopeElement, axes ); File "/home/tbrown/.inkscape/extensions/bezierenvelope.py", line 102, in morphElement morphedPath = morphPath( path, axes ) File "/home/tbrown/.inkscape/extensions/bezierenvelope.py", line 118, in morphPath mapPointsToMorph( axes, percentages, morphed, numPts ) File "/home/tbrown/.inkscape/extensions/bezierenvelope.py", line 232, in mapPointsToMorph xTransform = match( yAnchor0, yAnchor1, xSpot0, xSpot1 ) File "/home/tbrown/.inkscape/extensions/bezierenvelope.py", line 289, in match t2 = simpletransform.parseTransform( "rotate(%f)"%(-angle_p) ) File "/mnt/usr1/usr1/home/tbrown/.inkscape/extensions/simpletransform.py", line 70, in parseTransform matrix=composeTransform(mat,matrix) UnboundLocalError: local variable 'matrix' referenced before assignment

Cheers -Terry

(The "letter" can contain other segments, but they won't look pretty since a straight line will remain straight.)

The easiest way to fix this is to convert all segments of the envelope to cubics. Not that hard, but I would prefer to use an existing funcion for that, if there is any. Would you know one?

On Thu, 09 Apr 2009 13:54 -0500, "Terry Brown" <terry_n_brown@...36...> wrote:

...

On Thu, 9 Apr 2009 13:49:46 -0500 Terry Brown <terry_n_brown@...36...> wrote:

...

...

I finished porting my old Bezier enveloping function from Batik/Java to Inkscape/Python. I'll call it "Bezier Envelope".

Sounds good - where do you get the ffgeom module it requires?

Whoops - I see it's in the devel. version.

Still didn't get output though, always got "Unsupported segment type L", or is that because my devel. version is stale?

Cheers -Terry

---

This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Thu, 09 Apr 2009 13:36:59 -0700 "G33K" <g99999k@...2136...> wrote:

Open simpletransform.py, and replace all "result.groups" (plural) with "result.group" (singular). Then the matrix parser constructors will work.

Ok, got it to run :-) attached .jpg

Result was much larger than the page and also squashed horizontally, i.e. different aspect ratio than the envelope, but easily shrunk and stretched back into shape.

Aside: I was using inkscape-devel (Ubuntu 8.10 nightly), result.group was correct in /usr/share/inkscape-devel/extensions, but wrong in /usr/share/inkscape/extensions, makes me thing devel is pulling from .../inkscape/ first, and only then .../inkscape-devel/ if the targets not in the first dir.

Cheers -Terry

G33K wrote the following on 4/13/2009 12:47 PM:

...

Ok, got it to run :-) attached .jpg

Result was much larger than the page and also squashed horizontally, i.e. different aspect ratio than the envelope, but easily shrunk and stretched back into shape.

Can you maybe send me the original SVG file? Whenever I used the effect, it was a pretty close fit, so I attributed the small offsets to the incomplete calculation of the bounding box. But if the result was larger than the page, maybe some algorithm needs to be fixed too.

Also, I realized it's probably difficult to have people test the extension if it doesn't work out of the box. Thank you guys for trying it out nonetheless. I wrote a function to convert lines and quads to cubics, so now it should work with just any path, without raising "unsupported" errors. I also copied the rotate and scale constructors from simpletransform.py, so that bug isn't a problem any more either. If anyone else wanted to use the effect, but was scared by the complicated setup, you might wanna give it a try now. :)

Your improvements to this extension work much better. This will be quite useful for future things. :)

Thank-you,

heathenx

Are you familiar with the "Envelope Deformation" LivePathEffect ?

I wonder how you like that tool and if you see possible improvements? (the math is done using 2geom, you can see the code in src\live_effects\lpe-envelope.cpp)

Looks very interesting. To be honest, I don't really understand the code. :) I deduct from the comments that it probably uses bend_path on all 4 edges and then interpolates the results according to the proximity to each edge. That seems to be a totally different approach, but I'll have to compile the sources to see if the result is actually any different to the Python script.

If you could need a helping hand with any particular problem, just let me know.

Could you try the LPE and see how it compares to your script?

Thanks! Johan

I might not have much time during the next days, here's just a first impression.

I can already say that the interpolation approach is more flexible, because it can deal with extreme curves where the handles point to opposing edges. With my axes tweening approach, the mapping inside the bounds follows the sides, which means the image gets reversed at some point in the middle (much like a fluttering flag). In the example image, the word "quick" is rendered inverse.

The LPE is also more precise because it breaks each curve down into tiny segments. Of course, that could be done with the axes approach too, but it would probably be too much for a script.

Another interesting difference is that my script takes the length of the handles into account, because it uses the bezier percentage. That's why the letter "x" is squashed.

Also, there seems to be a bug in my script, because the edge of the letter "q" leaks outside the bounds. Making the handles less extreme didn't solve that. I also tried the Java/Batik version, but the result is pretty much identical to the Python script.

I'll do some testing once I get the time.