Page 1 of 1

Uneven scaling of Polys

Posted: Fri Sep 06, 2019 4:17 pm
by CVH

Continuing from:

And as I don't want to interfere on standard scripts.

In Scale.js
Arround lines:

Code: Select all

403     // non-uniform scaling of other entities: 
404     entity.scale(sv, this.focusPoint); 
405     op.addObject(entity, flags); 
We could introduce the program flow as in the include flow dxf.
The math for md, P3, Sagitta'' and Bulge'' with the scaled tangent is in the screengrab.
There are some signs to adapt. Lost in sqauring and square routing.

It is also possible to do this graphically:
The new arc is the arc through the scaled endpoints and tangent at the scaled tangent.
Notice that the new apex point on the scaled tangent is not the same as the scaled apex point.
Visualized in the file New Sagitta.dxf.

I leave it up to you to provide me with an adapted script for scale.js.
You only have to enclose a function call at the correct place and the empty function.
From what I understand that can be between 404 and 405.
but I don't have the complete picture.
In scope should be the Poly and the scaling factors.

The option to do this can later be included in AppPrefs.
For now I only want to it put through a firm testing phase.

Kind regards,

Re: Uneven scaling of Polys

Posted: Sat Sep 07, 2019 6:18 pm
by CVH
Getting the hang of it:
Included are:
Adapted Scale.js
> Changes are marked with 'CVH'
Adapted ScaleDialog.ui
> For now without change to AppPreffs for testing
> Only works from the dialog

NOT YET fully tested on all kinds of Polys: So BE AWARE.
Edit: Further testing finished.

I made myself a sidenote about:
Arcs with a sweep larger as +/-50° (=bunch of math) should better be cut in two parts.
Did a lot of trials on that manually with indeed even better results.
If we cut arcs up, I first want to evaluate BiArcs and keeping tangency.

Besides that, for flowing Polys with arcs it is allready a better looking alternative.
Exploding a spline is a good startpoint for testing that.
Or cut a circle up in some random pieces and join as a Poly.
2 copies reveal even more differences.


- = - = - = - = - = -
Erratum: vertical chords faulty.
In test scale.js line 467 should read:

Code: Select all

poly.setBulgeAt(vertId , bulge * a / b);
- = - = - = - = - = -

Re: Uneven scaling of Polys

Posted: Sun Sep 08, 2019 5:09 am
by CVH
Here are my first quick tests:
Scaled Cyan underlay are the scaled arc segments as ellips arcs.
> What is the only correct way but ellips arcs can not be part of a polyline.
Scaled Dark red is the standard method that keeps the bulges unchanged.
Scaled Green is the mathematical scaled tangent method.
(off course green :wink:)

The math is fully reversible, re-scaling with the invers factors will result in the original arc apart of some arithmetic accuracy.
My option in the dialog is now coded persitent on.
I'll keep it

Pity to remark I have an annoying experience conserning my wiping endeavor:


Re: Uneven scaling of Polys

Posted: Mon Sep 09, 2019 9:13 am
by CVH
I think I am done testing.
Disregarded null-lenght Poly and NULL-Poly.
These should not be attemted to scaled.
Merely trying to select a NULL-poly (= @origin) will lead to an AppCrash.

The math is also not applicable on null-lenght segments that have a value for bulge.
>> this will result in Div0 anyhow.
These bulges are left as they are.

Further, everything turns out correctly. See new version of dxf.
And yes, I now see my math in the screengrab is a bit disambiguous.
luckily it was code correctly in Excel.
Copy, paste, replaced cells refs by vars, correct at first run.

Although, imho the scaling by mouse is faulty in general.
See also may '18, firts paragraph, firts post:
It later was declared as intended behaviour.
(can't search specific enough to retreive that)
In any case it will be hard for the user to pick two points in the ether to
provide an intented scaling factor as the result is:
scale = sqrt(dx1^2+dy1^2)/sqrt(dx2^2+dy2^2)
This is math humans are not good at. See new version of dxf.

And finally:
In test scale.js lines 472-475 may be reinstated with again a similar swap of var a and var b.
The math under 'slanted chords' will reduce to that for horizontal chords but it's ways shorter.

Code: Select all

 *** the lines as corrected *** 
467   poly.setBulgeAt(vertId , bulge * a / b);
473   poly.setBulgeAt(vertId , bulge * b / a);
Both are my bads. :oops: