## FDL Cubic Bezier Spline

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

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.

## Use of Singularity in Scrutinizer

In 2004, I had an idea to write a series of TechNotes to help developers obtain a basic understanding of principles in computational geometry.  I also decided to start a blog and authored a small AS library to go along with the material.  It seems that so many people turn to high-priced books for information and I simply wanted quality material to be available for free.

The Singularity library began in AS2 and was eventually ported to AS3.  Although never intended for commercial use, I now have dozens of requests for use of the library in commercial applications.  One recent application was in a set of new features for a product called Scrutinizer ™.

The upcoming release will use the arc-length parameterized quad. Bezier to draw dashed arcs.

While the Singularity package is no longer available (its capability ported to and expanded upon in Degrafa), I’m glad that a lot of people learned something new and applied it to actual applications.

## New Strokes in Freehand Drawing Library

Based on beta feedback, I’ve added two new strokes into the Freehand Drawing Library.  The first is an alternate variable-width stroke.  The standard variable-width drawing emulates a brush stroke that begins at negligible size and its width increases with speed (like pushing down harder on the brush).  The alternate stroke begins at a maximum size (initial point is a dot) and its width decreases with speed.  This is an experimental implementation and the creation as a separate stroke illustrates how to modify standard strokes for custom usage.  A screenshot is provided, below.

PolyLine is a constant-width stroke that interpolates a set of points.  An interesting feature of this stroke is that it is permanently non-interactive, that is it bypasses the normal stroke interaction for mouse or touch points.  Instead, the user manually adds vertices to the PolyLine.  Like any other constant-width stroke, it is assigned a solid-line drawing engine by default, which produces the drawing below.

The dots are manually added by the demo program.  In the future, they will be draggable.  This demo is currently a placeholder to test the spline drawing engines, now under development.

Because of these new additions, I’ve opened up several more beta slots.  There are currently two remaining.

The FDL is a serious commercial product, designed for serious commercial applications.  All FDL distributions include source code with full ASDoc.  As such, a small three-figure license fee is required to join the beta.  Beta users, however, get free upgrades for the life of the product.

If you have an application that could benefit from the FDL, especially if it is mobile or involves spline drawing, please contact me at theAlgorithmist [at] gmail [dot] com to discuss joining the beta program.