AP - Curve thickness question

[DarkClown]

We are having a slightly different understanding of the CCW definition. As you correctly mentioned you are moving AROUND a closed surface (and since these onject types have no surface intersection it is very clearly defined). So you can either move CW (regardless where you start) or CCW - because you move AROUND the closed surface! In your example you clearly only move CW (unless you change your fixpoint you move around!. If you want to define CW or CCW you need a (ONE) point/area you can move around regardless of the shape of an object. In this case its a point anywhere within(!) the surface. To be more visual. Put a nail somewhere in the green area. This is you fix- or reference point for the definition of CW/CCW. Attach a string to the nail and a pen at the other end. Now try to draw the outline of the surface. You will realise that you never change th CW/CCW direction surounding the surface - regardles of the shape of the surface.

For your example and argumentation you move the fixpoint from inside the curve to outside the curve what I consider as "not allowed" for a valid mathematical definition in this case.

A probably even better explanation would be: Imagine you stand on the outline of the curve and start walking on the outline. At any point ask yourself: On wich side is the surface? On any point of the curve the answer will be the same: Either right or left - but it will never change as long as you keep following the outline and don't turn around.

[R C-R]

5 hours ago, DarkClown said:

If you want to define CW or CCW you need a (ONE) point/area you can move around regardless of the shape of an object. In this case its a point anywhere within(!) the surface.

As I think about it, "anywhere within the surface" is exactly equivalent to inside the curve -- no ambiguity about it or any need to arbitrarily declare any reference point outside the shape as "not allowed," or consider moving/looking/walking in a CCW or CW direction around the shape.

As I see it, the whole left/right side of a curve idea is a non-intuitive complication for a property that is easily & intuitively understood in terms of inside or outside the curve.

[DarkClown]

32 minutes ago, R C-R said:

As I see it, the whole left/right side of a curve idea is a non-intuitive complication for a property that is easily & intuitively understood in terms of inside or outside the curve.

It was brought up when discussing open curves that had no "Inside" "Outside" ... (But still a left and right from the starting point )...

[R C-R]

1 hour ago, DarkClown said:

It was brought up when discussing open curves that had no "Inside" "Outside" ... (But still a left and right from the starting point )...

Yes, I know that. But I still think the current implementation (storing the inside/outside **property** of the curve even when an open one has no inside or outside) is all we need, as well as avoiding the need for any arbitrary designated ‘starting point’ with allowed & disallowed positions, which I am sure some users would find confusing.

[Pšenda]

On 1/5/2022 at 6:08 PM, R C-R said:

We also need to consider carefully how this would or should work with the 'quick shapes' (cogs, stars, arrows, & so on) since they do not have nodes & thus no defined start or end nodes. For them, inside & outside is well defined & intuitively obvious, but left & right is not since it depends on the start to end node direction.

Shapes are "closed" curves, and therefore have Inside and Outside. The Right and Left sides are thus completely irrelevant to them, because they are reserved for "open" curves. How easy and how logical.

[R C-R]

4 hours ago, Pšenda said:

The Right and Left sides are thus completely irrelevant to them, because they are reserved for "open" curves.

That is what I meant about left & right not being well defined for 'quick' (parametrically adjustable) shapes. Regular closed curves have an "orientation" (viewable by enabling the "Show Orientation" option on the Node Tool context toolbar) as well as an option to reverse that orientation (via the "Reverse Curve" option on the context toolbar), but quick shapes have neither (because they have no nodes unless they are converted to curves).

So for regular closed curves it could be argued that the left & right sides could be defined in terms of their direction/orientation, but that does not work for quick shapes.

[DarkClown]

14 hours ago, R C-R said:

viewable by enabling the "Show Orientation" option on the Node Tool context toolbar

Really?
 

[R C-R]

7 hours ago, DarkClown said:

Really?

I said regular closed curves show an orientation. The curve in your example is an open curve.

EDIT: for open curves, you can tell the orientation from which end has a red node. For closed ones, the only way to tell is by enabling the  "Show Orientation" option, which adds a tiny, hard to see red marker.

[DarkClown]

Frankly spoken I see absolutely no reason why one should treat an open curve differently from a closed curve! Everything works the same. We are just discussing wordings here. And even the developers made that clear when adding the "use fill" checkbox in the parameter panael for (open) curves. But still they exclude open curves from some operations ... (From my perspective one might even discuss if there's a start and an end within a closed curve - while it's obvious that an open curve has them)

[Paul Mc]

4 minutes ago, DarkClown said:

I see absolutely no reason why one should treat an open curve differently from a closed curve!

I agree. I've done a lot of coding in the past with parametric curves and almost without exception they are all represented by a list of control points (nodes) which have a start and end and thus a direction (even if the UI doesn't show this). The conic section representation used for closed circles and ellipses make it easy to calculate the offset. Convert To Curves converts this to parametric form. Open and closed parametric curves are usually represented in the same way - the only difference is in the rendering usually with an attribute that defines whether the curves is closed or not. I'm impressed with passion in the above discussion about inside/outside & left/right etc. but this is a user perspective issue and not an implementation issue. The maths involved in calculating the offset curve is the same whether open or closed. i.e. (I'm guessing here because I have no sight of the source code) but I'd put money on the fact that the code for handling open curves is 90% there and just needs tweaking for open curves and the UI handling.

