<awygle>
trying to think how to phrase this, can i have an extrusion where the two ends of it are not just parallel planes? or do i have to do another difference later to make that happen?
<awygle>
like if i wanted to do "extrude until you hit this surface" but that surface is curved
<whitequark>
unfortunately there's no such operation
<awygle>
bummer. ah well. hopefully differencing down from the curved surface won't make NURBS explode :p
<awygle>
it's weird that you can't select a plane as the source for a workplane
<whitequark>
I had to revert a patch that did that because of backwards compat concerns
<awygle>
shit, it did cause NURBS to explode. think i can fix it tho...
<whitequark>
yeah, it's pretty frustrating
<awygle>
master actually seems to perform much worse
<whitequark>
ok, so rs-422 has 100 ohm impedance, aui has 78 ohm (is that what IDC cable has? 50 meters of IDC per 802.3 sounds mildly insane)
<whitequark>
(still building)
<whitequark>
and I need 5 dB of attenuation to go from 3.3V to 1V
<awygle>
the values given by that calculator in that situation pass my sniff test (i expected slightly above Zmax in the middle and somewhat lower on both ends)
<whitequark>
hm, the driver actually works with a lot of different line impedances from 54 to 100 ohm
<whitequark>
I don't think I really need to match that, so I can just use 78 for both. that cuts down on resistor values considerably.
<awygle>
honestly a 100 to 78 mismatch is probably not that bad even if you just hooked them up directly
<awygle>
oh fuck off windows defender, i know what i'm doing
<whitequark>
that's why i didn't ask you for an email
<whitequark>
no idea what provider you use, but i'm sure it'd shred an exe
<awygle>
i share your certainty
<awygle>
oh yes that's MUCH better. it renders all the bright red conflict lines much more quickly :p
<whitequark>
hahaha
<whitequark>
yeah, we switched from immediate mode opengl to VBOs
<whitequark>
and added a lot of caching elsewhere
<awygle>
i should have no expectations that my NURBS woes will be improved by this change, though, right?
<awygle>
still basically the same solver?
<whitequark>
not significantly
<whitequark>
there's been some minor improvements
<whitequark>
it's unlikely you'll notice, but it is slightly better
<awygle>
all right well at least when i have to scrap half my groups to try and get to a more nurbs-friendly formulation it'll be a lot faster to redraw them lol
<awygle>
thanks wq
<whitequark>
yeah NURBS are hard
<whitequark>
sadly most people with complex geometry gave up and switched to f360
<whitequark>
can't blame them
<awygle>
i'm gonna finish this design in solvespace
<awygle>
i'm fighting an urge to say "sooo why exactly can't integrating opencascade work? maybe i could take a look..." which i know will not end well for anyone
<whitequark>
we're mostly not doing it for ideological reasons. the original author didn't because he considers opencascade a giant pile of atrocious code, which it is
<whitequark>
I share his opinion of OCE; I dislike it *slightly* less but still have no burning desire to integrate it
<whitequark>
you know what the problem with OCE is?
<whitequark>
it's developed by the org that sells consulting
<whitequark>
for OCE
<whitequark>
negative incentive to make it any better
<awygle>
oof. yes.
<whitequark>
it would probably be acceptable to have an optional OCE integration but I would advise you against trying to do it unless you have so much time you don't know what to do with it
<awygle>
yeah, i figured
<whitequark>
SolveSpace isn't the easiest codebase to work with, either. we're changing that, slowly, but it's complex
<whitequark>
lots of implicit interrelated dependencies you have to keep to avoid breaking savefiles
<awygle>
and as far as improving solvespace's solver, is that primarily a "nobody's paying so it's not a priority" or a "this is technically extremely difficult" or both?
<whitequark>
solver or NURBS?
<whitequark>
these two are completely orthogonal
<awygle>
NURBS i guess
<awygle>
the solver is good
<awygle>
i wasn't sure how they related
<whitequark>
it's technically extremely difficult
<whitequark>
there are very few people who can actually do it. I know... one or two, and I'd have to hire them, pay them a competitive salary, and become a manager basically
<whitequark>
so unless you have something like $6K/mo laying around
<awygle>
not currently, no
<whitequark>
there's a reason no open-source NURBS library does booleans, except OCE and SolveSpace
<whitequark>
I looked really hard over the years, and no one else did it. well, unless there's a new once since ~2y ago, but unlikely
<whitequark>
there's just no options even if you ignore the language
<awygle>
understood
<whitequark>
people mostly do for things like csg or brep, which are stupid easy to do booleans on
<whitequark>
and then you can't export STEP so it's pointless
<awygle>
i feel like i saw a roadmap-ish post once that said "we need to move from NURBS to <something that sounded like NURBS but wasn't>", but maybe i'm making that up
<whitequark>
don't think so, since NURBS is one of main advantages we have
<awygle>
arright. well thanks for the info. i didn't really think there'd be a feasible solution or you'd have done it already.
<whitequark>
it'd still be a lot of effort to replace the NURBS backend, but yeah, there isn't even anything to replace it with besides OCE
<whitequark>
the NURBS math is truly heinous for booleans
<whitequark>
fun fact: the booleans aren't actually exact
<whitequark>
since there are many cases with no closed form solution
<whitequark>
(or at least that's what I understood, I'm really bad at this sort of math)
<awygle>
is it possible for a certain geometry to be unexpressible in solvespace? (with exact nurbs i mean)
Ekho- is now known as Ekho
<whitequark>
oh, sure
<whitequark>
any loft along bezier
<whitequark>
probably many simpler examples
<awygle>
"loft along bezier"?
<awygle>
oh thank god i managed to express it. hopefully when i recreate everything else it'll still work.
<whitequark>
awygle: like, drag a 2d sketch along a bezier curve
<whitequark>
to make a solid
<awygle>
oh, like for threads
<whitequark>
no, those actually can be done with helix
<whitequark>
it's ... quite slow right now, and even more fragile than usua
<whitequark>
but it is doable
_whitelogger has joined #solvespace
mauz555 has joined #solvespace
mauz555 has quit []
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #solvespace
cr1901_modern1 has joined #solvespace
cr1901_modern has quit [Ping timeout: 272 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #solvespace
stultulo has joined #solvespace
f8l has quit [Ping timeout: 272 seconds]
stultulo is now known as f8l
<awygle>
... i have a symmetrical sketch, on a symmetrical part, where one half of the sketch causes a NURBS failure when extruded and the other half does not.
<awygle>
ended up fixing it by changing a dimension but still, weird