Archive

Posts Tagged ‘Freehand’

QA and Change Requests

August 7, 2012 2 comments

Okay, well, I hope that tells you where my summer is at this point and helps explain the lack of posts.  With some luck, I’ll be back to work on the Freehand Drawing Library later this month.

Thanks!

Categories: General Tags: , , ,

Editing A Cubic Bezier Spline

May 7, 2012 Comments off

A couple months ago, this was something I believed I would never say about the Freehand Drawing Library.  Now, the library is and always will be a drawing library. Editing is not part of the core library architecture, however, it is something that requires a level of support inside the library.  In the past, this was accomplished by caching the sequence of mouse motions used to define a stroke.  The points could be edited and manually assigned to a stroke, either all at once or in an ENTER_FRAME event to animate the stroke.

This works cleanly with a simple interface for typical strokes, i.e. touch-move-release motions.  Now that the FDL supports splines and possibly other constructs that stretch the definition of a stroke, what about editing more complex drawings?  I want to maintain a light interface and not make editing operations an integral part of the library.  That inevitably leads to interface and code bloat in an attempt to satisfy every possible combination of customer-created editor.

I think it was the movie ‘War Games’ that popularized the phrase, ‘always leave yourself a back door.’  The back door to stroke manipulation outside normal FDL methods is to use arbitrary name-value parameters.  Every stroke has the ability to access or mutate arbitrary data objects.  It’s only two methods in the API, but they provide a wide variety of capability to custom strokes.

I added a simple spline editor to the PolyLine demo as an illustration.  After creating a spline (by clicking the end button), the knot/tangent display is overlaid on top of the stroke as shown below.

The spline knots are already available since they were manually assigned to the stroke.  The tangent information is entirely encapsulated inside the drawing engine, inside the stroke.  That information is obtained by the demo via a parameter request,

__stroke.getParam( “tangent” + i.toString() );

It is the responsibility of each stroke class to document all custom parameter queries and settings.  The above query returns in- and out-tangent values in an Object and that information is passed to the editor.  Knots may be dragged, which cause a parallel shift in the tangent.  The new knot and tangent information is conveyed back to the stroke with a sequence of parameter settings,

__stroke.params = { “changeKnot”:{vertex:index, x:editor.knotX, y:editor.knotY} };

or

__stroke.params = { “changeInTangent”:{vertex:index, x:editor.inTangentX, y:editor.inTangentY} };

__stroke.params = { “changeOutTangent”:{vertex:index, x:editor.outTangentX, y:editor.outTangentY} };

If a spline drawing engine is assigned to the PolyLine, it passes this information onto the internal FDLIntepolatingSpline instance.  A non-spline engine (line segments) ignores the parameters.

The screenshot below shows the result of a knot drag.

After dragging the middle vertex, the following screenshot shows the result of editing the first-vertex out-tangent.

This is all supported by the existing architecture, but there is one wrinkle.  If the edited spline is to be saved and then redrawn at a future time, we must have the facility to record the tangent edits *and* bypass the tangent Command when the spline is reconstructed.

I added an auxData parameter to the StrokeDataVO, which allows arbitrary auxiliary data to be recorded for a stroke.  It’s easy to deep-copy an Object with a ByteArray, so preserving immutability was no problem.  Now, by adding support for a ‘redraw’ parameter in the PolyLine stroke, the spline can be redrawn with arbitrary tangents supplied by external data instead of the tangents computed by the injected tangent Command.

FDL Cubic Bezier Spline

April 30, 2012 1 comment

The cubic bezier spline drawing engine in the Freehand Drawing Library is now complete.  As I mentioned in the prior post, the drawing engine fits into the FDL architecture and allows a spline to be treated as a stroke.  The CubicBezierSpline drawing engine contains a reference to a FDLCubicBezierSpline, which handles all the spline computations except for tangents.  Tangents are implemented via a Command pattern (with the spline as the receiver of the Command).  Three tangent commands are now available for cubic splines.  The NormalBisector Command uses the same algorithm as described in this TechNote.  The CatmullRom Command uses an algorithm similar to that in Catmull-Rom splines.  The Corner Command can be applied on a per-vertex basis and constructs splines with hard ‘corners’ or only G-0 continuity at a join point.

While the CubicBezierSpline engine manages the internal spline and tangent commands, the spline and tangent computations can be easily used outside the FDL in a purely computational context.

Every FDL spline is arc-length parameterized by default, using a fast algorithm for on-the-fly parameterization.  So, every coordinate request, i.e. getX(t) and getY(t) is actually computed based on normalized arc length in [0,1].  So, getX(0.5) returns the x-coordinate at approximately half the length along the spline.

