uwestoehr wrote: ↑Sat Oct 02, 2021 11:46 pm
abdullah wrote: ↑Sat Oct 02, 2021 4:27 pm
This is mostly what I said some post ago about the "blocking constraint". To block parts of the geometry in place, while having the solver solve the other geometries. It is somehow the old "Block constraint" behaviour, which I changed last December.
This confuses me. The blocking constraint as it is can only block single edges from being moved. I cannot select my meander structure and apply a blocking constraint to it to disable the solver for it.
Was this possible before last December?
However, the blocking feature as it is is obviously helpful. So I opt for a further "hard blocking constraint" that would block the solver for several parts of a sketch.
New Block constraint
Blocking constraint can be applied to multiple edges at a time. Blocking constraint as it is now, identifies the missing DoF of the selected elements and blocks ONLY those. This cause the generally wanted effect that there is no interference between the constraints applied to an edge and the block constraint. This is the "new" behaviour of block constraint. To achieve this, in summary, it actually needs to solve the whole thing, identify the DoFs, block them and solve again. So it won't solve your problem, as 1) you do not have DoFs and 2) you want less solving, no more solving. This is driven by a rather smart way of building the system of equations and, to my knowledge, works great for what it claims to offer and delivers. This was the original intention behind the "block constraint", to enable to work with B-Splines while constraining "all those extra DoF" without having to manually fix each of them.
Old Block constraint
Blocking constraint as it was before, aka "old block constraint", would ignore any constraint on an element introduced before the block constraint. It will provide the edges with fixed parameters to the solver, meaning in effect that they are not "variables" and they are not "DoF". This behaviour had the rather big drawback that when changing the values of datums before the block constraint, the geometry would not follow the change (because the constraints were ignored). Worst, it will update the number in the datum constraint while not changing the dimensions. This was a continuous source of frustration and forum help requests. Because as Chrisb very rightly says, the "constraint" was being abused. When changing constraints on the blocked elements introduced after the block constraint, it gave rise to "redundant"/"conflicting" constraints. This "detail" of where the constraints were introduced w.r.t. the "block constraint" again caused lots of frustration and help forum requests. However, this implementation did have the advantage that all those "fixed parameters" and ignored constraints did not go to the solver as variables, leading to substantially smaller equation systems. This is, they went to the solver, and this was great because you could attach a non blocked line to an endpoint of a blocked line, but they did not contribute to the rank of the system (the DoFs). In summary, this behaviour was an initial effort (you may call it poor attempt) of fixing the problem of the B-Splines, when the solver was lacking the ability to detect which parameters of which geometry were contributing to the DoF. Once the solver gained this ability (December last year), this implementation was removed in favour of the one described above.
User requests
There were some voices missing the old behaviour (sometimes because the new behaviour had bugs, which as far as I know, are all solved). The ticket was created.
Way forward
I will handle this issue when I take care of that ticket in the tracker. I am trying to organise the time I have before the end of the year. I want to do bug fixing/feature request to keep the tracker manageable. I want to introduce "Geometry Layers". I would like to have "Offset curves" in the sketcher. I would like to help Przemo and Bernd with the CI (if they need my help). Overall, I would not like to see any Sketcher PR delayed (this will take my highest priority), and I would like to contribute review other PRs, at least in PartDesign. Somehow this was where I was sitting before summer. Now, it is unlikely I will have time to tackle all. So I cannot give you a time of when I will tackle this functionality.
For this functionality I need to study in detail the problems indicated in the ticket and how this affects power users in the help forum. I want to have any prospective functionality right and acceptable by all parties. Please, read that ticket. See if you want to add anything to the requirements, or feel free to open another ticket, linking to the forum discussions describing what you want. If you file a new ticket, please associate it to the existing ticket so that I handle both together. When I do, I will reopen the discussion, hopefully with a starting proposal to gather additional feedback or indicating all the problems I see preventing me from generating a proposal (the community is very wise in proposing ways of circumventing problems).
