Sketcher Tool settings : testers welcome!

[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

[-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]

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 (94.07 KiB) Viewed 458 times

case 2: The previous line's endpoint is partially constrained

DSH_Line_on_partially_constrained_line_1.gif (89.05 KiB) Viewed 458 times

DSH_Line_on_partially_constrained_line_2.gif (117.66 KiB) Viewed 458 times

case 3: The previous line's endpoint is fully constrained

DSH_Line_on_fully_constrained_line.gif (95.73 KiB) Viewed 458 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]

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]

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.

[paddle]

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]

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 (215.35 KiB) Viewed 196 times

My next objective now is to test this deeply for DSH Line, including the distance-angle construction method.

[Haavard]

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

That look really good!

[paddle]

Great news !
We're getting closer to merging