[To be reworked] Sketcher Tool settings : testers welcome!

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
C_h_o_p_i_n
Posts: 225
Joined: Fri Apr 26, 2019 3:14 pm

Re: Sketcher Tool settings : testers welcome!

Post by C_h_o_p_i_n »

Regarding the redundant autoconstraint problem.

how about display all possible solution and let the user choose which "group" of constraints to use ?

especially - If I use a widget to "autogenerate" some sketch elements rather than putting them togather step by step i would expect that the constraints constraing the widget-generated elements have a somewhat slightly higher "priority" than other constrains.

like a kinda hirarchy of constraints or grouped constraints.

Just as an Idea.

Regards,
Stefan
User avatar
-alex-
Veteran
Posts: 1853
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Sketcher Tool settings : testers welcome!

Post by -alex- »

Sorry devs, no time ATM to load/compile to test the features of this topic.
Just please remember the less you clic/move the mouse the better the workflow is, considering the carpal tunnel syndrome.
It's important to keep a fast workflow for main features (line, circle, simple rectangle and polyline) with just 1x LMB and related shortcut.
Thanks for the great job.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

C_h_o_p_i_n wrote: Wed Apr 27, 2022 5:49 am Regarding the redundant autoconstraint problem.

how about display all possible solution and let the user choose which "group" of constraints to use ?

especially - If I use a widget to "autogenerate" some sketch elements rather than putting them togather step by step i would expect that the constraints constraing the widget-generated elements have a somewhat slightly higher "priority" than other constrains.

like a kinda hirarchy of constraints or grouped constraints.
I have been giving it quite some thought.

In FC without the widget, we have the autoconstraint mode which can be switched on and off. I think this is part of the priority determination.

With ac off, there is no problem of redundancies and thus all widget limitations are strictly enforced. So this mode is kind of "full priority to widget".

With ac on, without the widget, autoconstraints are always enforced. I do not think that the introduction of the widget should change this behaviour. There is an exception though: autoconstraints sometimes are redundant (among them). This should be solved (and it is within reach, I think).

When introducing the widget there is an additional source of complexity in how to handle widget mandated dimensional constraints together with autoconstraints. This has two "parts": 1) any "attachment" constraint (coincidence with a previous point or point on object with a previous curve) shall not be redundant, 2) any other dimensional constraint applied should not create a conflicting/redundant situation.

I think that when autoconstraints are on, there should not be the need to add widget mandated constraints, other than dimensional constraints. Non-dimensional (geometric constraints) should come from autoconstraints.

In this situation, dimensional constraints should be, at worst, redundant (as opposed to conflicting). Then, prioritising generally means using geometric constraints instead of dimensional constraints. There is a wide understanding, I think, that we should prioritise geometric constraints over dimensional. Then, this means prioritising autoconstraints over widget-mandated constraints.

I have been working on (1), the attachment constraints. I could best illustrate it with a simple example: creating a line starting on the endpoint of another line using only the widget (without clicking). The default behaviour (of the published testing branch) is that the dimensions are created for the initial point of the line (even in cases where the are already dimensions on the endpoint of the previous line). The behaviour I would like to have is:

case 1: The previous line's endpoint is unconstrained
DSH_Line_on_unconstrained_line.gif
DSH_Line_on_unconstrained_line.gif (94.07 KiB) Viewed 2026 times
case 2: The previous line's endpoint is partially constrained
DSH_Line_on_partially_constrained_line_1.gif
DSH_Line_on_partially_constrained_line_1.gif (89.05 KiB) Viewed 2026 times
DSH_Line_on_partially_constrained_line_2.gif
DSH_Line_on_partially_constrained_line_2.gif (117.66 KiB) Viewed 2026 times
case 3: The previous line's endpoint is fully constrained
DSH_Line_on_fully_constrained_line.gif
DSH_Line_on_fully_constrained_line.gif (95.73 KiB) Viewed 2026 times
The widget mandated dimensional constraints that would be redundant, because the geometry is (indirectly) limited to the same situation in a different way, are simply not applied.

The above is a proof of concept demonstrator. I still need to do proper coding. But I think this is the direction we want to go.

Any comment on this?
cadcam
Posts: 273
Joined: Thu Apr 02, 2020 10:39 am

Re: Sketcher Tool settings : testers welcome!

Post by cadcam »

I am not sure if this helps as a solution, but if you want
a point, length, angle line (where the angle is not reference the
horizontal,but the previous line segment) is there a problem
if it the first line is not fully constrained?

BW
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

cadcam wrote: Thu May 05, 2022 9:13 am I am not sure if this helps as a solution, but if you want
a point, length, angle line (where the angle is not reference the
horizontal,but the previous line segment) is there a problem
if it the first line is not fully constrained?

BW
If one wants an angle that is not referenced to the horizontal, the widget cannot be used. Then, there is never a problem (other than the cases know in master where a redundant constraint appears, e.g. a line on the x axis with two PointOnObjects in the extremes and in addition a horizontal constraint).

