<GitHub>
[solvespace] whitequark commented on issue #195: > Right now, arcs and circles (and maybe splines as well) are drawn with a relatively large chord tolerance, which often results in significant visual differences between the ideal arc and the polygon displayed.... https://github.com/solvespace/solvespace/issues/195#issuecomment-278956133
<GitHub>
[solvespace] wpwrak commented on issue #195: The problem with setting a significantly smaller chord tolerance is that SolveSpace becomes extremely slow, probably since the chord tolerance also affects mesh operations. I guess having separate chord tolerances for arcs display and meshes could accomplish what I'm after.... https://github.com/solvespace/solvespace/issues/195#issuecomment-278969384
<wpwrak>
regenerating edges, expensive ... due to hidden line removal ?
<whitequark>
no, hidden line removal is done completely in shaders
<whitequark>
there can just be a lot of edges.
<wpwrak>
plan B: do sketches in cairo ;-))
<wpwrak>
but i guess an option to disable smooth arcs could help with such cases.
<wpwrak>
or just have a separate chord tolerance for arc display that can be set to either a model distance (mm) or a number of pixels (zoom-dependent)
<GitHub>
[solvespace] Evil-Spirit commented on issue #194: @wpwrak, an-cover.slvs is false dof reporting... i can't figure out why... but if you will remove all the groups but oled13, same orientation constrains only 2 dof instead of 3. but if you are create the empty file and apply same-orientation, it will constrain 3 dof as it should. https://github.com/solvespace/solvespace/issues/194#issuecomment-278999331
<wpwrak>
#196 is interesting, because it also shows that slvs can do better than just delete anything that depends on a point being deleted. e.g., if the same could be done with points on which groups depend (through the workplane, i guess (?)), then deletion could be a lot less traumatic
<GitHub>
[solvespace] Evil-Spirit commented on issue #194: @wpwrak, an-cover.slvs is false dof reporting... i can't figure out why... but if you will remove all the groups but oled13, same orientation constrains only 2 dof instead of 3. but if you are create the empty file and apply same-orientation, it will constrain 3 dof as it should. https://github.com/solvespace/solvespace/issues/194#issuecomment-278999331
<GitHub>
[solvespace] whitequark commented on issue #196: This is working as intended; solvespace explicitly ignores trivial constraints (generate.cpp:335) since otherwise deleting any request would result in the warning. https://github.com/solvespace/solvespace/issues/196#issuecomment-279000042
<whitequark>
wpwrak: uhm, no? you're misunderstanding what a dependency is
<whitequark>
a constraint between two points doesn't create a dependency between them
<whitequark>
the constraint depends on each of the points, and that's all
<GitHub>
[solvespace] wpwrak commented on issue #194: @Evil-Spirit: I think I found it: if I delete the same-orientation constraint, switch to "Anywhere in 3d", and re-create it, I get DOF = 0. So the loose DOF was probably for real, caused by user error. Still, it should be reported. https://github.com/solvespace/solvespace/issues/194#issuecomment-279001810
<wpwrak>
btw, i sometimes see "Anywhere in 3d" and "In Workplane" having a dot at the same time. bug of feature ?
<wpwrak>
meh, s/of/or/ :)
<whitequark>
bug
<whitequark>
wpwrak: ohh, same-orientation cosntraint in workplane
<whitequark>
hm
<whitequark>
that makes no sense, it doesn't have an in workplane variant
<wpwrak>
let's find out ...
<wpwrak>
solvespace is rather certain that it does ;-))
<wpwrak>
this also seems to be a way to schoedingerize the WP/3D indication
<whitequark>
hmm, this is definitely a bug
<wpwrak>
add to #194 or new issue ?
<whitequark>
new issue
<GitHub>
[solvespace] Evil-Spirit commented on issue #194: The problem with assemblies is in fact what correspondent point doesn't exist. Imported group just generate some parameters for position and rotation quat which don't liked with any of the existent entities. So, there are nothing to visualize, we have to visualize it by different routine (per group) not inside point or any other entity. https://github.com/solvespace/solvespace/issues/194#issueco
<wpwrak>
hmm, i have a file that passes all checks at the GUI (with no errors on the console), intersection, naked edges, i can even generate the mesh without complaints. however, if i solvespace-cli regenerate it, all hell seems to break loose: https://0bin.net/paste/Slv+gUdkDWw+CND3#jGsDZuFpYRW++PsQm4dPPk6botUwszrXjbqMmaKYnJW
<wpwrak>
should i worry ?
<whitequark>
different chord tolerance
<wpwrak>
hmm, tolerance and segments are the same for display and export
<whitequark>
but not when using the cli
<whitequark>
where you're using the default chord tolerance
<wpwrak>
aah, i see. so ... not a real problem then ?
mifune has quit [Read error: Connection reset by peer]
mifune has joined #solvespace
mifune has joined #solvespace
mifune has quit [Changing host]
mifune has quit [Ping timeout: 240 seconds]
lexszero has joined #solvespace
<lexszero>
hi all. is it possible to reorder groups somehow so the boolean operations are performed in desired order?
<wpwrak>
lexszero: yes, but it's a little complicated. in the .slvs file, there's a field called Group.order for each group that contains a numerical index for ordering
<wpwrak>
e.g., if you want to move a group called gXXX-foo to the end, you can 1) look at the numbers in use, and pick one above the last one (on unix: grep Group.order whatever.slvs), 2) edit whatever.slvs, search for the group's name (Group.name=foo), change the corresponding Group.order field, 3) open the file with solvespace and see if it worked
<wpwrak>
before all that, i'd make a backup :)
<lexszero>
thank you, I'll try it
<lexszero>
worked perfectly. maybe i'll make a little script to simplify this (like dump ordered list of groups - reorder list manually - take the new order and renumber)
<wpwrak>
that could be quite useful indeed
<lexszero>
i like that the file format is textual and can be hacked easily :)
<wpwrak>
yeah, and you can easily check if all groups are there and such. you just have to extract the gNNN as well
<whitequark>
it's not going to remain textual for long
<wpwrak>
hear, hear ! ;-)
<whitequark>
though there'll always be a tool to convert to and from a textual representation
<whitequark>
we need it for tests
<wpwrak>
very good. the ability to script is pretty important. plus, it can keep people from nagging you too much about features :)