m4ssi has quit [Remote host closed the connection]
<duckinator>
so, i keep encountering a weird issue where i try to make an assembly with 4 components arranged in a rectangle, and i can find absolutely no way to have all four connected. i've tried at least 8 different approaches, always getting "unsolvable constraints" or "redundant constraints", mentioning the last one i add and nothing else. how do i even start attempting to debug this? https://imgur.com/a/2JG5Wri
<dalias>
normally the redundant constraints give you a list of things, any one of which you can remove to resolve
<dalias>
i find lots of time H and V constraints cause this due to becoming redundant with some newly-added symmetry
<duckinator>
the thing is, when it says "redundant constraints"... it has a list of exactly one item. so i can't tell what it's redundant _with_.
<duckinator>
ofc now i can't manage to reproduce that particular problem, and it's always saying unsolvable. >.>
<dalias>
:/
<swivel>
i too have noticed the H/V constraints regularly become redundant as a model progresses
<swivel>
it used to be a major source of frustration for me until I learned ot just start removing them when triggered, solvespace's automatically assigning them on apporximately horiz/vert segments makes it worse imho
<dalias>
yes. iirc i've even had cases where they were redundant as soon as it added them
<dalias>
can't remember how that happened
<wpwrak>
oh, that's easy: have two points that are already H/V with respect to each other. then draw a line between them. it'll be auto-point-coincident with the other points, plus it will have its own H/V, which is redundant with what is already there.
<dalias>
ah yes
<wpwrak>
as a general rule, when the screen gets dark-red and i don't expect it to or it's one of the trivial things (H/V) that happen more or less randomly, i just press ^Z (undo) and try again.
<dalias>
i think if you're careful you can click close enough to the second point that it snaps, but sufficiently far to avoid the automatic H/V :-P
<wpwrak>
it's hard to get out of a problem, but easier to no get into one
<duckinator>
that's how i've been approaching it in general, but for some reason i'm getting into a lot of weird/hard-to-debug situations when doing this assembly
<duckinator>
which is weird because all i've been trying to do so far is arrange four components in a rectangle lmao
<dalias>
speaking of which, solvespace's snap/select on nearby point/line/curve seems to behave weird. is there a guide to how it works somewhere?
<dalias>
(i notice it because i remember finding this problem tricky and solving it really well writing a doom editor in vb in the 90s :)
<wpwrak>
this most often happens when you copy (part of) a structure from a another group. what i do is that i draw the general shape at a distance from the points it should coincide with, and avoiding horizontal/vertical lines, since they'll all be redundant. then i tie the points explicitly with pt-to-pt coincidence
<wpwrak>
i don't find snap/select very good in solvespace. e.g., dragging a radius out of a circle can often be a major pain. what would be nice is a way to iterate through the stack of candidate objects for any position. but this is complicated by having equivalent objects that are not the same. e.g., points in 3D that get projected to the same position in 2D. when you click on it, which is it ? and why should you care, since they're all the
<wpwrak>
same (until something changes, which it often doesn't, but it might) ) ?
<dalias>
:)
<wpwrak>
what's worse are partially overlapping items that are clearly not the same. e.g., a line that's the sum of several partial lines underneath. where "underneath" can mean coincident also in 3D. that's where things truly get messy.
<dalias>
yep
<dalias>
hit all of this
<dalias>
but it's fundamentally hard, not really a failing of solvespace
<swivel>
duckinator: there's not much we can offer in a way of assistance without the .svls
<swivel>
.slvs even
<wpwrak>
in fped, i sort of solved selection by having a click on an object create a list of candidates, and if the currently selected object was in that list, select the one following it. so you can just click until you reach the one you actually want. for some reason, this doesn't always works, but i think it's more a bug than a fundamental limitation of the universe :)
<wpwrak>
what's a real problem in solvespace is that points tend to be attached to objects, so even coincident points, which for all practical purposes are identical, aren't the same to solvespace. you particularly notice when you delete something.
<duckinator>
but i think i figured out why i was getting "redundant constraint" errors with only a single constraint: i just noticed i selected a line that was very close to but different than the line i wanted, and it gave that error. it was redundant with one of the constraints _in the other file_
<wpwrak>
in fped, i solved this by lines and such having no proper geometry at all. they just go to/through/whatever points, and it's the points you place. but then fped doesn't have a constrain-based solver but works by calculating coordinates. which is fine for circuit footprints (since you're in 2D, and you usually "design" things by copying parameters from data sheets), but solvespace has more demanding use cases
<duckinator>
i also just... deleted the file and tried again with the center of the first piece constrained to the center point and it seems to be working? so i think i might've sorted out the issues i was having, even if i'm not entirely sure how lol
<wpwrak>
but i think the concept may have some merits even there. you'd just not have "line L at distance X from point P" but "points (A, B), which are at the ends of line L at distance X from point P".
<wpwrak>
duckinator: that happens quite often ;-) one of the great features of solvespace is that it doesn't take much time to redo something you've already figured out. so very often, just discarding what didn't work and trying again is much faster than "debugging" a broken design.
<wpwrak>
also, solvespace lacks instrumentation for such debugging. e.g., you often can't find all the items involved in some issue in the 3D model and have to resort to going through the list in the text window. and there are, once again, the problems of deletions.
<wpwrak>
also e.g., deleting something that was used as a reference in a later group. best case is that you get a point that's now floating freely in space (you can find this most of the time by asking solvespace to show you the degrees of freedom - sometimes this fails, e.g, if you forget to fix the orientation of an assembly),
<wpwrak>
worst case, it's something used as anchor of a group. then you get a recursive deletion of potentially a lot of things. that's when things really spin out of control.
<wpwrak>
what i think solvespace should do in such cases is to just create a copy of the original anchor point(s) and somehow highlight them. this probably means that they should be members of the group they define, and not of some parent group, and you's just attach them (with the usual constraints) to things in their parents,