Polyline edit functions

QCAD Professional QCAD Script Programming & Contributions
1

Hi,
In which script can I find polyline edit functions in Qcad-master for functions like OC or OR ?
What is the difference between OQ and OF ?
Thx

2

Hi,
OC (polylinefromselection.js) and OR (polylinestart.js) are QCAD Pro features.
See: QCAD - Features
… Both are proprietary code.
Not open source (GitHub - qcad/qcad: QCAD - The Open Source 2D CAD. QCAD is a cross-platform CAD solution for Windows, macOS and Linux. It supports the DXF format and optionally the DWG format (through a proprietary plugin).) and only present as compiled in a QCAD Pro installation.

The differences between OQ and OF are subtle.
OQ (PolylineEquidistant.js) is again proprietary code.
While OF(Offset.js) is preformed by OffsetPro.js under QCAD Pro … And again … Right :wink:

What is it that you want to to see the actual code for of these QCAD Pro methods?

Regards,
CVH

3

is there a way to call some pro functions with scripts I write ? I use pro version and some functions as OC or apply an offset to spline giving a polyline are very useful for me…

4

The Pro scripts are from the proprietary part of QCAD so there’s no publicly available reference guide for them. For this reason, calling the pro functions within your scripts is going to be difficult.

I believe you can use them within your scripts but, since there’s no publicly available reference guide for them, you’re going to have to guess at the class/function names in order to do it.

Awhile back, I remember seeing a thread where someone was asking for permission to call a Pro script within his own script and Andrew said it was okay and recommended another line of code that checked to see if the QCAD was a pro version before trying to call the Pro script. I can’t seem to find that thread though. You could probably find it if you looked through a bunch of the really old threads.

5

Usually there is, but A) These are mostly interactive tools that require user input, indicating entities, cursor positions, options …
B) It is uncertain if these remain the same, they may change or be removed without notice.

Although (A), there is mostly a piece of code that preforms the actually offset and returns shapes. :wink:
OC: PolylineFromSelection and getAffectedObjects
OR: No example but basically: QCAD: RPolylineProxy Class Reference
OF in general:

Here is a complex story about proper offsets: How to get coordinates according to step value - QCAD Script Programming & Contributions - QCAD Forum
Bottom line … It ain’t finished, it might or might not work out.
All fine for basic stuff, for simple geometry, but it might fail when it gets more complex.
With the knowledge on this matter I can construct an arbitrary polyline where OQ would fail.

Especially problematic if the base entity self-intersects or if the resulting offset self-intersects.
The problems with polylines usually start with bulging segments (aka Arc-segments) and how they are joined to form a polyline.
Then, tangentially connected is more prone to errors. Basically a clash of tolerances.
Handling polylines is about always done by deconstructing them to segments (RShape’s) and joining segments back to a RPolyline shape.

General advice: Trim segment entities pair-wise before joining (OC) them to a polyline entity.
For Arcs this would ensure that the polar form matches as good as it gets with the end-point so far.
Arcs don’t have start and end-points, they have ending angles, a bulging segment has two ending points.

Regards,
CVH

6

Simply test on hasPlugin(“PROTOOLS”)
If that fails then it is not QCAD Pro nor Trial.

But you can also check for proxies before using a specific Pro resource, for example: RSpline.hasProxy()
If true then using Spline Pro features will work out.

Regards,
CVH

7

getEndPoint(); getStartPiont(); getEndPoint(); for RShape are available. They work by implementing the main orientation of the polyline?

8

What I mean is that Arcs don’t have ending points as a property/atribute/menber:

Like Lines do:

Meaning that any endpoint of an RLine (or a polyline node for that matter) has a well defined X/Y position in the plane.
While the endpoints of an Arc is a mathematical result, the closest definable X/Y position.
getStartPoint(): qcad/src/core/math/RArc.cpp at master · qcad/qcad · GitHub
getEndPoint(): qcad/src/core/math/RArc.cpp at master · qcad/qcad · GitHub
getPointAtAngle(a): qcad/src/core/math/RArc.cpp at master · qcad/qcad · GitHub

It will be rather precise near the origin, near (0,0;0,0), but decreases in accuracy when further off because of the limited number system.
Polar to Cartesian use trigonometry, RArc to bulge or reverse uses tan()/atan().
The distance between two points is by the hypotenuse what uses sqrt().
Internally rads are used and the accuracy for PI is great but limited.
…
..
.

It matters but that is not the sole or main issue here.
Matching an RLine start point is within 1e-6 in all directions.
Matching an RArc end is within 1e-9 rads and the amount of 1 radius away from the center within +/-1e-9
=> The tolerance for an RArc endpoint grows with the radius.
And to avoid issues I have seen the use of tolerances up to 1e-3 in standard resources.
It might be a fix in most cases but in the end tolerances should be relative to how accurate it can be.

As example:
RPolyline.appendShape() and all that rely on this: qcad/src/core/math/RPolyline.cpp at master · qcad/qcad · GitHub
When joining an RArc to an RPolyline :

  • The RArc start point if verified against the last node.
  • If the match is within 1e-3 then the RArc endpoint is the new ending node.
  • The bulging factor is calculated of the RArc … As is.
    The issue is now that it is uncertain if the distance between the nodes equals the originally chord …
    … but the bulge is calculated from the original sweep and the bulging factor is an exponential value.

It is thus possible to construct a polyline where the intersection of 2 neighboring Arc-segments doesn’t match with the node in between.
And when you then expect the node to be the intersection then … :wink:

Regards,
CVH

9

too hard for me … : e_confused

10

I can understand that.
It is not that hard if you finally discovered it after years of failing offsets.
Spending hours at an end digging through source code.
At some point starting to doubt your knowledge and mathematical skills.

Usually we expect something of a resource by its name that might not entirely be the case.
Some are coded with a specialized intention and an expected behavior.

Another but very simple example:
RCircle.isValid() = true when the center point is valid …
… The radius may be anything … positive, zero, negative or even NaN
If you expect a reliable outcome of a manipulation with a valid RCircle then your are in for the trouble in the last 3 cases.

For an RArc the radius must be more than zero for it to be valid.

At a certain point an even larger tolerance is no longer a fix, one should address the underlying issue.

Regards,
CVH