sklv3 has quit [Remote host closed the connection]
sklv3 has joined #solvespace
f8l has quit [Remote host closed the connection]
f8l has joined #solvespace
f8l has quit [Remote host closed the connection]
f8l has joined #solvespace
thaytan has quit [Ping timeout: 240 seconds]
thaytan has joined #solvespace
<awygle>
hi there. i'm teaching myself about how to use solvespace, and i _must_ be doing something stupid, because i can't get difference extrusion to remove material from the final 3d model.
<awygle>
i think i may be doing things in the wrong order? i drew a sketch (simple square, for testing), extruded it, made a new sketch (smaller square), extruded it, changed it to "difference", but i still have a full cube
<awygle>
if i set the _first_ sketch (big cube) to difference and the _second_ sketch (small cube) to union, then the material from the first sketch is removed from the second. but i can't re-order groups (and i found online that this is Not A Thing). so i'm not sure what i'm supposed to be doing. can anybody help?
<awygle>
oh, this is in 2.3 on Windows, if either of those matter.
<azonenberg>
awygle: is your extrusion going in the wrong direction?
<azonenberg>
if you're subtracting into empty space, it's not going to do anything
<whitequark>
what azonenberg said yeah
<whitequark>
also, you really should use nightlies, they're more stable than 2.3 generally
<whitequark>
and otherwise work better
* azonenberg
needs to try latest nightly and see if the weird opengl issue is gone
<awygle>
No, the volumes definitely overlap. Like I said, if I just swap which is union and which is difference I get _some_ result
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #solvespace
cr1901_modern has quit [Client Quit]
cr1901_modern has joined #solvespace
<whitequark>
can you share the slvs file? I'm not sure if I'm reading your description right
<whitequark>
awygle: ^
<awygle>
Will do, in the morning my time. Thanks for the help.
<whitequark>
you're being bitten by a subtle issue with the order of group operations
<awygle>
Yeah I figured, based on the reversal doing what I expect
<whitequark>
the group *list* ought to be a group *tree* like it is in other CAD packages, but it isn't and changing how it works is incredibly invasive
<whitequark>
the short answer is that you should draw the sketch you're subtracting on top of the extrude group you're subtracting from
<awygle>
And how do I do that?
<whitequark>
you actually have to do more work to *not* do that, which is why I wasn't expecting you to hit this bug
<whitequark>
to do that, always do any operations from the "New Group" menu when the latest group is active (has its radio button ticked)
<awygle>
So this is happening because I went back to "2D mode" before hitting the new sketch button?
<whitequark>
what do you mean by "2D mode"?
<awygle>
(this is clearly a bad mental model)
<awygle>
I went to the original sketch, instead of having the extrustion active
<whitequark>
yeah
<awygle>
Because I wanted to draw my new sketch in the same coordinate system and on the same plane
<whitequark>
oh I see
<whitequark>
so, two things here
<whitequark>
first, SolveSpace does not have "modes" internally, in the sense that all of its constraints always internally work in global 3D coordinates, and any constraints may be placed in any groups regardless of anything else
<awygle>
Sure. It's a UI distinction not a constraints distinction.
<whitequark>
if you use constraints in a workplane (create them with Sketch -> In Workplane active), then they constrain against *projections* of whatever entity you selected, instead of constraining against the entity itself
<whitequark>
but in any group you can have any number of constraints in workplane and in 3d
<awygle>
Oh, so you can change from constraining in 2d to constraining in 3d within the same group? Then why do you have to make a new group to extrude?
<whitequark>
the primary reason SolveSpace has the concept of "groups" in the first place is to keep the system of equations generated from constraints tractable, as constraints in later groups can't affect entities in earlier groups
<whitequark>
the secondary reason is to subdivide your sketch into more manageable pieces with regards to 3d bodies
<whitequark>
the idea is that you build up a solid piece by piece in a linear sequence of operations that stack on each other
<whitequark>
(where, of course, one of those operations is "union/subtract/merge with a subassembly", where the subassembly is treated as an opaque solid without considering its constraints at all)
<awygle>
Right
<whitequark>
so the basic workflow is: sketch in plane -> extrude -> sketch in plane -> difference -> etc
<whitequark>
which is also how your group list should look like
<whitequark>
the ability to insert groups into the middle of the stack is more of an advanced feature that is hard to use correctly
<whitequark>
I added it very early into post-2.0 development before I had a good understanding of the underlying concepts, and it shows
<whitequark>
(it replaced a different behavior that was IMO even harder to use correctly, so, ehh...)
<awygle>
I see. So the basic solution here is "don't hit new sketch unless you're sitting at the bottom of the group list"
<whitequark>
pretty much
<awygle>
Is there an easy way to, from that state, make sure your new sketch's workplane is the XY plane?
<whitequark>
yes. do either of the following: (a) select the XY workplane and hit Sketch In New Workplane, or (b) select the origin point (or any point you want), align your view roughly parallel to the XY plane, and hit Sketch In New Workplane
<awygle>
Okay, cool. Thanks
<whitequark>
in (a) the origin of the new workplane is always the global origin
<whitequark>
in (b) it is any point you want
<whitequark>
in practice (b) is usually the desirable choice
<whitequark>
there was a Sketch on Face feature but we had to cut it because of backward compatibility concerns; one day it'll be reinstated
<awygle>
Oh one last question - when getting my extrusion to go the right direction I realized that it was reporting 0 DOF with only the length constrained, but then I couldn't make the length negative. I ended up dragging the point to the other side _before_ setting the dimension, but is there a more intuitive way to handle that?
<awygle>
I was confused because technically there's an ambiguity but it's not like, a full DOF...
<whitequark>
currently SolveSpace doesn't treat the sign of a length constraint as a degree of freedom, which I consider a bug, as in practice it means that every existing sketch has many different spatial configurations that the solver doesn't randomly switch between only because of the way it's implemented
<whitequark>
you *should* be able to flip the constraint by negating the length, but currently unfortunately cannot, again because of backward compatibility concerns that never went into master
<whitequark>
what you've done as a workaround is correct
<whitequark>
you could also just constrain it and then flip it by dragging the point anyway
<whitequark>
it won't drag, but once you cross far enough to the other side, it'll suddenly flip to that configuration
<awygle>
Interesting, I didn't see that happen but I didn't try that hard.