The direction visibility issue is only a problem in the UI. Blender does a good job of showing the direction of a curve using chevrons along the length of the curve.

I'm chipping in with this post because this caught me out this morning while working on a design which used thick curves with alignments that were not centre which I had to break and found that the alignment jumped to centre.

[R C-R]

6 hours ago, DarkClown said:

Frankly spoken I see absolutely no reason why one should treat an open curve differently from a closed curve! Everything works the same.

Not true. Open curves can be joined with other open curves; closed curves cannot be joined with any other curve, whether open or closed.

6 hours ago, DarkClown said:

And even the developers made that clear when adding the "use fill" checkbox in the parameter panael for (open) curves.

I am not sure what you mean by the 'parameter panel,' but if you mean the "Use Fill" checkbox on the Pen Tool's context toolbar, that applies equally  to open or closed curves. But there is an obvious difference in how the fill is applied: for closed curves, the fill everywhere follows the curve of the path, while for open curves it just fills across a straight line between the start & end nodes:

6 hours ago, DarkClown said:

But still they exclude open curves from some operations ... (From my perspective one might even discuss if there's a start and an end within a closed curve - while it's obvious that an open curve has them)

What operations are excluded for open curves? For example, both open & closed curves can be reversed & both can have any of the 3 stroke alignment properties. It is just that the inside & outside of open curves are undefined so those two alignment properties only have a visible effect if & when the curve is closed. IOW, it can be a latent property, in much the same way a start or end arrow can be assigned to a curve with a stroke & then the stroke width reset to zero, via the 'no line style' button. But like in this start arrow.afdesign example, if you set the line style to 'solid' the arrow becomes visible.

For closed curves, one node defines both its start & its end; for open curves there are two, one defining the start & the other the end. But both curve types have a direction that can be reversed. It is easy to see that for open curves because the red end node jumps from one end of the curve to the other when the 'reverse curves' button is clicked. The only way to see the effect of that button for closed curves is to enable the "Show Orientation" checkbox, where both items are on the Node Tool's context toolbar.

[R C-R]

7 hours ago, Paul Mc said:

I agree. I've done a lot of coding in the past with parametric curves and almost without exception they are all represented by a list of control points (nodes) which have a start and end and thus a direction (even if the UI doesn't show this).

The Affinity parametric shapes do not have nodes, they have parametrically adjustable properties. Many can be moved in different directions, but not in the same way or along the same paths that nodes can be moved. Consider for instance the Cog's number of teeth, radii, tooth size, notch size, or curvature properties; the Triangle's Top Point property; the Diamond's Mid point property, the Pie's angles & hole radius properties, & so on.

So for example, how would you define the start & end of any of the radii, size, or most of these other properties?

[Paul Mc]

