<ohsix>
yep, on f24 and just the greeter is wayland, user sessions are still x
_whitelogger has joined #solvespace
<whitequark>
hm. that's annoying.
<whitequark>
is there anything in the console?
<whitequark>
except Vector::WithMagnitude, translation and generation messages
<wpwrak>
only "Missing (absent) translation for 'Show &Center of Mass" and :"SolveSpace!"
<whitequark>
mhm okay
<wpwrak>
btw, would be nice if one could toggle selection, e.g., when selecting a bunch of items, and getting one wrong, it would be good if one could just click it again to deselect, then proceed
<whitequark>
wpwrak: right-click then Unselect Hovered
<whitequark>
that said there's a PR for deselecting with left click
<whitequark>
wpwrak: random discovery: on valgrind, solvespace works just like on your machine (intermittent updates etc)
<ohsix>
if you file a bug or something post the link or point it out
<wpwrak>
ohsix: where is the bit you find weird in that screenshot ?
<wpwrak>
whitequark: (minor color variations) what i mean is that, given colors C and D and brightness value (from anti-aliasing) a(i) for pixel i, then a "clean" mix would be something like (C + D) / 2 * a(i)
<ohsix>
wpwrak: it is fringy, and before/after has been the measurement along the bottom
<wpwrak>
but here it looks like (C * a(i) + D * b(i)) / 2 with b(i) having a similar distribution as a(i), but not quite the same. thus, the color shifts a little, and also apparent brightness with it. basically looks like noise. but, i probably wouldn't notice if i didn't know to look for it :)
<wpwrak>
(fringy) hmm, the "40.00" looks fine to me in 8OTpwfk
<ohsix>
it looks like it has a purple fringe on top/bottom of main line
<ohsix>
it probably is fine, it is just different/new compared to the build i was using a lot from a few weeks ago
<ohsix>
antialiasing lines like that in a cad situation is p. tough
<ohsix>
basically they'll look like they have too much thickness by the time it is thick enough to look correct at a bunch of different angles
<wpwrak>
yeah, tricky to do this better. it could make lines an integral number of pixels wide, and shift them to the nearest pixel when drawing. but you'd still need AA for diagonals. so there isn't really that much one could improve
<ohsix>
gpus don't really draw lines very much ;]
<wpwrak>
i guess you can always turn them into a little triangle mesh ;-)
<ohsix>
i'll just ignore it until i get a high ppi display
<ohsix>
oh my, nevermind; i forgot shaders exist
<ohsix>
i really need to get a newer copy of the red book
<ohsix>
you can sample the lines however you want
<ohsix>
(ones you draw as triangles, that is)
nathan7 has quit [Ping timeout: 255 seconds]
nathan7 has joined #solvespace
<wpwrak>
btw, is there a deeper reason why one can't use coordinate axes for the parallel constraint (L) ?
<whitequark>
wpwrak: that's how solvespace renders lines
<whitequark>
turns them into a mesh
<whitequark>
you can't render lines in any other way in the programmable pipeline
<GitHub>
solvespace/master bb2cc4a whitequark: GTK: do not compose rendered geometry with an alpha buffer....
<whitequark>
wpwrak: (shift lines to nearest pixel) yes. this is already done for *almost* everything
<whitequark>
text was looking horrible before aligning it to pixel grid too
<whitequark>
now text as well as most lines are hinted
<whitequark>
wpwrak: (coordinate axes parallel constraint) uhm, you can
<wpwrak>
it tells me i can't :(
<whitequark>
what does it say exactly?
<whitequark>
and what are you doing?
<wpwrak>
i'm currently trying to constrain an assembly in 3D. turns out to be pretty hard. i guess i could just forget about the original coordinate system and build everything relative to the assembly, so i can let or float wherever slvs wants it. but that may cause trouble later on, when slicing (for 3d printing), since i'll depend on the slicer to figure out how to turn the resulting piece
<d42>
wpwrak: perhaps same orientation constraint between your assembly and workplane normals? :^)
<wpwrak>
i tried normals, but i either have to under- or over-constrain
<d42>
,_,
<wpwrak>
the placement: new, assemble oled13.slvs, then select a vertical (parallel to Y) line and the Y axis, L, and it gives me the usual lecture on what i can select for this constraint (which doesn't include axes)
<travis-ci>
solvespace/solvespace#336 (master - bb2cc4a : whitequark): The build passed.
<whitequark>
yes. so in general when doing assemblies you want the "same orientation" constraint.
<whitequark>
which removes 3 DOFs at once
<wpwrak>
i've alredy constrained a line on the left side to be normal to X and Z
<whitequark>
the issue with the parallel constraint is that it removes 2 DOFs out of 3 rotational
<whitequark>
so you can't really have more than one without enabling redundant constraints
<wpwrak>
yes, that's what i seem to run into with normals, too. those "accidental" redundancies are something a little confusing.
<whitequark>
they aren't accidental?
<d42>
solvespace tutorial covered that in detail, iirc ,_,
<d42>
but tldr lol
<wpwrak>
i mean using constraints that eliminate 2 DOF to manage something with 3 DOF, and such
<whitequark>
a parallel constraint in an assembly would be useful to constrain a rotating part, I would say
<wpwrak>
there are basically two types of redundances: things resulting from two such multi-DOF constraints conciding on one DOF (or, in general, constraints that are mathematically exactly implied by others), and constraints that just happen to overlap, but that could contradict each other. like having two lengths on a line.
<wpwrak>
the first ones are basically okay from a design point of view, while one wouldn't want to have the others. i guess enabling redundant constraints would just elimitate the warning one gets when producing the latter, no ?
<whitequark>
uhm, no and no
<whitequark>
2nd one is clearly a design error and there's no reason to permit them at all
<whitequark>
(in fact you used to be able to put several H/V constraints on the same thing, which led to weirdness afterwards because the system failed the rank test)
<whitequark>
1st one is *sometimes* a design error, because what you get is a fragile sketch
<whitequark>
for example in 2d you basically never want to enable redundant constraints because what you want can almost certainly be achieved in some other way
<whitequark>
that said, in 3d, sometimes it really is very laborous to avoid redundant constraints, which is why this feature exists
<whitequark>
however, if it's active the solver doesn't converge as well, and moving sketches will at times glitch them
<wpwrak>
(2nd) ah, i see that slvs distinguishes properly between "redundant" and "unsolvable".
<whitequark>
yes.
<wpwrak>
btw, what's really galling is that i can't just make a plane surface normal to a normal. that's what i'd normally think of using normals for.
<whitequark>
wpwrak: you can though
<whitequark>
every plane surface corresponds to either an extrusion or a lathe that has a normal perpendicular to that surface
<wpwrak>
can an assembly have an associated workplane ? i'm trying to construct a point that isn't in the original slvs, and it complains that H/V constraints need a workplane. but the assembly seems to lack that.
<whitequark>
sure. select the workplane then Sketch -> In Workplane
<wpwrak>
(normal) okay, that works (with the X constraint)
<wpwrak>
btw, could X be merged into L ? seems a bit confusing to have two ways to specify the same sort of property.
<whitequark>
no
<whitequark>
they are not the same sort of property? they constrain a different amount of DOFs
<wpwrak>
(select workplane ...) aah, nice. now i understood that bit.
<whitequark>
really that is enough already
<wpwrak>
hmm, there's the chirality, true. i've basically stopped to try fighting chirality
<wpwrak>
ah, "show DOF" sometimes seems to do nothing, even though there is a non-zero number of DOFs. i haven't used "show DOF" much, but perhaps it could be a candidate for a selectable list of items, like we now have for constraints ?
<whitequark>
no, that has nothing to do with chirality, just the number of DOFs...
<whitequark>
these are different constraints for different purposes
<wpwrak>
as far as i can tell, the thing is well enough constrained to not give me trouble. but since it's the fundament of pretty much all the rest of the design, i may want to err on the safe side
<whitequark>
let me see that sketch
<wpwrak>
yes, different purposes, but geometrically, "normals [= (unit) vectors] in the same direction" means "parallel" plus chirality. so it's a bit surprising from an usability point of view if one can't just ask slvs to make two normals parallel.
<whitequark>
where does chirality even come into play here?
<whitequark>
"same orientation" constrains two normals parallel, not one
<whitequark>
that's not what the same orientation constraint does, at all
<whitequark>
so in solvespace normals are really matrices. every normal contains the full rotation in 3-space
<whitequark>
"same orientation" means "same orientation of *parts*"
<whitequark>
"parallel or antiparallel" isn't a degree of freedom as well
<wpwrak>
so it's really "same orientation of plane" (where "plane" is identified by normals, for selection purposes) ?
<whitequark>
what you said is ambiguous
<wpwrak>
heh, how do you call a one bit degree of freedom ? "chirality" seems to fit nicely :)
<whitequark>
"parallel or antiparallel" isn't a degree of freedom internally in solvespace
<whitequark>
th solver is not actually >free< to change it
<whitequark>
(orientation of plane) in geometry, a plane is a surface that could be completely defined by two vectors
<whitequark>
under this definition "same orientation of plane" is the same thin as "parallel"
<whitequark>
in solvespace, the "same orientation" constraint is equivalent to two "parallel" constraints, without the associated overconstraining penalty
<whitequark>
so essentially two parallel constraints that share a DOF
<wpwrak>
so it's as if one could select two planes and make them parallel ?
<whitequark>
yes.
<whitequark>
or select an arbitrary orthonormal basis and then say that the αβγ Euler angles are the same for both parts
<whitequark>
mhm, I've never realized that it's confusingly named
<wpwrak>
(euler) that ought to delight the career mathematicians among your user base ;-)
<whitequark>
but indeed. "same orientation" with regards to vectors doesn't bring this up at all
<whitequark>
huh?
<whitequark>
this was in 9th grade of high school
<wpwrak>
in russia :)
<whitequark>
meh. I find that thinking about this in terms of angles is more intuitive
<whitequark>
someone that's actually *good* at computer graphics would say something in terms of linear algebra
<whitequark>
(as you know the euler angles aren't really usable for continuous transforms because they have a singularity, you have to use quaternions_
<whitequark>
(screw quaternions)
<wpwrak>
yeah, but what's nice about slvs is that you rarely have to worry about what's going on under the hood :)
<whitequark>
oh right, a normal is a quaternion exactly
<whitequark>
http://solvespace.com/ref.pl says: (Technically, a normal represents a rotation matrix from one coordinate system to another. It is represented internally as a unit quaternion.)
<wpwrak>
that's just like "technobabble" in star trek :)
<whitequark>
it's actually pretty easy to understand conceptually
<whitequark>
what's hard is writing code to do the thing
<wpwrak>
i found that to be true about a lot of things involving geometry :)