Bezigon Tool

Daniel

This is my giant, practical middle finger to Adobe! Fuck you, Adobe, for killing FreeHand.

It is here feckin' finally:

The Bezigon package is attached as Bezigon-packages.zip.

It contains two versions of the library and the documentation. You only need two files to integrate either version into Vectorstyler: bezigon.h and bezigon.cpp. Everything else is for testing, the demo, or reference.

Which version to use

Bezigon 4.2.0 has three node types: Corner, Smooth and Tangent.
Bezigon 2.2.0 has two: Corner and Smooth. It is about half the size.

On paths made only of Corner and Smooth nodes, the two versions give identical handles. Use 4.2.0 if VectorStyler needs Tangent nodes. I highly recommend it. Otherwise 2.2.0 is the simpler choice.

The permutation documents appear in both version folders and in Technical Documentation. The copies are identical, and the duplication is deliberate so each folder stands alone.

What each file does

bezigon.h is the public interface: the node types, make_node, close_path, set_node_type, compute_handles, drag_handle, and in 4.2.0 segment_is_straight and handle_axis.
bezigon.cpp contains all the rules. It depends only on the standard C++ headers <vector> and <cmath>, and has no global state, I/O or exceptions.
main.cpp is an interactive demo that runs on Windows with the EGE graphics library. It shows how the functions are called and lets you test every gesture. It is not part of the product.
demo_scenes.h (4.2.0 only) holds seven example paths, used by the demo keys 1 to 7 and by the tests.
test_bezigon.cpp is the test program. It needs no window and checks the rules across thousands of cases. Build it with the same compiler and flags as VS to confirm the results match on your toolchain. Expected results are in the README.
The permutation documents show every combination of node types, closes and edits, with a picture for each case. The Corner, Smooth and Cusp document covers both versions. The Tangent document covers 4.2.0 only.
The Technical Reference is the document to read first. It covers the API, the rules, the VectorStyler integration steps, and how degenerate input is handled. The History and Derivation explains how each rule was reached: the formulas, the FreeHand and Xara comparisons, and where we overrode FreeHand for intuitiveness.
README.md is a short overview with the test commands and a manual checklist for the demo.

Further note: You will see PhotoLine addressed throughout because we wrote it with the intention of initially just giving it to PhotoLine, but then changed our minds. So ignore this. The code is software agnostic.

How we used AI: We used AI extensively to test and debug the code we wrote. The model used was Claude Opus 5.5. We used AI extensively to derive formulas from screenshots. This is well documented within the history and derivation document. AI was used to create permutation tables which we then checked against FreeHand. AI was also used to give structure to our original brain dump and produce read me files, and technical references. The code itself was hand written by two extremely patient human beings: Vira Daniel & his long-suffering mate Taras Vynnychenko who obliged me with this mammoth project. He wrote this while he and his neighbours are still under Russian occupation. I wrote zero code. But I provided the complete creative direction to the entire project.

Edit: Permutation tables will be updated with exhaustive screenshots: Its partially filled because I got tired and lazy. But I have checked every single instance in FreeHand.

Daniel

I created a demo application of both versions for bezigon for those who want to try it: https://limewire.com/d/luGLt#jogenjIi9V - It works on Windows only. It also has demo instructions in the pdf. So you can play around with it. It might throw a warning when you open it because it has no digital signature. But it costs $$$ to get digital signature... so pardon me.

Boldline

@Daniel Would you be able to give a brief overview/explanation of what you're working on with the bezigon code and how that related to what is currently installed in VS today? From what I gather, there are some behaviors found in Freehand that are not working as smoothly in VS? thanks!

VectorStyler

@Daniel said in Bezigon Tool:

I created a demo application of both versions for bezigon for those who want to try it: https://limewire.com/d/luGLt#jogenjIi9V - It works on Windows only. It also has demo instructions in the pdf. So you can play around with it. It might throw a warning when you open it because it has no digital signature. But it costs $$$ to get digital signature... so pardon me.

This is good. Thanks a lot!

Daniel

@Boldline:

It is much easier to explain this in a video. I am going to record one tomorrow. For both VS and PL devs.

Daniel

@boldline @vectorstyler : https://youtu.be/w3ieED1z4gM - Here's the full breakdown.

The basic secret to the correct implementation is simple.

Every segment's handle is 39% of the segment length on either side, and every handle point points straight at the previous node until the next node is placed. In other words, every handle lies on the chord between two nodes until the next node is placed. That is the secret to Bezigon. At the moment, VectorStyler's implementation does not follow this logic, hence the awkward shapes it builds.

The loss in curvature becomes exponentially worse as the distance between the nodes grow.

Daniel

@vectorstyler: Just to add to this: We managed to test our algorithm further and we're extremely happy to say: We're off from FreeHand's at most by 0.008%, and typically about 0.005%, of each handle’s length. That is, 1 part in 13,000–20,000. The direction difference is effectively zero, at most 0.0003°. So that is a level of accuracy that you thankfully do not need to reproduce painfully. Please have a look at our algorithms! Thank you!

VectorStyler

@Daniel said in Bezigon Tool:

Please have a look at our algorithms!

I will try to include it in the next build. Thanks!

Daniel

@VectorStyler: At this point, you must think I am spamming this thread, but I promise this adds a great deal of value to what you're doing. My colleague who helped with the writing reverse engineered the number, 0.39 from pure screenshots. He did use AI, but even then - it is quite brilliant that he did it. Albeit he did not have to. Blender had worked it all out!

Found this brilliant piece of code from a Blender thread, which of course, is Open Source:

