Bezier Curves

X-Plane currently has a bezier curve model, available for line and polygon data in the apt.dat file and some DSF polygons (primarily lines and draped polygons).

The current scheme is based on pairs of vertex and control points. This proposal is for a next-gen encoding of bezier curves that is more flexible.

=Current Encoding=

The current encoding, for a bezier-enabled entity (flagged on the entity level) is to have a single control point for every vertex. That control point is the control point after the vertex; to form a cubic bezier, the opposite-side control point is extrapolated and used for the previous curve.

This scheme works well when a chain is made of a large number of "non-split" beziers (that is, beziers where the control points are symmetrical across nodes). But it requires inefficient special handling when there are split or non-bezier segments:


 * A control point is used in all cases, even for line segments, wasting storage space.
 * The change from curved to non-curved requires one extra vertex (with bezier) per transition.
 * A split bezier requires two extra vertices.

While these storage considerations are not critical for the apt.dat format at this point, they make the scheme inappropriate for roads, where storage consideration really matters.

=Proposed Encoding=

The proposed new encoding is to simply have an alternating sequence of points that are vertices and control points, e.g.

V C C V V C C V V V C C V C C V

The additional storage cost is some kind of flagging mechanism per vertex to indicate control point or vertex; for systems like X-Plane that handle only cubic beziers, there must be a rule of exactly 0 or 2 control points between vertices.

Assuming such "flag" storage can be efficiently encoded, the cost is:
 * Non-split beziers: 50% increase
 * Split beziers: 40% savings
 * Line segments within beizer: 50% savings
 * Transition from curve to segment: 33% savings

=Usages=


 * Apt.dat - a new record would insert a control point into the "point stream", allowing an alternating set of vertex types.
 * DSF - a per-vertex flag (perhaps the junction ID field being 0xFFFFFFFF) would separate control from vertex shape points in a road.
 * DSF - polygons would _not_ allow the new encoding.