### SOLVED Skewing and the way to it.

Posted:

**Tue May 01, 2018 9:06 pm**Hi all,

I was adding a feature request for non symmetrical scaling with reference and target point.

In some cases it was enoying that the 'reference' do not end up at the 'target'.

But that failed. Error: 'wrongtoken'.

A good thing because more insights came later.

Documenting this I found out that polylines with arcs don't scale properly.

A non symmetrical scaled arc is an ellipse. I enterred a bug report.

Andrew dismissed this because polylines don't support ellipses.

so I ran into the limmits of dxf/dwg.

As a fact I fought this one before.

Ever tried to design an oval rim to use with G-code? There is only one good way.

A central oval, two offsets that are splines, exploding to polys with tangentially conneted arcs, exploding to arcs.

None of the final paths are ellipses but they look like one, are concentric and have a fixed distance.

But is there no beter way to scale polylines with arcs? I asked myself.

And there are much better ways than keeping the bulge factor constant.

Pitty for all those polys I scaled before.

file included <Scaling Poly-arcs.dxf> (zoom in on the details)

I started with a spline with fitpoints as base for a fluent polyline with arcs.

This spline (yellow) has no line segments so I divided it in 3 parts and inserted 2 line segments (blue). (upper leftmost in the file)

Splitting the spline changed it into a splines with control points. (Expected behavior by Andrew)

From that I copied it to a polyline (orange) and as a string of arc segments (magenta).

The fitting of these three is quite good. Obvious the two latter fit perfectly.

(I have to mention that exploding the spline fails the demanded approximation tolerance set at 0.1 whatever)

This can not be said for the non symmetrical scaled versions at the right.

As I use the segment string as reference because here the arcs are properly scaled to ellipses (also magenta).

The scaled spline is by about the same amount off as the non scaled.

The scaled polyline is much more off and has bulging and kinks.

I also scaled the sagitta (cyan) and found that a three point arc (cyan) fit does the trick far better.

Using start and end point and the end point of the scaled sagitta.

A last enhancement would be scaling the tangent (dark cyan) and again use a three point arc (dark green).

Using the intersection of the scaled tangent and a line perpendicular to the midpoint between start and end point.

(also the new sagitta for the arc with equal bulge)

These two methods can be translated to a mathemathically relation to define a new bulge for the arc in question.

Although a pretty computal effort, I rather wait a few seconds than continue with bulging an kinky polys.

I chose the rounded corner for the error-math because I asume it is one of the worst cases in this example.

Rigoureus testing can only be done with a test function because the graphical work involved is very time consuming.

The numbers are the integrated surfaces of the deviations.

The tangent method is far out the best. The present method far out the worst.

When an arc sits between two non colinear line segments it can also be treated as a rounding.

in this case one could scale the rounding or use the tangent for a rounding and trim the lines to it.

For the first the error is larger as the best match but can be even smaller then the present method for scaling polys.

The same would be possible for arcs that connect at one line segment. I did not investigate it.

At the far right the different sagittas for the three arcs in detail are blown up to see the inpact of the constant bulging.

With X ratio over Y ratio of 0.5/1 the error can easely be twice that what would be expected and much more.

My conclusions are:

Splines are not replaced by Polys within the approximation tolerance.

Non symmetrical scaling is best not done for Polys with arcs or Splines.

Non symmetrical scaling of Polys with arcs with keeping the bulge for arcs is faulty.

Altough never perfect, the tangent method is a far better approximation for scaling fluent Polys with arcs.

The only exact way is to explode them into a string of segments an work with blocks.

This has a huge impact on using functions or modifcations on them.

So the way to 'reference' skewing is far more complicated as expected.

And I have other feature requests pending.

Like flawless offsetting a buch of curved lines.

Like simplifying curved lines.

Like median line between two curved lines.

I grew to be fond of the QCAD way and the UI and renew my contribution every year.

