<ohsix>
whitequark: how do i model filtercapplug.slvs without the naked edges/bad geometry, i tried doing it a few ways and messing with the settings for curves but never got a manifold model https://www.dropbox.com/s/crd6ljtjb6kme8v/fillercapplug.zip?dl=0
<ohsix>
lots of crap i want to model is like that, round, extrude a few faces, and the ways i've done it are generally notgood
L29Ah has quit [Remote host closed the connection]
<el3phanten>
ah I see the outer edge does not follow the one below
<ohsix>
i did it like that the first go, or do you mean leave the entire thing while i extrude from the same plane for the other feature?
<ohsix>
first go was a circle, extrude, circle with that tab, extrude, circle for final length, extrude, and it was worse; then i tried extruding the tab as a section and it was a bit better but there were still some bad edges
<el3phanten>
well the way I showed you still does not follow the edge below even if its ø16
<el3phanten>
so, maybe a difference object would be better
<el3phanten>
ohsix: am I understanding your problem right?
<ohsix>
just need to know how to make that shape with it being manifold, so i can 3d print it, all the different ways i could think of modeling it still had bad edges
<el3phanten>
ohsix: https://imgur.com/a/038Lc how about manually draw that line to follow the base edge
<ohsix>
sec, that's not actually where the bad edges end up
<el3phanten>
maybe start the inner cylinder at the same place where the base starts
<el3phanten>
so you are sure they intersect
<ohsix>
ahh that is a good idea
<ohsix>
and i didn't try that
<el3phanten>
seems to work here
<ohsix>
so, model the long cylinder, then put a 'wing' and a ring on it?
<ohsix>
go to Analyze -> Show naked edges
<el3phanten>
the order does not matter
<ohsix>
does it say everything is ok?
<el3phanten>
oh sry. I am new to this :)
<el3phanten>
ohsix: okey I dont get problems around the cylinders, but I need to start the g004 sketch also at the base
<el3phanten>
get errors around that
<el3phanten>
ohsix: so it seems that you just need to be sure the items intersect a bit, to get the unions right
<el3phanten>
ohsix: yes that did it. No errors now
<el3phanten>
so the order does not matter. You can just make the base cylinder ø16, and then the second, ø12 or what it was, make it start at the base or in the middle of the other cylinder. Not on it
<el3phanten>
same goes for the other extrusion
<ohsix>
k, i'll try that when i can
<ohsix>
i'm new to it too, thanks for looking
<el3phanten>
you are wellcome
<el3phanten>
I am new to solvespace. I am familiar with boolean operations in other software tho. When creating a union of two objects it is probably best to let them intersect a bit. If it detects just a small space between the surfaces, they might not union as you want. I dont know if there is a tolerance setting here, where you choose max distance between those two.
<ohsix>
that is a good point
<ohsix>
~all the problems i've had are with coplanar faces
<ohsix>
in one way or another
<el3phanten>
ok, so that might be the problem. Maybe whitequark has a better solution tho, than specifically trying to intersect. Because sometimes its just nice to start a sketch on a point on the object
<ohsix>
ya i've been thinking about it, there wasn't another way obvious to me to try it, just the workplanes and extrusion, but coplanar faces are going to be a problem
<ohsix>
in some cases they'll work, in a lot of other cases floating point number representation is implied and it's all inexact ;]
<whitequark>
ohsix: el3phanten: problem still exists?
<whitequark>
if yes can you describe the current status
<whitequark>
as for what el3phanten said about union: yes, intersecting "deeply" is always preferable from boolean op fidelity standpoint
<whitequark>
in general plane faces virtually always glue together properly *unless* there's a curved face nearby
<whitequark>
and curved faces almost never do
<whitequark>
it's a known issue in the NURBS backend
<el3phanten>
whitequark: the problem was that he object did not intersect
<el3phanten>
the other problem we talk about. If you extrude two cylinders of the same diameter, it will break
<el3phanten>
that was fixed by creating different diameters, and use a pipe around to difference
<whitequark>
yeah, it's quite aggravating
<el3phanten>
its okey, it can be avoided
<el3phanten>
just mentioning it here, because maybe you could tell us, that we missed some settings or something like that.
<el3phanten>
the pipe as difference works well for me. I dont know if I understood ohsix right
<ohsix>
whitequark: don't know if it is a problem, it's still just the same stuff i asked about before when two faces coincide at the edge
<ohsix>
but, for the original question, the way i was modeling it i got some bad faces and it was non-manifold; el3phanten suggested doing it in a way i hadn't tried and that worked pretty good
<ohsix>
also now i know that parts should penetrate a little for them to be properly intersected, when i'd extrude on the face of something, the stuff that came together at the workplane wouldn't intersect right either
<ohsix>
there's only so many vertices for stuff to connect to, so there were missing edges and junk
<ohsix>
haven't used enough cad or 3d modelling packages to really know if i'm generally just doing something stupid that can't work
<whitequark>
no, it has nothing to do with vertices
<whitequark>
in fact if you force it to mesh you'll see the naked edges disappear most of the time
<whitequark>
the problem is some sort of exact curve processing issue in the boolean op code
<wpwrak>
then don't show entities -> black nothingness
<wpwrak>
force NURBS to mesh -> solid is back
<whitequark>
huh
<wpwrak>
maybe it doesn't like that the original has been forced. i see that you make a change regarding mesh forcing recently
<whitequark>
I'll take a look in a moment
spaceSub has quit [Quit: So Long, and Thanks for All the Fish.]
<wpwrak>
g
<wpwrak>
oops. system acting up, recovering from slvs eating all memory after setting low chord tolerance ...
<wpwrak>
seems that the display chord tolerance is not applied to things that come from an assembly ?
<whitequark>
if an assembly was forced to triangle mesh (in any way), then it is "frozen"
<whitequark>
it won't be recomputed
<whitequark>
so... no display chord tolerance change, no export chord tolerance change, and export of the entire assembly uses display chord tolerance for parts
<whitequark>
at whichever time you've saved them
<wpwrak>
ewww. there really ought to be an option to recalculate everything (without changing the .slvs files)
<whitequark>
hahahahaha no
<whitequark>
not in a thousand days
<whitequark>
the current architecture is extremely hostile to this
<whitequark>
like I mentioned before, the amount of refactoring necessary is tantamount to rewriting half of solvespace
<whitequark>
this is actually a milestone goal for 3.0 but I'm increasingly thinking that we should release 3.0 without it
<lexszero>
and then you will need to rewrite 3/4 of slvs instead of just half
<whitequark>
lexszero: hm?
<whitequark>
I need to rewrite like... all of slvs
<wpwrak>
whitequark: quick hack: "save to memory / temp file", and "assemble from memory / temp file". the you can just run the usual process for each of the ancestors.
<whitequark>
wpwrak: then just write a shell script
<wpwrak>
if solvespace-cli regenerate uses -t, then that may be possible already after fixing the dialog crash
<whitequark>
it doesn't
<whitequark>
but that's easy to fix
<wpwrak>
kewl. then i can finally write my shell script ;-) that is, one the dialog is fixed, too
<wpwrak>
at least i hope there's no other problem. but if there is, it'll find out soon enough ...
<GitHub>
[solvespace] whitequark commented on issue #206: @Jonimoose can you please verify that the issue here is that STEP files exported by SolveSpace do not share edges between different bounding surfaces in the same solid? https://github.com/solvespace/solvespace/issues/206#issuecomment-292731063
<GitHub>
[solvespace] whitequark commented on issue #232: This is expected, and was extensively discussed before. SolveSpace cannot be built with Debian Jessie (stable, soon to be oldstable) but can be built with Debian Stretch (testing, soon to be stable). https://github.com/solvespace/solvespace/issues/232#issuecomment-292577663
<GitHub>
[solvespace] whitequark commented on issue #232: This is expected, and was extensively discussed before. SolveSpace cannot be built with Debian Wheezy (stable, soon to be oldstable) but can be built with Debian Jessie (testing, soon to be stable). https://github.com/solvespace/solvespace/issues/232#issuecomment-292577663