We use: 0.39 × own segment. Their comment explains why: a Bézier curve best approximates a quarter circle when the handle is 0.5519 of the radius, and dividing that by the chord, √2, gives 0.39.

This is it.

if (ELEM(BEZIER_HANDLE_AUTO, type_left, type_right)) {
    const float3 prev_diff = position - prev_position;
    const float3 next_diff = next_position - position;
    float prev_len = math::length(prev_diff);
    float next_len = math::length(next_diff);
    if (prev_len == 0.0f) {
      prev_len = 1.0f;
    }
    if (next_len == 0.0f) {
      next_len = 1.0f;
    }
    const float3 dir = next_diff / next_len + prev_diff / prev_len;

    /* The magic number 2.5614 is derived from approximating a circular arc at the control point.
     * Given the constraints:
     *
     * - `P0=(0,1),P1=(c,1),P2=(1,c),P3=(1,0)`.
     * - The first derivative of the curve must agree with the circular arc derivative at the
     *   endpoints.
     * - Minimize the maximum radial drift.
     *   one can compute `c ≈ 0.5519150244935105707435627`.
     *   The distance from P0 to P3 is `sqrt(2)`.
     *
     * The magic factor for `len` is `(sqrt(2) / 0.5519150244935105707435627) ≈ 2.562375546255352`.
     * In older code of blender a slightly worse approximation of 2.5614 is used. It's kept
     * for compatibility.
     *
     * See https://spencermortensen.com/articles/bezier-circle/. */
    const float len = math::length(dir) * 2.5614f;
    if (len != 0.0f) {
      if (type_left == BEZIER_HANDLE_AUTO) {
        const float prev_len_clamped = std::min(prev_len, next_len * 5.0f);
        left = position + dir * -(prev_len_clamped / len);
      }
      if (type_right == BEZIER_HANDLE_AUTO) {
        const float next_len_clamped = std::min(next_len, prev_len * 5.0f);
        right = position + dir * (next_len_clamped / len);
      }
    }
  }

https://tikz.dev/library-edges - And then, there is also this library, which again uses the same value, rounded up 0.3915... So we hit the jackpot.

From these, we have two more suggestions. The ability to clamp handles and to approximate true circles. I'll explain more later.

VectorStyler

@Daniel Thanks this is good!

VectorStyler

@Daniel Is the "Tangent" node type same as "Symmetric"?

Daniel

@VectorStyler: No. Tangent or connector node is not the same as symmetric:

Sharp - Basically has no handles - Straight line segment: But in our algorithm, we have made Sharp nodes to have handles because this means there is no need to convert them. You just pull the handle.

Cusp - A subtype of Sharp node, where both or one of the handle exits and can be moved in any direction independent of each other.

Smooth - Both handles collinear but can be sized independently.

Symmetric - Both handles collinear and locked to same size.

Connector/Tangent Node - Node that sit at the transition between straight line and curved segments to help form mathematically precise transitions so there are never any kinks. This is achieved by having the handle follow the direction of the straight line exactly. A tangent node is only really useful if it has one handle, but it is possible for it to have two handles. In every case, the handles always point back at the chord of the adjacent nodes. When the adjacent node moves, the corresponding facing handle moves with it.

The orange triangle is a tangent node and the handle lies on the chord to the square node forming a mathematically precise transition. When you move the red node, the tangent is repositioned. Like so.

This guarantees that I don't need to worry about my transition. Our documentation exhaustively explains this.

Kritter

Just wanted to say that I'm following this with great interest and I look forward to buying VectorStyler once you have an implementation of the tool working the way Daniel has shown it in his YouTube clip.

The Bezigon tool is infinitely superior to the Pen and I would be so happy to have a version of the 'Freehand implementation' on a modern Mac

VectorStyler

@Daniel said in Bezigon Tool:

The loss in curvature becomes exponentially worse as the distance between the nodes grow.

Which version of VectorStyler is this from?

VectorStyler

@Daniel said in Bezigon Tool:

Our documentation exhaustively explains this.

The documentation also contains editing step. Does this mean that the Bezigon tool can edit existing shapes? or that the Node tool should function as in this documentation?

(I should try Freehand somehow)

VectorStyler

@Daniel said in Bezigon Tool:

The Bezigon package is attached as Bezigon-packages.zip.

The "Bezigon 4.2.0" could also contain some important open path cases, just to see how the start/end tangent directions are for open paths.

larsherold

@VectorStyler

@VectorStyler said in Bezigon Tool:

(I should try Freehand somehow)

You can try FreeHand - it works "flawlessly" on Windows 11. (Using it daily myself...)

I'm safekeeping a FreeHand MX Installer.exe (v. 11.0.2) that installs a trial version on Windows 11. Runs just fine in Win7 compatibility mode.
There is an extensive built-in manual, but I have the 400+ pages PDF user manual from MacroMedia too.

Furthermore Adobe released perpetual serial numbers for MacroMedia products when they shut down the license server, after the CS2 era.
After all, a lot of customers owned licenses for FreeHand MX, Director MX etc., so they were obliged to allow re-installation of these.

Just say the word - love to be of help here!

Best regards
Lars Herold

Daniel

@VectorStyler: The one before the last patch.

Daniel

@VectorStyler: The rule is always simple. And you can understand this if you look at the Tangent permutation table. The handles always follow the chord of one or the other neighbouring nodes. Always.

Daniel

@larsherold: You don't need to this anymore. Thankfully. You can create a portable version of FreeHand. It is extremely simple. Install FreeHand using Sandboxie within a Sandboxed location. Now you have a copy that has zero dependency on Windows registries. You can copy the contents and use it anywhere!