In fact, I am awaiting the CAM part to exits its puberty.

Regards,

CVH

I was adding a feature request for non symmetrical scaling with reference and target point.

In some cases it was enoying that the 'reference' do not end up at the 'target'.

But that failed. Error: 'wrongtoken'.

A good thing because more insights came later.

Documenting this I found out that polylines with arcs don't scale properly.

A non symmetrical scaled arc is an ellipse. I enterred a bug report.

Andrew dismissed this because polylines don't support ellipses.

so I ran into the limmits of dxf/dwg.

As a fact I fought this one before.

Ever tried to design an oval rim to use with G-code? There is only one good way.

A central oval, two offsets that are splines, exploding to polys with tangentially conneted arcs, exploding to arcs.

None of the final paths are ellipses but they look like one, are concentric and have a fixed distance.

But is there no beter way to scale polylines with arcs? I asked myself.

And there are much better ways than keeping the bulge factor constant.

Pitty for all those polys I scaled before.

file included <Scaling Poly-arcs.dxf> (zoom in on the details)

I started with a spline with fitpoints as base for a fluent polyline with arcs.

This spline (yellow) has no line segments so I divided it in 3 parts and inserted 2 line segments (blue). (upper leftmost in the file)

Splitting the spline changed it into a splines with control points. (Expected behavior by Andrew)

From that I copied it to a polyline (orange) and as a string of arc segments (magenta).

The fitting of these three is quite good. Obvious the two latter fit perfectly.

(I have to mention that exploding the spline fails the demanded approximation tolerance set at 0.1 whatever)

This can not be said for the non symmetrical scaled versions at the right.

As I use the segment string as reference because here the arcs are properly scaled to ellipses (also magenta).

The scaled spline is by about the same amount off as the non scaled.

The scaled polyline is much more off and has bulging and kinks.

I also scaled the sagitta (cyan) and found that a three point arc (cyan) fit does the trick far better.

Using start and end point and the end point of the scaled sagitta.

A last enhancement would be scaling the tangent (dark cyan) and again use a three point arc (dark green).

Using the intersection of the scaled tangent and a line perpendicular to the midpoint between start and end point.

(also the new sagitta for the arc with equal bulge)

These two methods can be translated to a mathemathically relation to define a new bulge for the arc in question.

Although a pretty computal effort, I rather wait a few seconds than continue with bulging an kinky polys.

I chose the rounded corner for the error-math because I asume it is one of the worst cases in this example.

Rigoureus testing can only be done with a test function because the graphical work involved is very time consuming.

The numbers are the integrated surfaces of the deviations.

The tangent method is far out the best. The present method far out the worst.

When an arc sits between two non colinear line segments it can also be treated as a rounding.

in this case one could scale the rounding or use the tangent for a rounding and trim the lines to it.

For the first the error is larger as the best match but can be even smaller then the present method for scaling polys.

The same would be possible for arcs that connect at one line segment. I did not investigate it.

At the far right the different sagittas for the three arcs in detail are blown up to see the inpact of the constant bulging.

With X ratio over Y ratio of 0.5/1 the error can easely be twice that what would be expected and much more.

My conclusions are:

Splines are not replaced by Polys within the approximation tolerance.

Non symmetrical scaling is best not done for Polys with arcs or Splines.

Non symmetrical scaling of Polys with arcs with keeping the bulge for arcs is faulty.

Altough never perfect, the tangent method is a far better approximation for scaling fluent Polys with arcs.

The only exact way is to explode them into a string of segments an work with blocks.

This has a huge impact on using functions or modifcations on them.

So the way to 'reference' skewing is far more complicated as expected.

And I have other feature requests pending.

Like flawless offsetting a buch of curved lines.

Like simplifying curved lines.

Like median line between two curved lines.

I grew to be fond of the QCAD way and the UI and renew my contribution every year.

In fact, I am awaiting the CAM part to exits its puberty.

Regards,

CVH