Splines are implemented as drawing engines for a PolyLine stroke.  As always, a drawing engine is injected into the stroke,

__data.drawingEngine = “net.algorithmist.freehand.engine.CubicBezierSpline”;

Arbitrary parameters (name-value pairs) may be assigned to any drawing engine.  All splines require a ‘tangentCommand’ parameter to inject the Command used for tangent computations.  The normal bisector algorithm is applied as follows.

__data.engineParams  = {“tangentCommand”:”net.algorithmist.freehand.commands.NormalBisector”};

or, substitute the Catmull-Rom algorithm, if desired,

__data.engineParams  = {“tangentCommand”:”net.algorithmist.freehand.commands.CatmullRom”};

then, assign the data provider to the stroke,

__stroke.data = __data;

The cubic bezier spline supports auto-closure with G-1 continuity across the full set of tangent commands since the closure algorithm is inside the Command itself. Here is a screenshot,

and here is a screenshot of an open spline using the Catmull-Rom algorithm for tangent computations,

The next step is editing the spline by adjusting knots and tangents.  I was originally skeptical how far the architecture could be pushed in terms of a ‘drawing’ that was not in line with a traditional stroke motion, i.e. press-move-release.  Editing the mathematical properties of something like a spline seemed out of the question at first thought.  So far, I’m glad the architecture is holding up without having to hack anything in.  I suppose a demo containing a spline editor will be the ultimate test 🙂

As an aside, spline editing facilities are not part of the library; they are provided as one of the many demos available to FDL users.

Progress on Freehand Drawing Library Splines

April 25, 2012 Comments off

Splines in the Freehand Drawing Library have been a challenge in two areas.  First, the concept of freehand drawing is centered around strokes.  Strokes are defined by sequence of mouse/touch points that begin with a press, continue with a sequence of moves (while pressing), and end with a release.  An interpolative spline is defined with a series of interpolation points or vertices and continuity conditions at the join points.  There is no concept of press-move-release. Fortunately, the FDL architecture is sufficiently general to allow points to be artificially added to strokes.  The UI issue with splines is creating a user-friendly mechanism for identifying the last interpolation point.

The second issue is editing, both vertex and in/out tangents at each vertex.  Since all strokes allow their input points to be either manually defined or cached and returned via user input, editing is not part of the core library.  It’s impossible to create an editing system that is general, maintainable, and equally satisfies all prospective users.  When it comes to splines, I don’t want to add more methods to the IFreehandDrawable interface simply to accommodate new features.  New methods should be added only with careful thought and because it makes good, long-term sense for the library.  Fortunately, ample back-doors exist to arbitrarily set and retrieve properties for various stroke engines through parameter access and mutation methods. I plan to use that existing scheme to expose parameters that facilitate spline editing.

Tangent construction is handled by a Command pattern that is applied across the engine spline or at individual vertices.  The tangent command is injectable and its fully qualified class name is part of the stroke engine parameter set.

There is currently one spline-based stroke engine for the PolyLine stroke.  The CubicBezierSpline engine is based on the cubic bezier spline in this TechNote.  The tangent construction is handled by a NormalBisector Command that is injected into the stroke engine.  I also plan to add another tangent command that uses the same approach as Catmull-Rom splines.  This provides two different cubic bezier splines with a single code base.  I also plan to provide a corner tangent command that allows sharp corners to be inserted into otherwise continuous splines.

One final feature of the architecture is the decoupling of the spline computations from the drawing facilities in the FDL.  This is similar to how I decoupled spline computations from the drawing architecture in Degrafa.  There are no actual spline computations performed in the CubicBezierSpline drawing engine.  It contains a FDLCubicBezierSpline, which is a concrete implementation of the IFDLInterpolatingSpline interface.  FDLCubicBezierSpline is completely independent of the FDL.

The final implementation issue is on-the-fly arc-length parameterization.  In order to draw the spline with line decorators, all requests for x-y coordinates along the spline are based on normalized arc length, not the spline’s natural parameter.  In other words, getX(0.5) returns an x-coordinate of a point that is approximately one-half the length along the entire spline.  The arc-length parameterization is optimized for monotonically increasing or decreasing normalized arc-length queries.  It presumes constant redraws of the spline, so there is no pre-computation/lookup applied in the parameterization.

A screenshot of work in progress is provided below.

