[Etoys-notify] [JIRA] Updated: (SQ-211) Polygon curves with truly smooth cuvres
jira at immuexa.com
jira at immuexa.com
Sun May 31 08:03:42 EDT 2009
[ http://tracker.immuexa.com/browse/SQ-211?page=all ]
Scott Wallace updated SQ-211:
Fix Version: future release - desirables
(was: squeakfest 2009 release - possibles)
> Polygon curves with truly smooth cuvres
> Key: SQ-211
> URL: http://tracker.immuexa.com/browse/SQ-211
> Project: squeakland
> Type: Improvement
> Components: etoys
> Reporter: Jerome Peace
> Priority: Eventual
> Fix For: future release - desirables
> Original Estimate: 3 days
> Remaining: 3 days
> This is essential planting the flag to sell smooth curves to etoy/squeakland.
> The repair is already in 3.9, 3.10.2 on the squeak-dev side.
> The problem:
> Polygons cannot easily imitate ovals.
> The curve smoothing currently used for etoys polygons fits the polygon to a cubic spline. The end conditions for the spline are suitable for open curves. (Natural cubic).
> On closed curves etoys polygons always have one sharp bend.
> I considered this a bug and repaired it in a very complete fashion. The solution is in mantis issue
> [FIX] Closed curves can be smooth except for one sharp bend.
> The results are polygons that use a closed cubic spline for closed polygons. The effect is that you could now make closed polygons whose curvature did not depend on which vertex was first or last. Any rotation or reversal of the vertices would produce exactly the same curve.
> The fix was extensive to the curve fitting algorithm however it was isolated from the polygon code by observing the convention that all access to interpolated points was exclusively thru one method. This preserved the former polygon interface to the curve processing.
> It also allowed the slope calculation to be factored out into a few lines of code. This provided hooks to allow subclasses to do some other interesting variations.
> Once that code got into squeak, there was a request for jigsaw pieces. So a subclass MixedCurvedMorph was provided to allow the user the choice of a sharp bend (corners) or not at any vertex.
> The effect was that two polygons could share an edge with exactly the same shape between corners.
> The expressive power of these curves was best described by Subbu's keen eyed daughter who described them as "putty".
> [Enh] in 7001 there are now Curvier polygons and curves here is the next iteration... MixedCurves.
> Because I was working on polygons the changesets for curvier and mixedCurves accumulated other polygon repairs. Some of those repairs/refactorings are proposed for inclusion in the repairs in
> PolygonMorph Issues
> Getting curvier repairs into etoys/squeakland.
> Most of the work is done. The main work would be in adapting things to the current shape of polygon e.g. the presence of the vertex cursor.
> Alternately the changes could be completely in a PolygonMorph subclass. The curvier changes started out there and then as I was trying to get them accepted, Ned Konz noted they should be moved up to Polygon.
> Which I proceeded to do. Providing a preference encapsulated in the query #isCurvier to return to the old polygon behavior.
> In CurveMorph for example #isCurvier is redefined as false for backward compatibility. So far I have had no complaints from squeak-dev users. This might not be a telling test.
> More importantly, Cuvier polygons and Mixed curves have gotten some praise from etoy users, mostly Subbu and family.
> Their main selling point is they give more power to the user and allow a polygon path for objects that want to look like ovals and rectangles. One of the reasons this is desirable is that polygons do their own rotation. Rotated polygon ovals do less screen damage than rendered ellipses. So you get a bit more performance.
> They are also the underpinning for several add on projects. In my experimentation I found I could take a diamond or rectangle shaped polygon and multiply the slopes at all vertices by a constant weight. You get objects with varing curves including ones that could serve as rounded rectangles. (no pesky invisible corners needed.) Translucent colors are preserved during the rotations, unlike with rectangles. The shapes produced are quite pleasing to the eye.
> I have tried pushing things along by working on spec and sending the results to Yoshiki. This did not work out well.
> I am willing to provide more effort only if a path for getting this work into the image is agreed upon.
> The code has been written and should be adaptable to the present state of etoys. I would estimate about a few days work to get it into a joy ride version and then some time to fix up any problems that might reveal.
> I would expect a minimum of problems. Those kind of theoretical expectations are rarely what practical reality provides.
> Yours in curiosity and service, --Jerome Peace
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:
More information about the Etoys-notify