Sketcher Development - Integration of Extensions

[chrisb]

I cannot reproduce the effect either. Hopefully it vanished with the latest update. I will keep an eye on it.

Here is an example in master: I opened the model attached to this post. If I open the Sketch001 I see this:

SnipScreenshot-8f48bc.png (59.27 KiB) Viewed 2141 times

Enlarging repositions the constraint symbols:

SnipScreenshot-2126f2.png (95.9 KiB) Viewed 2141 times

OS: macOS 10.15
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23141 (Git)
Build type: Release
Branch: master
Hash: 0eba78d40096720f7a637a9a73c382a08b820bca
Python version: 3.8.6
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: C/Default (C)

[abdullah]

I see. My guess is that it is related to the grouping of constraints. When zoom is "too much out", constraints tend to get grouped and then the group fit to the screen.

However, this still looks different than the case of Chris_G. There the equality constraints are not being fit on the screen. If one such case can be replicated, it makes sense to investigate. It could be a dangling pointer, which is never good.

[Chris_G]

Sorry for the "not very precise" bug report.
Here is some more information.
I cannot reproduce the offset of the equality constraints of BSpline poles anymore ???
With a fresh build of master, they are located near the pole center, this is now OK.
Only remaining strangeness is an offset happening when I try to drag the radius constraint of a pole.
It is relative to the zoom level of the view.
When I click the radius number of the constraint, to drag it, it jumps by an amount that is roughly the radius of the pole circle.
Here is when I click the constraint :

grab-1.png (6.41 KiB) Viewed 2058 times

And here is what I get as soon as I start to drag the constraint :

grab-2.png (6.81 KiB) Viewed 2058 times

The constraint is moving normally, as expected, but offset.
This is not a big annoyance at all, I report it only for information.

[paullee]

SketchGeometryExtension

Just one simple concept to clarify, without understanding the technicalities of the discussion , is the capability of putting information in the geometry would only be available in Sketch?

Would it be e.g. be available in a DraftWire ? Just think it would be nice to have some functions on these objects (as Arch Object could be built on Sketch as well as Draft Objects like DWire)

Thanks.

[abdullah]

SketchGeometryExtension

Just one simple concept to clarify, without understanding the technicalities of the discussion , is the capability of putting information in the geometry would only be available in Sketch?

Would it be e.g. be available in a DraftWire ? Just think it would be nice to have some functions on these objects (as Arch Object could be built on Sketch as well as Draft Objects like DWire)

Thanks.

Wires are not Part::Geometries, so the short answer is no, Geometry extensions won't be available for DWires.

A different thing is that Draft or Arch, when interfacing with Sketches, set information into the sketch or retrieve information from the sketch. So, for example, if for arch it would make sense to mark some sketcher geometries and later retrieve this information, then a extension could be used. Also when exporting Draft Wires to a Sketch, the export could add information into extensions if necessary.

If an ability for Draft Wires to store information is wanted, then it would need to be implemented separately.

[abdullah]

Sorry for the "not very precise" bug report.

This one is very precise. Thanks!!

Reproduced and PR submitted.

[Chris_G]

I gave a try at PR 4130.
I first thought it didn't work.
I created a bspline, and experienced the same jumping behaviour of the weight constraint as before.
BUT, if I move any pole of the bspline, it fixes the bug, and the weight constraint can be moved without jumping any more.
Further testing reveals that only the last created weight constraint "jumps" when grabbed.
If I create 4 bsplines in the sketch.
It shows 4 weight constraints.
The first 3 weight constraints can be grabbed normally, but the last one jumps.
If I move a pole, of any of the 4 bsplines, it fixes the jumping.

[wmayer]

Regarding splines, I also agree with @Jee-Bee above: I work in programs like Inkscape and Illustrator a lot, and the spline creation in those programs works differently. Instead of showing the knots, you work with control points that actually lie on your line, and set a tangency condition and weight there. It seems like this is the "standard" user interface to creating splines: is the current spline interface a relic of using pre-existing FreeCAD concepts when the splines were first developed? Or is it a deliberate departure?

Actually, B-Splines in OCCT are defined by Poles and knots. I believe this is the general maths way of defining B-Splines, but I am not an expert. I need to investigate what those control points on the curve actually are. But it is not going to be part of this PR.

I wonder if this is what's used behind the scene: https://pomax.github.io/bezierinfo/#catmullconv

See also:
https://en.wikipedia.org/wiki/Cubic_Hermite_spline
https://en.wikipedia.org/wiki/Centripet ... Rom_spline

[kedder]

1. Remove "bool Construction" data member from Part::Geometry:
Code: Select all

class PartExport Geometry: public Base::Persistence
{
...

- protected:
- bool Construction;
};

This might have caused a regression in Arch Wall tool, documented here: https://forum.freecadweb.org/viewtopic. ... 3ce7f0a0e3

[abdullah]

This might have caused a regression in Arch Wall tool, documented here: https://forum.freecadweb.org/viewtopic. ... 3ce7f0a0e3

Yup. Unbelievably there was one CI test for that, but it passed CI in Travis.

It is now fixed:
https://github.com/FreeCAD/FreeCAD/pull/4137