During debugging, the outer edge of the convex hull of the bezier control points is drawn (in black).  The red dots are points on the cubic bezier spline at (approximate) uniform normalized arc length.  The next step is to apply a line decorator to actually draw the spline.  Another advantage of automatic arc-length parameterization is relatively easy computation of the Δs to use in point-to-point drawing of the spline.  This mimics a freehand curve like all the other engines, which allows automatic application of the existing line decorators in drawing the spline.

Categories: Flex, Math, Portfolio Tags: , , , ,

Arrowed Arcs in Freehand Drawing Library

January 31, 2012 Comments off

As promised, arrowed (quadratic) arcs are now in the Freehand Drawing Library.  They use the same two-point stroke as arrowed lines, but a different drawing engine.  Since three points are required to draw a quadratic arc, the free constraint is automatically computed based on a curvature parameter and a multiplier of the segment length between the two endpoints.  The curvature parameter controls whether the curve is concave upward or downward and the multiplier controls the overall general curvature (i.e. smaller values produce overall flatter curves).

A screen shot is provided below.

Start and end arrows are optional, so the ArrowedArc engine offers a back-door to creating simple quadratic arcs.

Lines and arcs use the same stroke, i.e.

import net.algorithmist.freehand.twopoint.TwoPoint;

private var __stroke:TwoPoint = new TwoPoint();

Simply inject the desired stroke engine,

__data.drawingEngine = “net.algorithmist.freehand.engine.ArrowedArc”;

__stroke.data = __data;

Then, draw and have fun.  I have not yet coded arc decorators, so only solid-line arcs may be drawn with the current beta.

I’ll add one more stroke to the library before RC1 and hopefully blog about it some time next week.  Thanks for your inquiries to date!

Arrowed Lines in Freehand Drawing Library

January 26, 2012 Comments off

Drawing lines does not sound very interesting, but in addition to my own app. development, another user expressed a desire for animated arrowed lines.  So, a new two-point stroke has been added to the library.  The TwoPoint class is the base for a family of classes in which a stroke is defined only by a starting point and the current mouse/touch point.

In keeping with the FDL architecture, an engine is assigned to a two-point stroke.  Two engines will be provided in the first release candidate, arrowed lines and arcs.  The start and end arrows are optional, so these engines provide a back-door to drawing lines and arcs.  Not sexy, but the existing line decorators are applicable, so it’s incredibly easy to draw dotted or dashed lines.

Since the point sequence to a stroke may be simulated in an animation, it’s now very easy to draw animated dashed or solid, arrowed lines.  Here is a screen shot from one of the demos.

Injecting a new line decorator is a matter of assigning the fully qualified class name of the decorator,

__data.lineDecorator = “net.algorithmist.freehand.decorators.SolidLine”;

or

__data.lineDecorator = “net.algorithmist.freehand.decorators.DashedLine”;

then, re-assign the stroke’s data provider,

__stroke.data = __data;

There are still a couple beta slots open, so if you are interested in developing a Flex-based application (mobile or otherwise) involving freehand drawing, please contact me at theAlgorithmist [at] gmail [dot] com.  There is a small, three-figure license fee that is a one-time cost.  Beta users get free upgrades for life!

I’ll be posting a roadmap for the anticipated release cycle shortly, so even if you are not interested in Flex/Actionscript development, say tuned.  A subset of the Freehand Drawing Library may be coming for JS or Corona developers.

New Drawing Engines for Freehand Drawing Library

January 9, 2012 Comments off

The upcoming beta for the Freehand Drawing Library now has a single constant-width stroke and three drawing engines.  The basic stroke is architected to work with any drawing engine (IDrawingEngine instance).  The StrokeDataVO contains both the fully qualified class name of the IDrawingEngine instance and an engineParams Object to pass arbitrary parameters to any drawing engine.

The three drawing engines are

1 – SmoothedStroke: Constant-width equivalent of the algorithm used in the variable-width Freehand stroke.  This algorithm allows cusps or sharp angles in the stroke.

2 – ConstantSmoothing:  Same engine as #1 except that smoothing is constant.  Cusps are not possible.

3 – Lagged:  This is an experimental engine that implements lagged smoothing over a small number of prior mouse moves. The entire stroke is redrawn from scratch after every move.  This produces a variety of interesting strokes that move in a serpentine fashion while the stroke is drawn.  I think this one would be fun for a kid’s doodling application.

A screen shot of the lagged drawing engine is shown below.

With the current FDL architecture, all three engines can be interchanged with the same basic, constant-width stroke.  And, each drawing engine can be used with any of the three available line decorators (solid, dashed, dotted).

One stroke, nine different drawings 🙂

I have a few minor details to clean up and then a new beta (0.95) will be released.