<GitHub>
[solvespace] dynamodan commented on issue #144: @Evil-Spirit I tried to make Z (the blue axis) be vertical, but it causes some strange bugs. By default, Y is vertical, I'm sure of it, because of the way the horizontal and vertical constraints are messed up in some work planes when Z is "up". So... Y is up for now. https://github.com/solvespace/solvespace/pull/144#issuecomment-273017552
<GitHub>
[solvespace] whitequark commented on issue #144: @dynamodan Horizontal and vertical constraints have nothing to do with XYZ (i.e. the global coordinate system). They are defined in reference to the workplane they're in. https://github.com/solvespace/solvespace/pull/144#issuecomment-273017700
<wpwrak>
grmbl. what's really frustrating is if you forgot how you anchored something. in the thicket of constraints it's impossible to find out :-(
<whitequark>
mmh, interestingly I don't get that a lot
<wpwrak>
wish there weren't quite so many mistakes that have "roll back really far and try again" as their solution :(
<whitequark>
but sure, your display of constraints for entities and such shouldn't be too hard to do...
<wpwrak>
i've been trying a number of variations of a design, and also experimented with slic3r bugs in parallel. too much distraction, so i forgot how i anchored the critter this time.
<whitequark>
yeah, I totally understand that you may not think the same way as me
<whitequark>
this isn't an excuse for rejection, quite the opposite
<wpwrak>
naming would also be great. that way, you can just tag something as "this-or-that-rect", "clearance", etc., and the next time you try to go through the constraints you won't have to guess what this one may be.
<wpwrak>
especially rects are tricky since they produce a lot of automatic constraints
<whitequark>
mmmmh
<whitequark>
okay
<wpwrak>
the thing i'm trying right now is an enclosure for an oled module with a touch panel. so that's a lot of rects that are somehow related, either by being concentric or with some vertical offset from another rect's center.
<wpwrak>
rects being: touch panel dimensions, plus clearance (for the enclosure wall), outer wall, touch panel active area (which is offset), bezel, spacer "ring" inside the bezel , the oled module, clearance (for the carrier), oled module active area (which is offset), and then how touch and oled are placed with respect to each other
<wpwrak>
plus a few minor ones for cables
<wpwrak>
slvs handles all this admirably, but it gets a little hard on the human element :)
<wpwrak>
ah, another trap: exporting an STL if you're somewhere in the middle of the list. it's also a bit counter-intuitive that you then only get part of your model.
<whitequark>
oh, it's rather not!
<whitequark>
export works as WYSIWYG.
<whitequark>
this is somewhat unusual, but it is very predictable, and I had to work hard to keep it so
<whitequark>
you have stippled stuff on screen? you get that on export, natch
<wpwrak>
oh, i don't say it's not useful. just that you get a surprise when you edit, export, slice. hopefully you notice at this point that something isn't right. else, you'll find out after the next step, printing :)
<wpwrak>
so far, i always caught the partial STLs when arranging pieces in the slicer. but i can imagine that i could overlook some detail change that gets added late in the list.
<whitequark>
ugh, I accidentally committed your oled.slvs
<wpwrak>
heh, now a "back" would be great, when exploring dependencies
<wpwrak>
do i need to turn something on to get the extra highlighting ?
<whitequark>
nope
<wpwrak>
ah, it's just drawing. not the circles evil-spirit suggested.
<GitHub>
[solvespace] wpwrak commented on issue #157: Thanks a lot ! Now, when exploring the dependency graph, I find that a "back" button (like in Web browsers) would be really handy. I guess, next, I'll ask for "Forward", too :) https://github.com/solvespace/solvespace/issues/157#issuecomment-273122984
<cr1901_modern>
I wonder how the hidden surface outline stuff was implemented
<wpwrak>
it certainly looks like the kind of place where lots of experimenting and evolution happens
<cr1901_modern>
Cool, will do
<cr1901_modern>
Has everything been migrated beyond 1.0?
<cr1901_modern>
OpenGL*
<whitequark>
more or less
<whitequark>
GL1 is kept for wine compatibility
dfgg has quit [Ping timeout: 240 seconds]
dfgg has joined #solvespace
<GitHub>
[solvespace] dynamodan commented on issue #144: Here's an example of what I was referring to with the H and V constraints. The sketching is being done in the XY plane, with the Z axis pointing up. The constraints work perfectly well -- the lines stay constrained. But look how the H's are on the vertical lines, and the V's are on the horizontal lines. It's not really "messed up" I guess.... https://github.com/solvespace/solvespace/pull/144#i
<GitHub>
[solvespace] dynamodan commented on issue #144: Here's an example of what I was referring to with the H and V constraints. The sketching is being done in the XY plane, with the Z axis pointing up. The constraints work perfectly well -- the lines stay constrained. But look how the H's are on the vertical lines, and the V's are on the horizontal lines. It's not really "messed up" I guess.... https://github.com/solvespace/solvespace/pull/144#i
<GitHub>
[solvespace] dynamodan commented on issue #144: Here's a screenshot of what I mean by the constraints being messed up. They aren't really -- the constraints still work perfectly to constrain the lines straight. The sketching is being done in the ZX workplane, with Z pointing "up", that is, toward the top of the screen.... https://github.com/solvespace/solvespace/pull/144#issuecomment-273140750
<GitHub>
[solvespace] dynamodan commented on issue #144: Well, not just the H and V lying on their sides, but the H is on the vertical segment, and the V is on the horizontal segment. It really confused me the other day, LOL! Anyway, in the context of turntable mouse navigation, I'm happy. https://github.com/solvespace/solvespace/pull/144#issuecomment-273145048
<GitHub>
[solvespace] whitequark commented on issue #144: @dynamodan Actually, now that I look closer, there's no issue. Try pressing F2 (without any turntable mode enabled). You'll see that horizontal will become what you expect from the constraints. https://github.com/solvespace/solvespace/pull/144#issuecomment-273145759
<GitHub>
[solvespace] Symbian9 commented on issue #50: Maybe it would be usefull make some simple "my-own-theme.cfg" template, that would be stored in config folder, that should define how represent UI (icon set, positions of UI elements in main window, etc).... https://github.com/solvespace/solvespace/issues/50#issuecomment-273166375
<wpwrak>
wonderful. now it works just like i always dreamed it should :) thanks a lot !
<wpwrak>
ah, are there alternative roll models ? (for rotating the model) e.g., it seems that one can control only two angles, which makes some rotations awkward. e.g., in meshlab, one can rotate also along the axis that points at the viewer, by dragging near the upper or lower edge of the screen.
<wpwrak>
maybe s/roll/trackball/
<wpwrak>
right now it's a bit like a rubik's cube: to rotate around that axis, you first have to rotate it on another, then prependicularly, and then back.