<InPhase>
joseph_: Reviewing your list of issues, I'm reasonably confident this is from trying to trigger it before fully understanding how the code gets to the parts that change it. This is of course a reasonable first step to intuit and try to leap ahead and see if you can keep going. But it failed, as happens a fraction of the time, so the efficient track is to backtrack and build up the proper understanding
<InPhase>
of the flow with printouts gradually worked backwards. Start at the part of the code that sets the shader, and have it print or log what shader it's using (or at least an identifying portion of it). Then work up the chain to everything that can call it so you know how it gets there each time it does, and as you work up the chain keep putting marker printouts into the code for the things that can call
<InPhase>
the hot path you're trying to debug until you have a printout sequence that shows you how you are or aren't getting to where you want to be, and then add in printouts for the elements that are causing the faulty branch, then trace back the source of those elements with more printouts. Do it right, and you'll eventually have a sequence of prints giving you full visibility to what you're trying to fix,
<InPhase>
and won't be working blinded by the confusion of what we sometimes disparigingly call "other people's code". ;)
<InPhase>
joseph_: This printout work should take significantly less time than the time you appear to have already spent trying to sort it out the other way, and you'll get more than success out of it, as you'll also come away with a clear picture and understanding for the full set of changes you need to make.
<InPhase>
joseph_: Don't fear cluttering the code or cluttering the git tree. You can git squash, or otherwise copy over the successful parts later. The temporary insertion of disposable intermediate code is a huge value, and easy to clean up with all the diffing and version control features available. (And you'll have a small number of lines to keep from this particular step anyway, I think.)
<robwerks>
that hurt my brain
<robwerks>
you coders are amazing
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
J1A8487 has joined #openscad
robwerks has quit [Quit: Peace to all and to all a good piece!]
J1A84 has quit [Ping timeout: 252 seconds]
qeed has joined #openscad
Guest15 has joined #openscad
ali1234 has quit [Remote host closed the connection]
_xxoxx has joined #openscad
Junxter has quit [Ping timeout: 244 seconds]
RichardP_ has quit [Ping timeout: 244 seconds]
<J1A8487>
zingos there is something about slicing (inclusive or exclusive) that will drastically change the size of threads - but default slicer use something in between and as Inphase lib is empirical it is for sure a good way to go. Besides the printing also every moving parts need some clearance and screws have by definition a very big gap between
<J1A8487>
bolt and nut thread.
<J1A8487>
joseph_ Just want to say - Great that you put in all that work! Thanks!
<InPhase>
J1A8487: In several cases my printed threads were calibrated to be tighter than metal nuts and bolts would be. But this is actually on purpose, because plastic is more flimsy. Not only does it have more beneficial flex, it also has more harmful flex that weakens the hold or threatens to slip the smaller threads out. But when you pack it all in tighter, you get a more secure result.
<InPhase>
If someone were printing with metal, my numbers would probably be inadequately adjusted.
<J1A8487>
yeah metal printing behave totally different due to the thermic dif of 1000K
__xxoxx has joined #openscad
<InPhase>
With the small threads, the difference from packing tighter can be very enormous. Removing a small clearance gap can add 50% to 100% more contact area.
<J1A8487>
also plastic will deform and so threads "wear in" and get smoother surface when used
<ccox_>
your numbers seem to be ok when matching plastic and metal parts -- at least with the SMA connectors, and other threaded fiber bundles I've tested.
<InPhase>
And then on top of that there's just no room left for the plastic to bend.
<InPhase>
ccox_: Yeah, I ran parallel tests plastic to plastic, metal to plastic, and plastic to metal, and adjusted both sides until all three of these worked out.
<ccox_>
That's sorta what I suspected. It's working great for the random spectroscopy accessories I need.
_xxoxx has quit [Ping timeout: 240 seconds]
<InPhase>
ccox_: Honestly I thought it would vary more printer to printer, but most people over the years have reported it just works for them.
<J1A8487>
iirc your lib changes the angle of thread surfaces with the clearance - but that should be small and tolerance increase bolts which is strange.. however it works - i can only assume that changing the tolerance value could have strange effects.
<InPhase>
The better quality printers that came out since then seem to have just made it more reliable for people, since I had very meticulously calibrated my printer before those tests.
<ccox_>
I always love surprises like that.
<J1A8487>
pretty sure you get problems if sliced inclusively (the more with .2 layer)
<J1A8487>
403 The server understood the request, but will not fulfill it. (what an a…ttitude )
<ccox_>
My guess is that it is a permissions issue, that just has horrible error messages ;-)
<J1A8487>
ok google is creating individual links ..
<J1A8487>
(image is from a google site webpage)
<J1A8487>
if you don't visit the site - the direct link is denied
RichardPotthoff has joined #openscad
ur5us has joined #openscad
KimK has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
<J1A8487>
oh the warning "current tab changed - you want export previous render" didn't show when using customizer to change (2022.05.04)
_xxoxx has joined #openscad
__xxoxx has quit [Ping timeout: 244 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
KimK has quit [Quit: Leaving]
KimK has joined #openscad
_xxoxx has quit [Read error: Connection reset by peer]
_xxoxx has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
linext_ has joined #openscad
linext has quit [Ping timeout: 240 seconds]
la1yv has quit [Ping timeout: 244 seconds]
la1yv has joined #openscad
la1yv has quit [Remote host closed the connection]
la1yv has joined #openscad
ur5us has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
teepee has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
teepee has joined #openscad
lauraaa has joined #openscad
<lauraaa>
heyo guys
<lauraaa>
for the people who waw around when i came here, i am glad to let you know that i finally finished the project
<teepee>
nice, did you get some prints in hand too?
<lauraaa>
well, not in my own had, someone from here helped with the 1st version of the model, i made some changes to the code and script so rn, I have no idea how it looks like in real life
<lauraaa>
hand*
_xxoxx has quit [Ping timeout: 255 seconds]
<J1A8487>
maybe we could add your project to the gallery
<J1A8487>
lauraaa did you manage the numbers with the prefix?
<J1A84>
a dirty acceleration is to keep objects .001 apart - the slicer should ignore that (and if not it wouldn't matter much) and the render doesn't need to calculate intersection of objects like with lazy union
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<Scopeuk>
lauraaa just to confirm "is there a faster way to convert from scad to stl?" is this faster than running openscad my.scad -o my.stl ? if so the only thing is the experimental stuff J1A84 mentioned that is in the nightly
<Scopeuk>
how your design is implemented has a massive affect on how long it takes to render in openscad so it can be worth optimizing sometimes
<Scopeuk>
and when testing turning down how smooth circles are etc
<J1A84>
if the dot is a module there shouldn't be a big increase due to the use of many dots except the union of them all
fling has joined #openscad
<InPhase>
lauraaa: A particular approach to doing a design can have an enormous impact. I've had things go from 30 minutes to 30 seconds to render just by coming up with smarter ways to do it.
<InPhase>
lauraaa: The right way to think of it is that it's not so much a conversion, as running a scad program, so it will do the amount of work you give it to do. :)
<InPhase>
lauraaa: Although there are, as mentioned, experimental improvements that are pushing some decent multiples in improved performance, depending on what the design contains.
<InPhase>
lauraaa: For a rough sense, the dominant predictor of OpenSCAD runtimes on a design is the number of geometric interactions that have to be computed times the number of faces that make up those geometric objects.
<InPhase>
lauraaa: So one easy approach to getting better performance is to make sure you make only the faces you need for a particular print outcome, and then look for opportunities to obtain the same shape with fewer geometric interactions.
<InPhase>
lauraaa: And then, sometimes you just accept a slower final render in favor of a really quick simple scad routine to write, and you let the computer do work instead of doing work yourself.
<J1A84>
it's spheres on a cube .. so nut much to improve except using a mesh polyhedron and just moving the dots up.
<J1A84>
\s\nut\not
<InPhase>
Is there a link to the current source for it?
<lauraaa>
im sorry, i am back
<lauraaa>
there is no link yet, but i can create a pastebin