Repository navigation
Coincident vs distance = 0 #2
Description
I've noticed that in some cases, coincident constraint on points doesn't work whereas setting distance to 0 does... but only before the first regeneration. This looks like a bug.
The case where I most often encounter this is setting difference extrusion depth. This is actually very tricky to do without overconstraining the sketch if you want to make it using constraints and not just drag and leave it wherever.
Activity
whitequark commentedon Apr 25, 2015
Sample file: http://rghost.net/7LXlrP7xn.
jwesthues commentedon Apr 25, 2015
Point-point distance (or length) of zero won't usually do anything good. In general, that constraint removes one DOF, but when the distance is zero it removes three or two (in 3d/2d). The solver currently writes an equation like x^2 + y^2 = 0 in that case, which attempts to constraint multiple degrees of freedom in a single equation, which doesn't work.
That could be modified to write a different set of equations when the distance was below a tolerance, but that's potentially confusing too, as the structure of the sketch changes with what appears to be just a parameter change. The best solution would perhaps be just to warn when the user tries to enter that.
How else are you trying to constrain the extrusion? That depth is 1 DOF, so point-on-point or point-on-line in 3d overconstrains. Point-on-face (or point-on-line projected into 2d) should work, though.
A greater range of constraints would work if the solver permitted redundant but not inconsistent equations--basically, if it were okay for the Jacobian to not have full rank, as long as we could still satisfy all the equations to within some tolerance. That's less geometrically clean, but it may be closer to what people expect.
whitequark commentedon Apr 25, 2015
Ah, I thought it'd be something like this. Warning the user makes sense. The issue is more with complexity of constraining extrusions than the distance = 0, it's just that setting distance to 0 appeared to momentarily work for my case and it actually doesn't.
It's trivial in this case (just constrain it onto a face), but lathe groups don't have faces yet, and there are other cases. For example, I needed to make a hole in a wall of a cylinder that goes through the entire depth of the wall. Constraining that so that the sketch is not overconstrained requires a ridiculous amount of construction.
(As a side note, why does constraining a point in 3D to a circle that is the result of extrusion actually constrains it to the cylinder going through that circle?)
I think allowing overconstrained but consistent sketches would be a good possibility. I'm not sure if this is something that should be enabled by default; especially in 2D, overconstraining is usually a really good indication that something's wrong with your understanding of the geometry you're trying to define. In 3D however and also in 2D if you use symmetry constraints heavily, it's more trouble than it's worth, in my experience.
Perhaps a per-group solver setting that's off by default for 2D and on for 3D?
whitequark commentedon Apr 25, 2015
After reflection, I really like the idea of that setting. I often get to fight the solver when constraining 3D assemblies--especially in the cases where "same orientation" is too restrictive, so I use a parallel constraint on the normal, but then it can rotate around it and often there's nothing handy to constrain the rotation against. And I think there were some other cases I can't immediately recall in detail.
jwesthues commentedon Apr 27, 2015
It seems reasonable. The basic change would be to permit a row of zeros when we orthogonalize the Jacobian in CalculateRank(), as long as the same sequence of row operations applied to the b vector would also result in zero. It shouldn't be too hard to set a tolerance on that, since the equations already all return something roughly like a length. The numerical implications of that downstream (or the correct heuristic for choosing which equations to discard) would be the hard part.
whitequark commentedon Apr 28, 2015
I see. I'm afraid that's out of my depth.
Evil-Spirit commentedon Jul 18, 2015
i have many ideas how to improve sketch solving. for example, it is good idea to drag sketch through something like distance=0 or fix in new mouse position instead of directly parameter changeing. this is more stable, but causes dof problems sometimes. also, for point=point you can firstly add distance=0 constraint, when it solved ok just substitute it with x=x, y=y for more PERFOMANCE.
Evil-Spirit commentedon Jul 18, 2015
Also we have tried pseudo-solutions for linear systems, but profit of it is not yet completely understood.
jwesthues commentedon Jul 18, 2015
There certainly are ways to improve convergence of the solver. I don't see how writing distance=0 (i.e., (xb - xa)^2 + (yb - ya)^2 = 0 instead of xa = xb and ya = yb) helps, though. That's one equation that attempts to fix 2 DOF, and the linearized constraint goes to zero as the constraint is satisfied. If you really have a sketch where that "helps", then I'd guess that something is badly wrong elsewhere.
Evil-Spirit commentedon Jul 19, 2015
Mysterious are the ways of The Solver. So, distance=0 can have better convergene not because of its formula but because it goes into Jacobian matrix. so, at the moment of a constraint creation, we can add equation x=x, y=y to solve using Jacobian, so it converges, after it we can use solve-by-substitution again for x=x, y=y.
Evil-Spirit commentedon Jul 19, 2015
The main idea is to start from parameters which satsfy all the equations except new one, not from many broken contraints how it performed when dragging of points directly change coordintes, or when equations solved by substitution first time after creation.
jwesthues commentedon Jul 19, 2015
Can you post an example that exhibits this behavior? As dx^2 + dy^2 = 0 gets satisfied, dx and dy must both go to zero, which means that the linearized constraint (i.e., the corresponding row in the Jacobian) also goes to zero, and the Jacobian goes singular. So perhaps something unexpected is happening, but it doesn't make sense for that to do anything but hurt.
I also don't see why solving xa = xb in the Jacobian would perform better than consolidating those by forward-substitution. Ignoring rounding error in the linear system solve, they're exactly equivalent. That rounding error is (a) generally insignificant, and (b) if significant, generally bad.
Evil-Spirit commentedon Jul 19, 2015
at the moment all old files are dead, someone broken file format. so i cant recall this. when i get it again, you will be first who will know. but generally i dont speak about dx^2 + dy^2 = 0 but speak about sketch-modifing stratagy - allways start from maximally converged parameters. it means when you need to drag point, you should not to modify cordinates directly & solve sketch after it, you should apply new constraint (like as in "where dragged" constraint) and solve sketch. if you need to apply new constraint, you need to add equation in Jacobian anyway (even if it can be solved by substitution). because if you add it like substitution, it cause sketch constraints not converged at the start point of solving. at the start you must have two different points which was in some contraints & was converged by last solve. in the end you must have two points with the same coordinates, so you can call it the same point and after you can solve it by substitution everywhere. in other worlds, if you perform substitution, this will be one point & you get not converged contraints in the begnning of the next solve. i have some problems to explain it because of poor english skills. sorry
Evil-Spirit commentedon Jul 19, 2015
also, you have "step dimension". all dimensions can be parameters which added to system of equations when you trying to modify it with the corresponding equation. & every label value changeing can be performed like this.
also you can perform satisfing of constraints through solve (actually works for me)
jwesthues commentedon Jul 19, 2015
I think I get what you're saying about substitution vs. Newton-solving. You mean where xa is initially not equal to xb, like when a point-coincident constraint is first applied to two non-coincident constraints? In that case, I agree that the behavior will be different--substitution requires you to pick a single initial value, but the Newton's method will work its way in from both.
When a point with 1 DOF gets dragged, are you writing two equations (and accepting that it won't generally be possible to satisfy both), or a single equation that projects the mouse motion onto a fixed line (with that line calculated, for example, based on the previous solution), or a single nonlinear equation?
"Step dimension" or anything else that breaks a big change into many little changes is definitely helpful. I don't do it automatically because it's slow, but that will pretty much always improve convergence.
11 remaining items
jwesthues commentedon Jul 20, 2015
(a) is pretty intuitive. If you think of all the vectors that make some angle θ with some axis, then if:
(b) takes a bit more thought...
Evil-Spirit commentedon Jul 20, 2015
ok, ive tested. i can assmble box in sketch 3d using parallel, perpendicular and this is hard but solveable
Evil-Spirit commentedon Jul 20, 2015
Evil-Spirit commentedon Jul 20, 2015
atan2(sqrt(sqr((py - py) * (pz - pz) - (pz - pz) * (py - py)) + sqr((pz - pz) * (px - px) - (px - px) * (pz - pz)) + sqr((px - px) * (py - py) - (py - py) * (px - px))), (px - px) * (px - px) + (py - py) * (py - py) + (pz - pz) * (pz - pz)) - 1.5708
Evil-Spirit commentedon Oct 6, 2015
i have made some improvements about atan2 angle (parallel, perpendicular, angle) with signed angle preserving relative position.
also, i ve made some improvements about #2 (comment)
the repo https://github.com/Evil-Spirit/solvespace-1
whitequark commentedon Jan 22, 2016
Setting mentioned in #2 (comment) implemented in whitequark/solvespace@46ab541444bdf4c9a16af3057c043ca4507bc63e.
ruevs commentedon Oct 23, 2020
Note to self - wisdom lies in here :-)
Merge pull request solvespace#2 from pacew/python