mumptai has quit [Remote host closed the connection]
ohsix has quit [Ping timeout: 240 seconds]
ohsix has joined #solvespace
<whitequark>
moment
<whitequark>
wpwrak: sort of I think
<whitequark>
actually, let me look closer...
cr1901_modern1 has joined #solvespace
cr1901_modern has quit [Ping timeout: 255 seconds]
<whitequark>
wpwrak: yes. try reducing the diameter to 5.
<wpwrak>
diam 6 (intersecting with the rectangular bumps on the side): 22 nakes edges. diam 5 (just sitting peacefully on the base): self-intersecting and 36 naked edges. interesting degradation :)
<wpwrak>
i guess things like naked edges and such could, either directly or indirectly (e.g., by forcing me to force mesh instead of nurbs) also cause/contribute to the slowness ? if yes, i'll just wait until things improve around #171 before continuing to investigate the slowdown
<whitequark>
they do contribute to slowness by virtue of non-convergence in numeric code
<wpwrak>
that seems to fit the symptoms quite well indeed
<wpwrak>
by the way, is the limitation of the solver to one group/sketch just caused by the desire of avoiding combinatoric explosion (or similar), and could the solver thus also work over a pair of groups ? or is there a deeper limitation at work ?
<whitequark>
it is caused by the desire to keep groups tractable, yes
<whitequark>
the solver won't work for a pair of groups because of how the generation process works internally
<whitequark>
on top of that, it's an UI disaster: making only the 1st group in a pair active would hide the 2nd group, but it would still affect the solver
<whitequark>
why not just keep the geometry in one group?
<wpwrak>
ah yes, the UI thing is a good point. maybe you could optionally suspend the dependencies on 2nd, if you don't want to calculate them in a hidden way.
<wpwrak>
if you do geometry with assemblies, i think you can't keep things in one group, can you ? e.g., items A, B, C, whose placement is related in some way.
<whitequark>
you're going to have to have a really good argument to convince me that this is desirable
<wpwrak>
the argument comes from the workflow perspective: if you start with solvespace, you typically have a simple structure and the solver does things as if by magic.
<wpwrak>
when you "graduate" to more complex designs, the workflow is much more like in "dumb" systems, where you have to pay extreme attention to the order in which you do things and it's hard to fix troublesome dependencies. (made worse by #164, but i guess things like the A B C scenario above are genuinely unsolvable without duplicating geometry)
<whitequark>
regarding the assembly argument: this is usually solved by having a scaffold.
<whitequark>
but a more proper solution would probably be to get rid of 'assembly groups' and instead have as many linked parts as you want in any single group
<wpwrak>
e.g., i guess one could solve it by: 1) importing A, B, C for reference, 2) adding a sketch that copies the relevant relative items (distances and such) from A, B, C, and then constructs the geometry for the real A, B, C, and then 3) import A, B, C again, this time for real, and attach to the sketch from 2)
<whitequark>
yes. but that's awful.
<wpwrak>
(awful) exactly :)
<whitequark>
there's no very strong reason for having a group per assembly, except the internal ID space is somewhat limited, and that was a simpler solution back in the days
<wpwrak>
and yes, making groups more inclusive sounds good
<wpwrak>
i'm doing a little experiment to better understand workplanes and working in 3D ... let's assume i want to make a circle in XY and one in ZX, center at the origin, same diameter (i.e., one is perpendicular to the other). this works fine with eq-radius, but there doesn't seem to be a way to do it with a coincident point, not even if all the items are in 3D.
cr1901_modern1 is now known as cr1901_modern
<whitequark>
wpwrak: are you trying to do something like "constrain a point to a circle for two non-coplanar circles" ?
<wpwrak>
yes
<whitequark>
well, I have bad news for you: "point-on-circle" constraint is really "point-on-cylinder"
<wpwrak>
ahaa !!!
<whitequark>
there had been an extended discussion of this somewhere, let me dig it out...
<wpwrak>
sounds almost like a case for those annoying little pop ups with "did you know that .... [ ] don't show again" :)
<whitequark>
"Since SolveSpace doesn't have point-on-cylindrical-surface constraints, and doesn't automatically generate curves from surfaces when you sketch in planes that cut them, the present behavior seemed most likely to be helpful."
<whitequark>
so essentially... just add two more pt-in-plane constraints