Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.postscript > #3429
| Newsgroups | comp.lang.postscript |
|---|---|
| Date | 2019-07-24 00:38 -0700 |
| References | <bcebd98c-b6bf-47fb-bfa9-bc064429190b@googlegroups.com> <5661daa6-058f-4f70-97e8-af7b0568cfc9@googlegroups.com> <9b8a3d34-e793-4f5c-bbb6-3509e7a20cd8@googlegroups.com> |
| Message-ID | <cdeb0b57-5da9-4255-bb71-ed4bff63b693@googlegroups.com> (permalink) |
| Subject | Re: Snipping the ears |
| From | luser droog <luser.droog@gmail.com> |
On Monday, July 22, 2019 at 2:47:45 AM UTC-5, luser droog wrote: > On Saturday, July 20, 2019 at 6:51:02 PM UTC-5, luser droog wrote: > > On Saturday, July 20, 2019 at 3:18:58 PM UTC-5, luser droog wrote: > > > After 27 posts in the other thread, I thought it'd be nice to > > > have a fresher start on the remaining issues with my code. > > > > > > The task is to take the glyph of the number 9 using 'charpath', > > > then traverse the curves like a turtlw with a paintbrush hanging > > > out one arm's-length away. > > > > > > The tricky part would be dealing with the actual Bezier curves, > > > so I call 'flattenpath' first so I can work with just line > > > segments. The 'setflat' operator can be used to control how > > > finely the curves are cut into line segments. > > > > > > (Or maybe, the curves true secret path to the desired result??) > > > > > > Anyway, to traverse the line segments I use a control structure > > > I cooked up, called 'fortuplem'. It works kind of like 'forall', > > > but it takes 2 parameters n and m. n is the step-value between > > > iterations, and m is the width of a slice of the array produce > > > using 'getinterval'. Calling with n=2 m=2 iterates over the > > > points in the line. Calling with n=2 m=4 iterates over 2 point > > > slices. So I can run through these 2 points slices, get a vector > > > between them, normalize, take the perpendicular vector, scale > > > by my "arm's length" and produce a new transformed point. > > > This just needs one special case for the wrap around the end > > > from the last point to the first. > > > > > > > > > So, this all *works* with the untidy caveat that it produces > > > "ears" when the input path has a tight bend in the curve. > > > > > > Detecting and pruning these ears would make the output nicer > > > and more usable. A further nicety would be implementing miter > > > or bevel joins for the other side of the tight bends. > > > > > > > > > Any, here's the current state of the code, including the laborious > > > fixes for the 2 "hacks" described at the end of the last thread. > > > > > > > I've said this before, but I think I can detect the ears now. > > I take the vector out of each point, take the angle, take the > > diff between adjacent angles, then take the signs of that angular > > change. > > > > If I've reasoned correctly, this gives me a chart of left turns vs. > > right turns for each point. Running it on the left hand offset curve > > (-n offsetpath) gives me this: > > > [snip]> > > And I see a lonely "1* -1 1*" in the first curve, and a "-1* 1 -1*" in the second, > > which makes sense considering that the two curves are deliberately described > > in differing orientations to take advantage of the even/odd rule. > > > > Running it one the right hand curve (+n offsetpath) gives me this: > > > [snip]> > > Which shows no ears on the inner curve, but several spots of weirdness in > > the outer curve. There's an interesting "-1* 1 1 1 -1*" which looks like the > > bunched up points on the foot the '9'. > > > > And two little wiggles "1* -1 1 -1 1 -1*" and "1* -1 1 -1*" which I don't > > know what those are. > > > > So, now to try actually snipping. I'll tackly the simple ones first I think. > > "-1* 1 -1*" and "1* -1 1*" patterns. I think I need the incoming and outgoing vectors and then take their intersection as they approach their > > points. > > > > I'm not sure what to do with the fat ear and the ripples. > > Sigh. It's turning into the same rats' nest as before. So, let's start over. > This fresh program does not do any offsetting yet. It also preserves curves. > Just dumping the numbers for now to get a sense of what's going on in there. > A few 'linetos' here and there but lots of 'curvetos' (the 6 element subarrays). > > So, the question changes. Can we detect sharp turns in the curveto operands? > And then do something sensible to produce an offset for that portion? > Wikipedia has some info: https://en.wikipedia.org/wiki/Parallel_curve > I tried implementing some stuff and the result was ugly. So at long last, I busted out the pen and paper and began to make some real progress. I think I have a good idea of what I want it to do, and the challenge now is just implementing it. When running through the path, transforming one 'lineto' or 'curveto' at a time, we need a little surrounding context to get all the interesting vectors that contribute to the result. So, my idea is to run through the path elements with a sliding window of three elements, one on each side. For a 'x u lineto' element, we only need 2 vectors, v_in the vector coming in (from currentpoint to x y) v_out the vector going out (from x y to next element) x' y' = x y + scale(n. perp(norm(v_in + v_out))) For a 'xy1 xy2 xy3 curveto' element, there are 4 important vectors v_enter the vector approaching (from earlier upto currentpoint) v_in the first hermite vector (from currentpoint to xy1) v_exit the second hermite vector (from xy2 to xy3) v_out the vector going out (from xy3 to next element) Then xy1 should be modified by the perp of the avg of v_enter and v_in. xy2 and xy3 should be modified by the perp of the avg of v_exit and v_out. I don't have this all working yet, but it seems like it ought to work. Another idea is to do one iteration of DeCasteljau's algorithm to aplit the curve and find the center point and its in/out vectors. Then (somehow) figure out how to move the original control points s.t. the center point moves appropriately.
Back to comp.lang.postscript | Previous | Next — Previous in thread | Next in thread | Find similar
Snipping the ears luser droog <luser.droog@gmail.com> - 2019-07-20 13:18 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-07-20 16:51 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-07-22 00:47 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-07-24 00:38 -0700
Re: Snipping the ears Mark Carroll <mtbc@bcs.org> - 2019-07-24 08:50 +0100
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-07-29 23:18 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-08-06 22:05 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-08-08 00:22 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-08-11 13:33 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-08-13 16:03 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-08-19 22:46 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-08-21 23:44 -0700
Re: Snipping the ears jdaw1 <jdawiseman@gmail.com> - 2019-10-10 15:07 -0700
Re: Snipping the ears jdaw1 <jdawiseman@gmail.com> - 2019-10-10 15:09 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-10-13 01:39 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2019-10-13 01:51 -0700
Re: Snipping the ears jdaw1 <jdawiseman@gmail.com> - 2020-06-04 03:15 -0700
Re: Snipping the ears luser droog <luser.droog@gmail.com> - 2020-07-09 10:31 -0700
Re: Snipping the ears jdaw1 <jdawiseman@gmail.com> - 2021-02-13 09:51 -0800
csiph-web