QCAD.org Forum

Is there any way to convert from fit point splines to control point splines in QCAD? The code to do some form of this conversion must already exists within QCAD because when you divide a fit point spline it automatically turns the two new splines into control points splines. I don't want to divide though, I just want to convert a closed spline and keep it whole, but I can't find a function anywhere to do that.

The reason I want this is, I find it much more natural and easier to draw fit point splines when I am tracing an external reference, because where you click, the spline passes through that exact location. However a program I use the drawing with later outside of QCAD only understands third degree control point splines, so I need the drawing in that form in order for them to display correctly there. That program is very old and the company that made it is long gone so there is no chance of a change of support there.

In a perfect world I'd love to be able to do the opposite as well, convert from control point splines back to fit point spines, but that's less necessary for me as I don't go back as often from the other program to QCAD and there isn't as big of a difference in ease of use when editing splines as opposed to initially drawing them.

Hi,

Before, I would have answered NO and no, there isn't such a method or tool in the QCAD GUI.
The reverse technique is most probably not straightforward ...
... The question is then: Which and how many fit-points?
The spline goes through an endless amount of points.

Open fit-point splines are 'relaxed' or end normal in the endpoints.
If we divide a fit-point spline in an arbitrary place there is residual stress in that point.
The partial spline does not end normal in that point and it is converted to a control-point spline to keep the end orientation(s).

Your 'other' application would handle such partial splines with no problem. Right?

At the hand of more recent examples I would answer YES.
For creating a tangent arc to an ellipse, the AT method (ArcTPR.js) uses an offset to this ellipse.
An offset to an ellipse is never another ellipse.
This is a fit-point spline through points at an orthogonal offset to the ellipse in numerous places.
(For some idiotic reason every 0.1rads of 2Pi and thus not symmetrical but that doesn't matter here)
Then finding intersections with this shape fail big time and the result is always: No solution

Documented in this forum topic.
As difference between case C.1 and C.2 the test script reports that the fit-point spline also has control-points.
There are none on creation but afterwards there are, already when simply using var dummy = spline.getTMin().
Intersections with such a spline no longer fail and we can solve the AT tool exception for the near perpendicular point on the ellipse.

For the record: The initial problem is not yet fully solved by this.
A) Near perpendicular point is based on getVectorTo(), found to be incorrect or not very accurate.
b) There are up to another 3 far-side perpendicular points. Unsolved for with current resources.
Meanwhile perfectly functional in my copy of ArcTPR.js.


I'll have to test whether this quirk can be used to convert fit-point splines into control-point splines.
Not yet aware if we can address knot-vectors. If that is exposed to the scripting environment.
Also, there is no guarantee for the correctness.
It will not get any better than what we already see when we divide up a fit-point spline.
Probably due to mathematical inaccuracies, shortcuts or whatever.

I can envision to query the FP spline, force an internal update and clear the fit-points.
Then re-casting the spline without fit-points, essentially a CP spline.
Not today anyway.

Regards,
CVH

Update ...
So far functional for open type FP splines converted to CP splines.
Converted closed periodic FP splines are about similar in shape but deform greatly.

It seems to have to do with: 'There are an endless amount of spline shapes that cross all fit-points'.
For defining control-points, spline curve interpolation can then be: “uniform”, “chord”, “centripetal”, ... "global"
On the ezdxf site I then read that a certain routine 'calculates the same control points from fit points as AutoCAD and BricsCAD'.
While the examples given show that there is a fair amount of difference between the methods.

TBC ... Regards,
CVH

Update ...
Made some progress ... Manually ... Now I have to script these approaches and see what happens.

There is a difference if the spline was newly created or came from a saved source.
Both CP and FP types change their definition somewhere in the File Save - Revert/Load process
e.g.:
A closed CP spline with 5 control-points comes back as open with 8 control-points.
A logical and geometrical closed FP spline with 5+1 fit-points comes back as only logical closed with 5 fit-points.

If a FP spline is logical and geometrical closed we can set it logically open without change to the shape.
Already reported that conversion for open FP splines is functional.

But there is a twist ... With 'geometrical' closed I mean that the first fit-point is equal to the last.
And that combined with a closed nature. Correcter: A periodic nature.
Then isClosed(), isGeometricallyClosed() or isPeriodic() all return the 'periodic' = true parameter.

TBC ... Regards,
CVH

Success.
So far with a few arbitrary, simple and QCAD native spline shapes.

Download the attached JS script called 'ConvertFPintoCPsplines.js' and store it away in a familiar place.

The script acts on selected entities in the current drawing.
- Select some entities and initiate the script with: Misc .. Development .. Run Script (XC).
(Or simply use the keyboard shortcut sequence XC)
- Navigate to your script location and select it.
- Acknowledge a warning dialog ifso, there is nothing harmful in the script.

Anything else than fit-points splines is filtered out from the selection.

'As is', the script does NOT run silent and reports various things in the Command History.
For that my Command Line widget is docked at the right and displays more history lines.

'As is', the script does NOT remove the original selected entities.
In experimental phase my advice is to keep the original shapes on a dedicated layer.
-> New entities are cast on the current active layer using the current default attributes.

There are 2 flags at the top of the script : 'silent' and 'doReplace'.
One can edit the script with any plain text editor.

Like for any transaction, the changes applied can be undone, redone.

