Spline intersections misbehave below a scale of a few inches

[WraithGlade]

Hello, I'm not sure if this is a bug or not, but it is definitely a serious usability pitfall.

Specifically, today I was trying to set up a QCAD file for working on a small printed card that's only a few inches wide and tall. I need to use splines for it probably, so I was testing that out, but to my great dismay I found that the intersection snapping tool was behaving extremely erratically and seemingly nonsensically and was failing to detect most intersections, which would be a serious impediment to using QCAD for any practical small parts that ever require splines, which is quite a lot of things actually since a few inches is actually quite a practical scale for many uses cases.

I was about to give up and be forced to use some other software for it when luckily I considered the possibility of numeric imprecision and tried scaling up the whole schematic by a factor of 10x and suddenly all the spline intersections for snapping started being detected 100% reliably. Thus, I can now work around the problem by scaling up to do my work and then back down when finished. It seems like some kind of numerical precision threshold for detecting spline intersections is hit whenever a schematic is less than a few inches wide or tall.

It seems like there should be a setting for this though, because what someone is using a CAD system to work on (whether small scale or large scale) is sure to vary quite a lot and a scale of a few inches seems much too large for loss of intersection precision to start happening.

Is there a setting for that already somewhere? If not then I would suggest that there should be one, to account for people working on smaller scales. Not everybody works on architectural or landscape scales. Small schematics have a vast multitude of uses and having them behave extremely erratically due to some threshold being hit is extremely confusing for users. It made me think QCAD's spline implementation must be essentially unusable, when in reality it was just a problem of scale.

I tried in vain searching everywhere in QCAD's user interface and the reference manual for some way to set the numerical precision of schematics of a QCAD file but didn't find any. I only found ways to change dimension labels and rounding displays and such, which are unrelated.

I have attached a simple test demonstration QCAD schematic file (DXF) with a few splines showing some of the cases where the intersection detection behaves erratically for splines at these "small" (few inches) scales. These are not the actual project files I'm working on, but just basic demos for easier testing.

Anyway, thanks for reading and I hope that QCAD's handling of small scale objects is improved. This seems like a very confusing problem that will mislead many people to think that QCAD is less reliable and less usable for splines than it actually is.

So, if you are reading this and you've ever used splines for any small scale QCAD schematic and they behaved poorly and seemed very buggy, then the small scale may be the only real reason why! QCAD's splines are more useful than they seem, as I've suddenly discovered! Try scaling everything up and suddenly the splines will work just as effectively as polylines and other basic objects!

PS: Unrelatedly probably, I also had issues today with hotkeys frequently not responding, even including for escape keys like QQ or basic keys like LI (for lines), which was strange. Sometimes I'd type them in a half dozen times and no response came from the QCAD user interface. I have recently switched to Linux though, so perhaps my Linux Mint Xfce desktop environment or Linux more broadly is causing that problem.

[CVH]

Hi,

Fit-point Splines are a QCAD Pro feature.
Splines methods for Pro users are backed by OpenNURBS libraries.
These will coincidentally be renewed in the upcoming release, see QCAD Changelog >v3.32.2
That may fix some issues with Splines ... Or that may not fix all.

Intersections are simply not found in your tiny example. (Except one self-intersection and then almost correct)
Remark that only the fit-points are returned as snapping points.
Then the snap naming is incorrect ... We would expect that they are called 'Reference' points.
A node of a Polyline is also called an intersection point ...
... True, an intersection between two segments but then also a 'Reference' point with a marker when selected.

I am an engraver and encountered this numerical problem for coin-size designs before.
The Floating Point number system itself has some limitations but it should be well fitted for the purpose.
In short: Up to 15-16 numerical digits correct disregarding the place of the decimal separator and leading/trailing zeros.

What may be unjust are fixed hard-coded tolerances for some decision making up to 0.1
Remind that tolerances and preference values are the same for metric or imperial users.
That would be a tolerance of 0.1mm for me and 0.1 inch for you.
To start with, values in mm are already 25.4 times larger.
-> There is no method to alter internal thresholds.
These are chosen to fit most users or to make it work in most common cases.
-> Preferences can and must be adapted.


Not only with Splines, as these are mostly not supported for CNC we need to fall back on Polylines or even Arcs and Lines.
Typically artistic art and rarely limited to squared out shapes.
CAD is then mostly intended for the latter ... Basically.

My solution after years of struggling at this end of the scale was to convert all to microns instead of trying to do the design in mm.
Coordinate values are then 1000 times larger and hard-coded tolerances remain the same.
Floating point operations are then more stable and behind CAD everything is nothing else than a vast amount of operations.
Every single operation induces some minute amount of uncertainty on the intermediate result.
Uncertainty is like entropy and can only grow.
Thresholds must be included but they should be size adaptive.


The problem is that my CNC only accepts DXF files in mm or inch.
I can fool the drawing unit and my CNC driver soft can scale generated G-code down.


I documented several issues in the past with possible fixes ...
... Only a small part of my propositions were adopted as 'beneficial for the mass'.
... Only critical bugs were fixed and many reports remain open.
At some point you start to code your own resources to circumvent specific problems.
It is like a house of cards, if some cards of the basic layer are crooked then you can't build up high.


Because for CNC we typically need Lines (G0/1) or Arcs (G2/3) a solution might be to convert Splines to Polylines.
First:
I made it a habit NOT to delete things like original Splines and Text, I preserve copies before I alter them.

Then visit Application Preferences .. Modify .. Explode.
- Spline approximation tolerance: 0.01
- Not to Polylines with Line-segments, the result is then tangentially connected Arc(-like) segments.

Sometimes you need to experiment with the approximation tolerance.
- A vast amount of Polyline segments from an explosion is probably a too strict tolerance.
- Only a few is a too coarse approximation.
I made it a bit easier to visit the Explode preferences frequently, see contribution.

In your 2 by 2" example explode the Splines to Polylines.
Intersections are now possible.

Below a certain scale and with much more and smaller details than yours this method won't hold any longer.
At some point Arc resources may start to fail.
A typical answer is 'short Arcs and/or tiny radii are simply not well supported'.

Regards,
CVH

[CVH]

Update:

The v3.32.3.0 release with updated OpenNURBS libraries did not fixed the issue.
Although common distributions are not using Qt6 except macOS on ARM64 (-> p46616)
It is said that snapshots do.

On further reading OpenNURBS does not support intersections per direct among other things.
I then suspect that the problem lies in the RSplineProxy resource.
Probably intersections of Splines of a few drawing units long or less are simply ignored.

Regards,
CVH