<tjader>
I'm forcing triangle because I get errors in an earlier difference if I don't
<tjader>
From reading around github it seems NURBS booleans are very buggy, so there's probably no way around that, right?
<whitequark>
I wouldn't describe them as "very buggy"
<whitequark>
there are a few known issues and they make a few kinds of operations nearly impossible to use
<whitequark>
but if you avoid those they work fine
<whitequark>
anyway, what font is that? comic sans?
<tjader>
Yes
<whitequark>
that kind of looks like a font issue, like perhaps it has very small edges or something
<whitequark>
what if you play with chord tolerance?
<tjader>
I wouldn't say the operation that is giving the NURBS error is unusual at all
<tjader>
I'm just subtracting a cuboid to get that slant on the outer rim
<tjader>
Raise chord tolerance you mean? I'll try that
<tjader>
I've raised it up to 1 mm, still getting errors
<whitequark>
wait, didn't you just say you forced an earlier group to triangle mesh?
<whitequark>
oh
<whitequark>
sorry I misread
<tjader>
I did
<whitequark>
so the thing about NURBS booleans is that certain kinds of intersections break them
<whitequark>
for example, slicing exactly one quarter of a sphere does that
<tjader>
Only spheres? I'm slicing quarter circles
<tjader>
The rounded edges are quarter circles
<whitequark>
anything circular, the sphere is just an example
<whitequark>
I'm not entirely sure how the math works out, but the problem generally arises when a surface is sliced exactly along its control points
<tjader>
I'm slicing through some control points indeed
<whitequark>
offsetting one of the surfaces even a bit makes the booleans work
<whitequark>
it's kludgy
<tjader>
I'd have to move the workplane of the cuboid for that
<whitequark>
ah.
<tjader>
I defined the workplane using the controlpoints on the ends of the shape, then drew a rectangle and extruded it one-sided
<tjader>
I'd have to construct points an epsilon above those control points and make a new workplane, but can I do that without messing up everything that comes after?
<tjader>
Anyway, would being able to use NURBS booleans help with the text problem?
<whitequark>
unlikely. try doing it in a new sketch
<whitequark>
this was more of a tangent
<whitequark>
the issue you're experiencing with text looks like a bug
<tjader>
Actually, I think I only would have to redo that cuboud and the cylindrical cutout
<tjader>
I don't think anything else depends on that slanted workplane
<tjader>
I'll try that later
<tjader>
I just made a simple drawing here, I'm getting the text errors when forcing triangles, but it works fine with nurbs
<whitequark>
interesting
<tjader>
I am also getting a redundant constraint warning in a situation where I don't see how anything is redundant
<tjader>
If I remove any of the constraints it complains about I get 1 DOF
<tjader>
Weird, if I keep the constraints and allow redundant constraints I still get 1 DOF
<whitequark>
allowing redundant constraints only suppresses the warning
<tjader>
But Show Underconstrained Points doesn't seem to highlight anything
<whitequark>
hm I can't reproduce with DejaVu Sans Oblique
<whitequark>
what version?
<whitequark>
of SolveSpace that is
<tjader>
The one you linked yesterday, 3.0~7baf5858
<whitequark>
sorry, I *can* reproduce it with either Cambria or DejaVu Sans
<whitequark>
yeah that seems like a clear bug
<whitequark>
please file an issue with the testcase attached
<tjader>
Sure, will do that later
<whitequark>
I can't seem to reproduce the constraint issue at all though
<tjader>
Does it show 1 dof on g004 for you?
<whitequark>
nope, says "ok"
<tjader>
weird, I have 1 dof
<tjader>
Maybe it is fixed in master
<whitequark>
very strange issue
<tjader>
If I stop allowing redundant constraints it complains the two symmetry constraints are redundant
<tjader>
I don't see how they are
<whitequark>
ahh
<whitequark>
I can explain what happens here
<whitequark>
a symmetry constraint removes two DOF
<whitequark>
it's basically a relative horizontal/vertical constraint (x1=x2 or y1=y2 depending on orientation) plus an equal distance constraint relative to the symmetry plane
<whitequark>
what you're looking for is one symmetry constraint and one midpoint constraint
<whitequark>
the bug here is the dof amount shown with "allow redundant constraints" checked
<whitequark>
well, i'm not sure if i consider that a bug; i'm not sure if we should show the dof count with that checkbox turned on at all
<whitequark>
since it kinda breaks the dof calculation
<whitequark>
but anyway, that's the reason for the behavior you're seeing
<tjader>
You mean I should create a vertical midpoint and force it to be on x=0 instead of using a vertical symmetry?
<whitequark>
yes, to avoid constraining the points to be horizontal
<tjader>
What I want to achieve is to force the text to be horizontal and centered
<whitequark>
since they are already constrained horizontal by virtue of (a) your first symmetry constraint and (b) the fact that the text associated points are always at right angle
<tjader>
Using two symmetry accomplishes that with 2 commands
<whitequark>
sure, but that's not what the symmetry constraint is for
<tjader>
Creating a midpoint will mean creating a construction segment, a point, midpoint constraint, and x=0 constraint
<tjader>
Much more fiddly
* whitequark
shrugs
<whitequark>
all tools are limited
<whitequark>
the nature of parametric modeling in solvespace means that you're going to have to fit your problem to the tools at hand, to some extent
<tjader>
I think I'll keep using two symmetries and allowing redundant constraints
<tjader>
Yeah, I'm not really complaining
<whitequark>
that's probably a bad idea in general
<whitequark>
the checkbox to allow redundant constraints is there as an escape hatch
<whitequark>
but it makes the solver work somewhat worse
<tjader>
One thing that I wish I could do is to apply an equal length constraint to distance constraints
<whitequark>
so unless you have absolutely no other way to do what you want, don't use it
<tjader>
Okay
<whitequark>
let me see if there's a more elegant way
<tjader>
I usually replicate what I just said by creating two construction segments and constraining them to be equal
<whitequark>
yep
<tjader>
But when I'm constrarining the distance of a point to a line then I also have to constrain the construction segment to be perpendicular to the line
<whitequark>
the way constraints are currently created somewhat limits the vocabulary because you have to disambiguate the options through the combination of menus and selection
<whitequark>
there are some long-term plans to improve on that, but nothing that will be done soon
<tjader>
It would be nice if the midpoint constraint worked on three points as well as a point and a line segment
<whitequark>
that wouldn't work UI-wise
<whitequark>
well
<whitequark>
the only way to make that work is selection order dependent, which sucks
<tjader>
It would be similar to the equal angles for example
<whitequark>
and is also currently just not implementable
<tjader>
Yeah, it sucks, but it already has parallels
<whitequark>
oh
<whitequark>
oh, it is
<whitequark>
I misremembered how it works
<whitequark>
ok, so it just sucks then, let's not make a bad situation worse
<whitequark>
any new constraint we add has to be supported forever. the bar for adding a new constraint or entity is (and should be) high
<tjader>
Yeah, I'm just throwing ideas here
<tjader>
I've been using the program for two days now, my opinion shouldn't really carry much weight :p
<whitequark>
makes sense
<whitequark>
pain points encountered by new users are valuable, but not all of them are directly actionable
<whitequark>
on top of that solvespace has a lot of legacy and is somewhat limited in options
<tjader>
I'm throwing ideas in the hope that either you tell me there's a simpler way to do what I'm trying to do or it's simple to implement and just hasn't been thought of
<whitequark>
the three-dot midpoint constraint isn't such a bad idea
<whitequark>
if more people ask for it i'll see if maybe the ordering nastiness is justified
<whitequark>
i've certainly had the desire for it myself a few times
<tjader>
It would be an application of Occam's razor
<tjader>
But there's two way to not multiply entities unnecessarirly here
<tjader>
Which is more unnecessary? To add an unnecessary line segment to a sketch or to add one more constraint? :p
<whitequark>
I'd say that's not the question
<whitequark>
a minor annoyance in a corner case isn't very important, on its own at least
<whitequark>
it becomes important if it becomes common, or if using the workaround is error-prone
<tjader>
I've changed the text test file to use the midpoint constraint instead of vertical symmetry. I'll post the issue later today
<tjader>
Lunch time now
<_whitenotifier-f>
[solvespace] phkahler commented on issue #631: Windows artifact complains about vcomp140d.dll - https://git.io/Jf7M0
<_whitenotifier-f>
[solvespace] whitequark commented on issue #631: Windows artifact complains about vcomp140d.dll - https://git.io/Jf7Mg
<_whitenotifier-f>
[solvespace] whitequark commented on issue #631: Windows artifact complains about vcomp140d.dll - https://git.io/Jf7M2
<_whitenotifier-f>
[solvespace] phkahler commented on issue #631: Windows artifact complains about vcomp140d.dll - https://git.io/Jf7MM
leorat has joined #solvespace
<_whitenotifier-f>
[solvespace] RodrigoTjader opened issue #632: Problems with text extrusion when forcing triangle mesh - https://git.io/Jf7Dz
leorat has quit [Remote host closed the connection]
leorat has joined #solvespace
leorat has quit [Remote host closed the connection]