Sketcher Tool settings : testers welcome!

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
C_h_o_p_i_n
Posts: 191
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: 1253
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: 4470
Joined: Sun May 04, 2014 3:16 pm

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 577 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 577 times
DSH_Line_on_partially_constrained_line_2.gif
DSH_Line_on_partially_constrained_line_2.gif (117.66 KiB) Viewed 577 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 577 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: 157
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: 4470
Joined: Sun May 04, 2014 3:16 pm

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
Posts: 450
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: 4470
Joined: Sun May 04, 2014 3:16 pm

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 315 times
My next objective now is to test this deeply for DSH Line, including the distance-angle construction method.
Haavard
Posts: 91
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
Posts: 450
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
Post Reply