Hi @R C-R sorry, but I think you may be confusing the parametric model used to define the high level shapes (like the cogs, conics etc.) with the underlying representation of the curve for drawing or after you apply Convert To Curves. All the lower level curves are represented by a list of control points. The higher-level parametric models eventually reduce to a set of individual lower level Bezier curves. Bezier curves have a direction and can be strung together to form longer curves. They can also be given thickness by calculating an offset curve.

I used the term nodes because of the node tool and the fact that the control points (that are referred to as nodes in Affinity) are used in the curve specification.

The higher level parametric models are not really curves but procedural methods by which a set of curves is constructed. A set of technical drawing procedures.

You are correct in saying that Affinity parametric shapes do not have nodes - they have parameters, some of which are positions on the canvas. Technically, Bezier curves are parametric curves - the parameters being the control points.

[R C-R]

13 minutes ago, Paul Mc said:

You are correct in saying that Affinity parametric shapes do not have nodes - they have parameters, some of which are positions on the canvas. Technically, Bezier curves are parametric curves - the parameters being the control points.

But the directional properties of the control points of parametric shapes are not directly comparable to the directional properties of the control points of Bezier curves. With few exceptions there are not even the same number of them, nor do they change the shape in similar ways. The former do not 'reduce' to the latter unless they are converted to curves, at which time the parametric control points no longer exist.

They are fundamentally different kinds of shapes, created with different tools that have very different options that are used to manipulate their varied & different kinds of control points in fundamentally different ways.

[Paul Mc]

Like I said there are two levels at work here: high level shapes and low level curves. They are completely separate and are only related because the high level shapes need to be converted to curves in order to be rendered to the screen. Normally this happens behind the scenes and the user isn't aware of it. If you change a parameter value then the procedure is re-executed and a new curve or set of curves is created.

That same conversion is also applied when you use the Convert To Curves function.

Just to be clear a cog, for example, is not a curve - it is a Bezier spline that has been created by a procedure that generated the (Bezier) control points based on computations driven by the input parameters. You don't think it is a curve because you can't see or access the nodes in the UI. They are there though, behind the scenes. If you drag one of the shape control points to a new position then the procedure gets executed again and a new set of control points is created and a new spline curve displayed. Click on Convert To Curves and the nodes appear. 

[R C-R]

37 minutes ago, Paul Mc said:

That same conversion is also applied when you use the Convert To Curves function.

Nope. When you apply the Convert to Curves function, the parametric control points no longer exist. They are destructively converted into how many ever nodes are required to duplicate the shape. If that is not done, there are no nodes, no clearly defined 'direction' for the path(s) the shape consists of.

Or as simply as I can put it, parametric shapes & curves are two different things in the Affinity implementation. Only one of them can be converted to the other. That is why there is a function is called convert to curves, but no convert to shape function.

[Paul Mc]

I think we are probably arguing over terminology here. Control Points is a term that is used in mathematics i.e. outside of Affinity, for the points that define the ends and handle positions of a Bezier curve. A string of these form a Bezier Spline which is what most of the curves in AD are comprised.

I think you are using the term Parametric Control Points for those shapes that are defined procedurally via the Tool panel, like the cog etc. Although they do provide control and could be argued as being named correctly I feel they are confusing the discussion here. The parameters to the shape tools are not only points as they also include values which are not points as you mentioned earlier.

On those points I think we have been in agreement all along.

 

 

[R C-R]

2 minutes ago, Paul Mc said:

I think you are using the term Parametric Control Points for those shapes that are defined procedurally via the Tool panel, like the cog etc.

Actually, I was only referring to them that way because you called them "control points" in your recent posts. Like you just wrote, as I had mentioned earlier not all of them are points in the normal sense of a single specific location on the canvas (for example the radius values or number of teeth) so they are quite different from the control handles or location of nodes in a curve object.

Moreover, changing these parametric controls does not produce comparable results to changing the controls of the nodes of Bezier curves, so I do not think it clarifies anything to equate in any way these entirely different kind of controls.

IOW, they are all controls but they are not all points, so the two terms are not interchangeable terms, in much the same way shapes & curves are not interchangeable terms.