m4ssi has quit [Remote host closed the connection]
<togo>
dalias: appImage is a new and great way to lower the hurdle to make software easy to evaluate for anybody (on linux)
<whitequark>
i have considered appimage
<whitequark>
unfortunately providing appimage as a primary method of distribution doesn't work very well
<whitequark>
it causes all the same trouble as distribution-specific packages but has none of their benefits
<dalias>
that's my impression of it too
<whitequark>
oh, i'm glad to see i'm not alone
<dalias>
just getting someone to maintain packages for it in popular distros would probably be more beneficial
<whitequark>
in case of solvespace... i have two general options
<dalias>
apt-get install solvespace :)
<whitequark>
i can pack gtk into the appimage
<whitequark>
which means that now i'm responsible for maintaining gtk
<whitequark>
or, i can grab gtk from the system
<whitequark>
which means that i get hit by gtk's ... abi ... incompatibilities
<whitequark>
it's not as disastrous i originally thought, but by the time they deployed a non-disastrous solution, all the distros picked up the wrong abi
<whitequark>
also packing gtk into appimage breaks user themes
<whitequark>
and i can't even easily build appimages on CI, because travis still runs trusty
<whitequark>
so i'd have to do some abomination with docker and whatnot
<dalias>
i just discovered solvespace-cli and now all my stuff is going to have makefiles and automate gcode from .slvs :)
<whitequark>
haha
<whitequark>
don't forget to hierarchically regenerate
<whitequark>
since imported designs use the mesh already present in the slvs file
<dalias>
:)
<dalias>
and i can also rewrite cura's derived parameters that only work from the python gui frontend as makefile rules that do the same
<dalias>
(the config file is full of python expressions where one parameter is derived from another, but the derivations are ignored if you use the cli)
<whitequark>
it'd be very easy to add support for parametric expressions
<whitequark>
like "regenerate with x=10"
<whitequark>
mainly it's some ui work
<whitequark>
but i am confident that you can do it to the necessary standard
<dalias>
might make the most sense to just write a short python program to duplicate what their gui does
<whitequark>
oh, i mean in solvespace
<whitequark>
"give me a gear with this number of teeth"
<dalias>
yeah that'd be nice too
<whitequark>
right, that's what i suggest you implement :P
<dalias>
:-)
<whitequark>
there's a patch that does this without a GUI
<dalias>
or same thing for number of balls in a bearing assembly
<dalias>
i was playing with them a bit more, still not getting the tolerances right tho
<dalias>
(for printing as a single print)
<whitequark>
nod
<dalias>
they avoid falling apart, and spin nicely under no load, but wobble too much..
<dalias>
and on top of that i found out i'm getting about 0.05-0.1mm wall offset from die swell, meaning i should be seeing the opposite. so something really weird is going on
<dalias>
(if i correct for die swell such that a 5mm peg fits in a 5mm hole, all the ball bearings fall out. :-P
<whitequark>
huh
<dalias>
i mean my printer is printing walls such that solids are slightly expanded vs the model. if i try to print a 5mm peg and a 5mm hole, i get something like 5.1-5.2mm and 4.8-4.9mm, respectively
<whitequark>
this seems really bad
<dalias>
other ppl i asked were surprised it's that good :-p
<dalias>
and it seems to be because the extruded filament swells ("die swell") from the 0.4mm nozzle to about 0.48mm
<dalias>
anyway you can correct for this just by offsetting the paths the slicer generates towards the interior of the solid by the same amount
<dalias>
and that gets me peg and hole that fit together perfectly
<dalias>
but with that calibration, my ball bearings that were just loose before fall out :-P
<dalias>
it's probably still the slicer's fault
<dalias>
not solvespace's mesh export
<dalias>
one question i do have tho -- when solvespace uses the term chords, does that mean the approximation of a circle/sphere lies entirely inside it, rather than centered on with error in both directions?
<whitequark>
22:38 < dalias> other ppl i asked were surprised it's that good :-p
<whitequark>
well
<whitequark>
i'm used to machining, where you measure tolerances in thou
<whitequark>
so more like tens of microns
<wpwrak>
when 3D printing, being off my only a few hundred microns is excellent :)
<whitequark>
wpwrak: btw, any new patches from you? i've cleaned out my backlog
<dalias>
whitequark, *nod*, 3d printing is nowhere near that good, at least not with a $200 printer
<whitequark>
i have a weird printer
<whitequark>
some russian guy designed a metal variant of prusa i3
<whitequark>
and sold me one of early prototypes for 1/2 retail price
<whitequark>
it's even powder coated
<dalias>
:)
<swivel>
dalias: is the problem that each of the balls must then be treated as distinct objects when offseting towards their respective interiors?
<wpwrak>
whitequark: alas, i'm quite busy lately. so no time for solvespace hacking for a while. that doesn't stop my mental list of things i'd love to have from growing, though :)
<whitequark>
such as?
<dalias>
swivel, cura does that fine; it's already working with slices that are conceptually cross sections of a solid, so offsetting is just along the normal projected into the plane
<dalias>
or at least it's supposed to do it fine. maybe it has bugs that don't affect cylinders but do affect spheres :-p
<wpwrak>
more constraints. especially point-line-line equidistance would be nice for corners. and there are also differences in the feature set available in 2D vs. 3D. then unified points: if you look at a point, show also the characteristics of equivalent points. easier exploration: when looking at an object, have links to all the points mentioned. and a super-big one: for foo.slvs, default foo.stl to the same directory, same basename.
<wpwrak>
and of course the old classic: don't recursively delete across anchor points of workplanes, but clone the points.
<dalias>
are there any good constraints for preventing the solver from flipping between 2 possible discrete solutions?
<dalias>
best approach i've found is using a length ratio when possible
<swivel>
maybe there's already a way to do this, but i'd appreciate a step+repeat variant which follows an arbitrary path instead of a uniform step
<whitequark>
dalias: hm, which constraint causes the flipping?
<whitequark>
i think all constraints these days should respect sign
<wpwrak>
(corners) would be very useful for enclosures and such, where you have lots and lots of things that following something else, but with a certain offset. of course, an offsetting operation would be cool, too, but that's tricky even with something a simple as a polygon. ah, arc/circle-to-arc/circle distance would also be nice.
<wpwrak>
these are supports for LED rails, for my terrace
<wpwrak>
with the cable going around concrete bars (and the little corner pieces protecting cable and concrete from each other)
<dalias>
whitequark, i mean i don't know the right way to write some consraints
<dalias>
like i'll constrain a circle to be distance X away from a point on something else along its radius
<wpwrak>
sadly, the end caps for the led rails will need a thread. i tried to just hang them freely, but my cables are too stiff and turn and shift the led rail. so i'll need to turn the end caps into threads and then use nuts to fix them in place. that'll be a job for openscad: design the tricky bits in solvespace, then merge this with a thread from openscad. at least that's the theory. haven't done that merge yet.
<dalias>
but it can either be away from that something else, or "inside" that something else by distance X
<dalias>
both are solutions
<dalias>
dragging free stuff doesn't cause it to flip to wrong one unless you go too fasrt
<dalias>
but numerically editing a length constraint elsewhere often does