The widget, when parameters are set to define the coordinates of a point (one enters x and y), it is always fixed with respect to the origin. In the case of the line tool, if polar method is used (length + angle), the angle is also referenced to the horizontal.
User avatar
paddle
Veteran
Posts: 1391
Joined: Mon Feb 03, 2020 4:47 pm

Re: Sketcher Tool settings : testers welcome!

Post by paddle »

abdullah wrote: Thu May 05, 2022 8:42 am The above is a proof of concept demonstrator. I still need to do proper coding. But I think this is the direction we want to go.

Any comment on this?
Sounds good to me. Although it feels to me that this might be an edge case. No?
If user wants to start a line from an existing point and get the coincident constraint, then it's easier to just click on the point than enter the dimensions.

In the case you show it could make sens to make a line by entering the previous line endpoint because it's 10 10 so it's easy to type. But in real cases where points are at random position, clicking makes more sens than using the widget.

So my idea is that if user wants autoconstraint he clicks where he wants it. If he's entering parameters, then he probably don't care about autoconstraint. Unless he enters only 1 parameters (say x coordinate) and clicks on a line because he wants to pointOnObject on it. In which case he wants both.

So my take is that (when AC on):
- If user typed in 2 out of 2 parameters for this step : ignore the step autoconstraint if any.
- If user typed in 1 out of 2 parameters for this step : also add the autoconstraint if it is not redundant/conflicting.
- If user typed no parameters : use aucoconstraint.

But the issue with this approach is that not all steps have 2 parameters. So linking the number of parameters to the correct autoconstraint may be painful.

Having said that I have not given a very deep thought to this so please do not take that too seriously if you see a flaw in my reasoning. I must admit that this problem confuses me slightly so I might be off the mark completely.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

I might be close to what I wanted to do.

I have extended the solver diagnosis capabilities, and the avoidance of redundant constraints while creating geometry has greatly improved.

This is a typical example:
DSH_Line_Challenge.gif
DSH_Line_Challenge.gif (215.35 KiB) Viewed 1764 times
My next objective now is to test this deeply for DSH Line, including the distance-angle construction method.
Haavard
Posts: 217
Joined: Wed Feb 17, 2021 10:48 pm

Re: Sketcher Tool settings : testers welcome!

Post by Haavard »

abdullah wrote: Sat May 14, 2022 6:49 am I have extended the solver diagnosis capabilities, and the avoidance of redundant constraints while creating geometry has greatly improved.
That look really good! :D
User avatar
paddle
Veteran
Posts: 1391
Joined: Mon Feb 03, 2020 4:47 pm

Re: Sketcher Tool settings : testers welcome!

Post by paddle »

Great news ! :)
We're getting closer to merging :D
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

It's been a while.

I have added some PRs to master, which are of functionality independent from the tool widget and the new DSH architecture we have been working on, but that are a precondition and support it.

I do not have the time to review/test/correct all new tools and intended changes of DSH architecture and tool widget effort at a single time. Therefore, I have opted to change the strategy (while keeping up to previous commitments). This way, we might have a continuous flow of improvements, instead of some kind of "big test" and "big merge". It will also be possible get feedback and ideas on snapping while creating geometry, which is one blocking issue for some tools. It will also reduce the number of simultaneous decisions to be taken at a time.

Once some of the tools are approved and merged, the new DSH architecture will be better understood and it might also be possible for me to get some help from you folks to test PRs and help with code review. It will also enable other developers, jnxd directly comes to my mind due to his work on DSH B-Spline, to use the new possibilities (if they match their use cases).

Because I use it a lot, I want to define DSH. DSH stands for DrawSketchHandler. This is the name of the parent class used while creating geometry in the sketcher (also in many cases in constraints and other tools). It is what allows to get the input (mouse and keyboard) in the tools (create rectangle, create circle, ...) and assist the user in doing what he or she intends to do (for example by drawing prototype curves dynamically while adapting to the input, or marking cut points during trimming).

When I refer to new DSH architecture, mostly I refer to a new architecture hanging on the existing one (which is not changed, save for bug fixing a minor refactors), which should be an improvement, at least for the subclass of geometry creation. Part of the new DSH architecture, but not all, relates to paddle widget (though having a widget is not mandatory for a tool), when it is chosen to have a widget, it simplifies (and streamlines) the code base when input does not only come from mouse and keyboard, but is constrained by values(comboboxes/checkboxes entered in the widget.

Summary: The new architecture is not a drastic change of the existing one, but a specialisation useful for certain use cases. Any tool written in the existing architecture continues to work without modification.

While I will have some code availability during July, I hope to have more coding time in August (where I plan for holidays, so hopefully more free time for FreeCad).

Testing

I am going to push the development branch into the testing branch (which allows to create snap builds and have you test functionality and changes). Although this will have tools that should be there and others that may be not, it will enable to test the ones that should be there. Then we collect feedback, make improvements, fix bugs, and if there is a good community acceptance, we code review each of them individually and merge it. Our usual FC development flow.
Post Reply