<wpwrak>
so what determines the mesh export tolerance of the linked files ? hard-coded ? :)
<whitequark>
nope
<whitequark>
what's used is the display tolerance during the last save
<whitequark>
this is wrong, and this can't be fixed without true hierarchical sketches
<whitequark>
this happens in one condition though, if you force NURBS to triangle mesh.
<whitequark>
if you link a sketch with NURBS surfaces, then the tolerances (export or not) from the assembly sketch are used
<wpwrak>
yes, i need to force meshes. else i get nakes edges. and you told me i should get rid of them :)
<wpwrak>
so the work-around would be to 1) lower the display tolerance in /.config/solvespace/settings.json, 2) solvespace-cli regenerate *.slvs; 3) solvespace-cli export-mesh ?
<wpwrak>
or is the answer "wait for a patch" ? :)
<whitequark>
that workaround wouldn't really help
<wpwrak>
so what can i do ?
<whitequark>
(because -cli doesn't care about any settings set in the GUI, or anything else not on command line, for repeatability)
<whitequark>
well, a proper solution would be to fix the issue that breaks the NURBS backend
<whitequark>
can you do that?
<wpwrak>
how would i find out what that is ?
<whitequark>
it's usually surfaces that are coincident in weird ways.
<whitequark>
but you could send me a sketch and tell where the issue first appears
<wpwrak>
lemme try a few things ... if run out of ideas, i'll cry for help
<whitequark>
what about using "solid model as: assemble" in group settings?
<whitequark>
this will leave two surfaces in the middle of your thing.
<wpwrak>
an-side defines the side wall. it also contains a sketch that defines most of the device's geometry. an-side-overlap is a continuation of the wall, but with a little step for the cover
<wpwrak>
with "assemble" instead of "union" it gets worse
<whitequark>
oh, right
<whitequark>
how about extracting the sketch-in-worklane extruded in an-side into its own sketch, then extruding that once (for an-side) and another time (for an-side-overlap, a two-side extrusion) then doing a difference to add the 'step' ?
<whitequark>
let me file a bug though, I think Aleksey might be able to fix this...
<whitequark>
wpwrak: meanwhile you can make a really horrible workaround in your local solvespace tree
<wpwrak>
i suppose the problem may have two parts: 1) that the coincident arc has non-identical definitions (i.e., they describe the same curve, but one is shorter), and then 2) something going wrong when making the union with the empty space for the step
<whitequark>
adjust the "regenerate" command to first perform a regeneration for an export, and to take an export chord tolerance parameter
<wpwrak>
(#171) thanks ! ah yes, control points would explain my 1) and 2)
<whitequark>
I don't think 2) is a problem at all
<whitequark>
but I may be wrong. so whatever.
<wpwrak>
so evil-spirit is the project's nurbs guru ?
<whitequark>
the project's computer graphics guru and the only full-time dev
<whitequark>
he didn't have much nurbs experience but told me that he picked a book about it recently or something
<whitequark>
let's hope he can fix it, because no one else surely will
<wpwrak>
yeah, computational geometry tends to be messy
<whitequark>
he did all the shaders stuff in the GL2 renderer and so on
<whitequark>
meanwhile I failed to make a triangle rotate with the programmable pipeline
<wpwrak>
every beginning is hard :)
<wpwrak>
that was an interesting chain of issues: 1) 3D prints look bad -> 2) tolerances are too high -> 3) tolerance settings get ignored for meshes -> 4) NURBS unions are broken
<whitequark>
this is actually better than the situation in 2.0
<whitequark>
in 2.0, tolerance was set based on zoom level.
<whitequark>
and then the mesh saved to the file
<whitequark>
so you would actually have to *zoom in* then resave everything. and pray you zoomed in to the right level of detail
<wpwrak>
sweet ;-)
<whitequark>
naturally this also affected convergence of the NURBS backend (though not the solver)
<whitequark>
which is what caused me to fix this disaster
<wpwrak>
well done ! :)
<whitequark>
well, not-so-well-done...
<whitequark>
or we wouldn't have this discussion
<wpwrak>
i guess a lot of things will fall into place once you have support for multi-part designs
<whitequark>
yes.
<wpwrak>
then it should also be easier to control visibility. in my case design i now have a bewildering number of points and lines, very frequently overlapping
<whitequark>
but right now, solvespace uses the technique well-known to C programmers, namely "let's stash everything into global variables"
<whitequark>
that makes it really friggin hard to do anything useful with more than one sketch at a time
<wpwrak>
and the current "flat" visibility control only helps a bit
<wpwrak>
one sketch or one part ? i don't see any issues (from a user's point of view) with having multiple sketches
<wpwrak>
the problems only start when i have multiple parts, be it multiple outputs (e.g., top shell, insert, and bottom cover), or be it repated elements of the same larger part (e.g., left and right wall)
<whitequark>
a part is called a "sketch" internally
<whitequark>
which is annoying and confusing
<wpwrak>
oh, indeed :)
<whitequark>
what you call a sketch is called a "group"...
<wpwrak>
whitequark: btw, an idea for reducing the clutter on the screen you get with complex models: only show points that are either not related to anything else or that belong to a selected object. where "belong" could also include being connected through a constraint. in fped i use a similar approach for changing points (there, points are constructed with a network of vectors, and then lines and such are drawn on top of points. changing a
<wpwrak>
point means setting up the new vector, selecting the item to change, then dragging the respective point (endpoint, center, etc.) to the new location)