I guess this is a transitional thing. Clearly, the harder way development-wise is to apply the logic behind all constraint situations to safely avoid solver locks and errors. Once achived, it offers benefits and many chances for new features to the user, e.g. your very nice example with the already implemented dynamic modification. The other way to 'force' the user to fully understand what is going on under the hood makes it harder on the user to get going and maybe is less flexible. But its easier on the developer to reach a stable and fast solver functionality with less testing, even for more exotic use cases.realthunder wrote: ↑Fri Feb 28, 2020 1:30 amI haven't really tested, but by now, I think an element will always have a valid interpretation in any constraints. One thing you may not know, and I think many other CAD don't support, is that you can dynamically change the type of an existing constraint, using its 'ConstraintType' property. And in many case, you don't need to change its constraining elements because of this dynamic nature in element interpretation. Asking user to make more restrictive selection defeats its purpose.
It's more of matter of documentation. I should mention those auto relaxing logic in the document. If the user really cares about DOF and stuff, he'll read the document. If not, well, he definitely needs help from auto relaxing. Another fact is that, I did optimization only on those composite constraints that I created. The underlying SolveSpace solver only supports basic constraints, which are all exposed by asm3. So the user is free choose the hard way.
Not a big surprise though, that you are aiming for the more high end solution
I can confirm that it has become my favourit constraint by now. Despite the cumbersome angular corrections. By the way, I find that I am ending up mofiying both constraint element's "Angle" properties most of the time, because its quite impossible without Euler/Quaternion based rotations to correct normal axis flipping and plane orientations at the same time. So its very convenient to have two separate angular correction variables for a single constraint. I did not expect that I will need that.realthunder wrote: ↑Fri Feb 28, 2020 1:30 amYes, it is about the same. In fact, it is added as a result of discussion in one of his thread, before he made asm4.I have tested the "Attachment" constraint for attaching parts that are attached with multiple screws in real life. The most important info was that Attachment constraint saves on solver time, which I was not aware of. Maybe I am wrong, but this seems to be the counterpart of Zolkos Assembly4 LCS, just presented as constraint?
I think one use case would be "your part is flipped in the normal direction (i.e. 180° about X) and off alignment for 135° about Z". The axial mover is a great tool and it alreday has a keyboard short cut (a,m). I have not used it yet for precision control, like lock it to 15/45/90 deg steps, or make precision 1° steps. At least its not easy enough to find out how that is done with try and error. But I will have a look to your documentation, probaly it already can do that.
A totally different apporach could be to introduce a manual override constraints mode. Its could be applied on a selected existing tree constraint and allow to select an additional constraint as usual. Just the constraint is only applied to the selected constraint by an over-constraint reduction algorithm. It is not selected in the tree, but the selected constraint is modified. For example, after the "attachment" operation I would select the attachment constraint and select the manual override constraint mode. then I select two faces and press "align". The part would then find a solution to satisfy both constraints and modify the initially selected constraint (here "attachment"), so the part remains in that position. By confirming the mode the affected constraints are changed, by escaping the mode the part flips back.
Since by definition there are only two constraints involved, it should be much easier to apply an intelligent over-constraint solution logic, even create a solution table for each combination. For "Attachment", obviously the rotation axes of either element could be modified by another constraint.
Maybe just an intermediate step to a fully automatic DOF reducer (which would allow to keep both constraints in the tree), but there could be even benefits for the user explicitly reduce the number of constraints, e.g. for a more slim and simple tree, etc. On the other hand a modal feature is always a dangerous thing in GUI design, because it must be clear that you are in there and how to get out of it at any time - maybe thats not worth the benefits.