realthunder
Feature request: second class constraints
Frequently I would like to have redundant constraints that can be used when needed, dropped when violated, and indicate when they are violated/not violated but redundant.
- When a feature is under-constrained and the second class constraint will reduce DOF
-
- use the second class constraint, color it green
- When a feature is fully constrained and the second class constraint is violated
-
- color it red
-
- indicate target value and violation for boolean style constraint(horizontal/vertical/tangent/perpendicular) or actual value(distance/angle)
- When a feature is fully constrained and the second class constraint is not violated
-
- color it blue
From my point of view, it sounds too complicated.
For me personally is sufficient to toggle manually the mode of particular constraints:
By terms "rednudant" and "second class" constraints, you propose to: a) create another third type of constraints, in addition to driving (red) and reference (blue) constraints, or b) change behavior of existing reference (blue) constraints?
If the answer is b, I can disagree, because it would change significantly in wrong way the current logic of constraints functionality. Also often the reference blue constraints are set just to measure how a dimesnion changes if another dimension changes. For example if some driving red constraint would be deleted for some reason, then autoconstraining of the sketch this way would not be desired.
If the answer is a, thus adding a new constraint mode, and not changing behavior of existing constraints modes, then user can choose if he will use it or not.
Don't get me wrong if I missed something.
I am with @Rabbit-sk here. Or to be more precise: what do you want to achieve with that? Sketches need not to be over-constrained, and FreeCAD does an excelent job telling the user where something is "wrong", like over or underconstrained.
@Rabbit-sk thanks for the thoughtful reply. I actually didn't know about reference constraints. Being able to add a "target" to reference constraints would get 90% of the feature I'd like. The target/reference constraint would simply provide some color indication if the target isn't met.
I just felt the current constraint system is a bit unwieldy to use when I don't know exactly what my solution will be, but I have some hard requirements for several interlocking parts.