Bezigon Tool
-
Adding further commentary to this after trying out the Quick Pen Tool in Illustrator.
This is, like I've said in my earlier comment, a simple combination arc spline and polygonal segments. This is a useful addition, but does not warrant a separate tool. It is a pen tool mode. See Boxy SVG, which, of all the software out there, correctly categories it as one of the Splines. You have Quad Bezier, Cubic Bezier, Basis, Polygonal. The single most interesting mode of pen tool is catmull rom, which is used extensively in animation. Again, too out of depth to explain the mathematics of this.
In case you didn't realise, Catmull Rom is implemented in a modified form within Affinity Designer. It's the smart pen mode.
If @VectorStyler you want a perfect, simplified, intuitive view of how to create spline modes, please study Boxy SVG's free, web interface. It is a designer's dream come true. Notice the wonderful curve segment highlight you get when you hover over the curve, showing which part of the curve you're about manipulate. When you're dealing with complex curves (such as in fonts), this is useful to have as visual feedback. Notice also the Boxy SVG correctly and logically merges the Spline Tool and node-manipulation function. The only other software to do this is Xara Designer.
Now coming to Quick Pen Tool in illustrator. What does it actually do? It combines Arc Spline and Straight Line Splines, simple as that. Every consecutive segment you draw can either be a full circular arc, or, if you make a switch in the contextual menu, a straight line.
How is it different from Bezigon? Bezigon Tool combines Quad Bezier and Cubic Bezier with Polygonal Segments. This means that where you now click drag to create smooth curves, in Bezigon, this is achieved automatically.
In FreeHand, if remember correctly, if you simply click, you get straight lines. You hold down Alt and click, you get an averaged curve that connects two points, which is intelligently smooth. You don't need to change anything. Hope this adds more insight and help you get this right.
I would love for Boxy SVG/Xara's simplicity and logical coherence in VS, too.
-
@Daniel I added this to the backlog and will review if can be done by 1.3
-
Thank you so much! That would be amazing.
-
Further to our conversation on email, I agree with you @VectorStyler: the pen tool has actually made giant leaps over both Illy and Affinity Designer. Just a note. No need for response.
-
@Daniel @VectorStyler I found this website called, "Bezier-rs Interactive Documentation" today as part of the fast developing online open source graphite app. I love that it's interactive and explains through its ability to interact with. I thought you might appreciate it. Graphite has a lot of nice features that are worth checking out.
-
Now, we have a working Bezigon tool! Which is brilliant. Thank you @VectorStyler. I didn't want to split this conversation into multiple threads. Immediately upon using it, a number of things came to mind. But it is best illustrated with a gif.
Notice the difference between the Bezigon in FreeHand and Bezigon in VS.
https://imgbox.com/UCBeQoh3 - In the link there are two different gifs. So please click next to see the second gif too.
I might be missing something here, so please let me know if I am doing something wrong. Once again, thank you!
I also wanted to note that we need the concept of tangential node as a part of this tool. Tangential node essentially snaps the node handle parallel to the node. I can record a gif for this later.
This is an improvement that you can implement as a part of the node tool so that tangential nodes are available across all curve-making tools.
EDIT:
I think I know what's going on:
In FreeHand: Simple Click --> Cusp Node. Alt Click --> Smooth Node. So if I start like this:
Simple Click --> . Alt Click --> Smooth node. Simple Click --> This creates a perfect semi-circular curve. This is because the last simple click, makes the previous node perfectly symmetrical. I can do the same on the other side and create a perfect circle.
In VS, the behaviour seems slightly different. Wondering what I am missing.
-
@Daniel I added this to the backlog and will try to improve it.
-
My vociferous campaigning to get this tool into more apps has paid off in one more place: PhotoLine now has Bezigon as a subfunction of the curve creation tool!
-
@vectorstyler: Working on the Bezigon in VS, there are quite few kinks. Me and an old software colleague spent some months basically reverse engineering the FreeHand implementation. It is tested exhaustively. Every edge case works. And it is written so that there are zero dependencies. So you can free use it. We've released it under MIT License, permissive use with total control to modify as you wish. We wrote it originally for PhotoLine integration. So the readme files address PL. But ignore those, you still have solid code.
-
@Daniel Can you describe these issues?, just so that I understand them
-
@VectorStyler: Hey! Basically, far from being a simple and straight forward algorithm, Bezigon has a lot of edge cases, which FreeHand has very cleverly coded. We basically mapped out all of these edge cases exhaustively by hand and compared them one at a time.
Pie, eye and shield are the three best cases for explaining this:
PC - Plain Click, MC is modifier click.
In VS, try this sequence:
MC + PC + MC + PC + Close the shape with PC. This should produce a perfect eye shape. That is, two circular arcs joined at the sides. The curve approximation is not accurate.
Shield: Start with a PC, then MC, PC (for corner), MC, PC (for bottom corner) - you'll see that curve approximation suffers. The shield is the perfect case for trying this out. I will record a video for you later.
Meanwhile, if you compile and run the code, you'll see how it works for every edge case. We'll document the edge cases clearly and completely later.
Meanwhile: Here's how we figured it out:
We worked off of screenshots and video recordings of FreeHand Bezigon producing various shapes, a set of measured handle lengths from the tool itself, and the option to test each hypothesis against the real thing by drawing the same click pattern in both. I fired up my FreeHand 11 and tested every single edge case, measured handle lengths by taking screenshots, and then manually measuring distances in Affinity (which now has the feature of turning measures into objects). We also used the manual to kind of try and figure out the logic.
We built a minimal C++ tool first, click to place points, see lines, and then added one rule at a time, checking each against FreeHand immediately.
The first discovery was handle length. FreeHand's Bezigon uses a fraction of the segment length as the handle length. Three measurements gave 0.39, and it stayed at 0.39 across every configuration we tried. That number was not the hard part.
The node types were straightforward. A plain click makes a corner; a modifier click makes a smooth node. Where things got interesting was what happens to the handles of each.
Smooth nodes were the easy case. The tangent is the direction from the previous node to the next. That is what any spline library does.
Corners were the puzzle. At first we pointed the handle at the neighbouring node. That works for straight segments but produces visibly wrong curves when the segment is supposed to be an arc. The shape comes out pinched, and the arcs get progressively less circular as you add nodes.
The rule that fixed everything was this: at a corner adjacent to a smooth node, the corner's handle is the reflection of the smooth node's tangent across the chord.
It sounds obscure, but it is actually the exact property of a circular arc. In any circle, the tangent at one end of a chord and the tangent at the other make equal angles with the chord, on opposite sides. So if you know one tangent, the other is its mirror image. FreeHand uses this trick to turn segments between a corner and a smooth node into proper arcs.
The last thing we figured out was how FreeHand treats the start node when a path is closed. There are two variants: plain close and modifier close. Plain close leaves the start node's type unchanged, modifier close forces it to a corner. There is a further special case for a plain-closed path whose start and second nodes are both corners, where the handles become collinear along the line to the second node, but only if the last node is smooth. This last condition took us the longest to find. The bug only manifested on one specific click pattern.
Once that rule was in, the shapes snapped into place. The eye, the pie wedge, the shield, all of them matched FreeHand's output.
The thing I underestimated was how much of this would come down to looking at two nearly-identical images side by side and asking "what's different here?". There is no shortcut. You cannot derive the rules from first principles; FreeHand has quirks that are not mathematically optimal, and you only find them by comparing outputs.
It took 2 months of work to make it all work perfectly. I did no coding. My friend, Taras, wrote all the code. I merely tested the visual output.
-
@Daniel I will try to improve this