# EDIT #
<attachment> ConvertFPintoCPsplines.js <attachment>
Experimental script removed. See lower for details.
Downloaded 54 times before removal.
# EDIT #

Please report back: Success, exceptions, script stalling or not ending with reporting 'Script END.', ...
For any exceptions, please include a drawing file with the failing spline.

In time I could streamline the code and convert it to an Addon tool.

Regards,
CVH

Thanks so much for your efforts! I was trying to follow along with your posts but it was mostly going over my head.

I ran the script on a drawing with 174 splines and spot checked them. As far as I could tell it worked perfect. If I run into any issues I'll report back again.

It’s worth noting that this achieves perfection for closed fit point splines by creating open control point splines. If I close the newly created control points splines, slight differences do emerge. The program I'm importing them into treats them as closed and shows those difference as well, regardless of if I have them open or closed in QCAD. However, it appears that as long as I don’t get the vertices too far apart, which is true for almost everything I’m drawing, the difference is negligible for my purposes. So this solution does still work for me.

BrianZ111 wrote: ↑

Sun Feb 23, 2025 9:25 am

Thanks so much for your efforts! I was trying to follow along with your posts but it was mostly going over my head.

It wasn't that big of an effort.
Purely experimental based on several findings:

A) Related to ArcTPR.js
When we create a low level mathematical RSpline shape with Fit-points in a script:
- There are no Control-points to start with.
- After 'forcing an internal update' (OpenNURBS) there are auto generated Control-points besides Fit-points.

B) First update.
We can query an 'open' Fit-points spline from the drawing, take its mathematical shape, clear the Fit-points list and cast that back as entity.
Effectively converting the 'open' FP type to a CP type.
This does not work correctly for 'closed' periodic Fit-points splines.

C) Historical, mentioned in the second update.
Another observation is that 'closed' periodic Control-points splines come back as open after Save - Open/Revert (OpenDesign).
Typically geometrically closed and with more Control-points as originally.
The periodic nature is no longer at a single point but maintained by additional Control-points at start and end.

Also meaning that it serves no practical use to try to define them as 'closed' periodic.

D)
A 'closed' periodic Fit-points spline can be logically or geometrically 'closed'.
After Save - Open/Revert (OpenDesign) closed FP splines always come back as logically 'closed'.
A geometrically 'closed' periodic Fit-points spline does not change its shape when clearing the 'closed' periodic nature.


The fix for 'closed' periodic Fit-points splines was obvious.
When 'closed' without the last point being equal to the first, append a Fit-point equal to the first and clear the 'closed' periodic nature.
Then clear the Fit-points list, effectively converting the 'open' FP type to a CP type.

BrianZ111 wrote: ↑

Mon Feb 24, 2025 2:23 am

It’s worth noting that this achieves perfection for closed fit point splines by creating open control point splines

Indeed, it seems that we can't store these.

BrianZ111 wrote: ↑

Mon Feb 24, 2025 2:23 am

regardless of if I have them open or closed in QCAD.

As stated, I am not aware when (C) occurs: On Save or on Load?
From what you report I now suspect 'on Save' but I have no means to verify that.
Totally out of my hands because QCAD relies on OpenDesign libraries for handling DXF/DWG.

I also gave examples that splines can be rendered very differently depending the algorithm.
Not aware if the 'other' application renders them as what is common for most CAD applications.

Regards,
CVH

Perhaps you don't need the 'fix' at all.
Perhaps you need them as the 'auto generated Control-points besides Fit-points'.
What is reported as 'about similar in shape but deform greatly' for a few points and low/high curvature within QCAD.

Would it be possible to provide an image before and an image after.
For example a DXF file with a FP spline and somehow the export of the other application.
At best not as spline because of the differences in rendering.
Preferable with a low point count, low and high curvature at points.

An image or screenshot would be rudimentary but it should show us the nature of the artifacts
If that is a CNC driver then the exported G-code is also fine (Typically G2/3 moves or arcs)


You could also experiment with not applying the 'fix' required for identical rendering in QCAD.
In the script: Change to: One is never equal to zero and the code of the 'fix' is skipped.
Not replacing originals you will notice that the 'closed' FP type and the CP type don't render the same in QCAD.
In the end they are probably not stored or retrieved back as 'closed' CP splines


Another option is to convert splines to polylines in QCAD with 'Explode' (XP).
See menu Edit .. Application Preferences .. Modify .. Explode for the tolerance used to approximate the spline.

Resulting in a polyline with tangentially connected Arc-segments.
These should not be rendered differently in both applications.
Such a polyline of a duplicate is then kinda the steady state to compare with.

Explode one level further and the result are individual Arcs, still tangentially connected.
That is essentially my approach because my CNC driver does not handle splines and for polylines it is kinda strict.

Regards,
CVH

The question on closed CP splines is asked: Related topic
I would be surprised if there is ever a reply to that.

Experimental script removed.

• Perfectly OK for QCAD native usage.

• It is not feasible to convert periodic closed Fit-Point splines to Control-Point splines that remain closed ... Afterwards

• The result is then interpreted differently by the target application.

The inverse (CP -> FP) seems to be feasible to some extend.
Major hurdle are periodic closed Control-Point splines before saving or after a reload.
I dropped the research.

There must be some interest ... This topic was viewed about 3200 times in less than 10 days.

Sorry, I knew this was a long shot.

Regards,
CVH