teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
<J22> OlivierChafik[m]  any idea why https://v.gd/7etPqU   took   1221sec to display?   (i unchecked the render box but doesn't helped)  and  on my pc this show in  .3 sec and render in 34sec  ..  ( but cool that it worked in the end )
<InPhase> J22: That's a heavy testcase. Maybe if you aggressively hack pieces out until you find the minimum that's still wildly different, and then inline the library, and continue hacking down to a minimum.
<OlivierChafik[m]> It renders very fast w/o fast-csg
<OlivierChafik[m]> (also, might be unclosed)
<OlivierChafik[m]> (tick "show experiments" and untick fast-csg)
<InPhase> J22: That has been the necessary step for most of the fast-csg fixes so far, since there's so much going on.
<J22> i didn't get any error locally
<OlivierChafik[m]> mmh maybe I'm testing with a weird build haha
<OlivierChafik[m]> the extreme slowness can be a case where corefinement failed and the nef fallback was used instead. If you enable fast-csg-debug it will tell us (although rn I'm not streaming errors so it's all gonna come at the very end :-( )
<OlivierChafik[m]> it could also just be a case where having a lazy kernel helps a lot, and I've disabled the laziness with my custom coarsely-filtered kernel
<J22> only the union is taken 10 sec without fast  csg
<OlivierChafik[m]> I did witness very weird slow nef bevhavioru in fallbacks but was convinced it was a lazy thing
<J22> but with  much longer
<J22> https://bpa.st/HMBQ   this is from render locally with debug
<J22> (not web)
<OlivierChafik[m]> I'm getting a "mesh is not closed" warning but maybe my local ub.scad version is lagging behind?
<OlivierChafik[m]> btw fast-csg-remesh should cut the # facets in half
<J22> running 2022.02.18    the  ub.scad is 22.07  but the used modules probably haven't changed that much  (Zylinder and Pill)
<OlivierChafik[m]> (i was at 056|22)
<J22> although there is a 0 dimensional double face which may cause problems  for fast CSG maybe as it could be manifold
<J22> between  056 and 072  Pill() and Zylinder() wasn't changed (according to my log)
<OlivierChafik[m]> yeah there are unclosed bodies in here, used the latest ub.scad + latest dev snapshot (OpenSCAD-2022.03.11). But that doesn't explain why it's slow. I think the next steps for wasm performance are to ask the CGAL folks for help, but I'm taking a rest from that for the weekend haha (rn, adding autocompletion for includes :-D)
<J22> hmm the union rendered in 315sec   and is missing the top and bottom of Zylinder()  the  issues i assumed are on the side
<J22> OlivierChafik[m] where did you see .. or how that the mesh is not closed?
<OlivierChafik[m]> https://bpa.st/GS7A
<J22> looks fine to me https://pasteboard.co/7xwsrD6wdlbM.png   and the  export is fine .. not sure how to see https://pasteboard.co/7xwsrD6wdlbM.png
<J22> ah ok so your newer version shows that
<OlivierChafik[m]> latest dev snapshot of openscad, latest ub, same issue as with older ub
<J22> include<ub.scad>;
<J22>       union(){
<J22>         Zylinder();
<J22>         cube();
<J22>       }
<J22> with fast csg the top and bottom are missed ..
<OlivierChafik[m]> ah ok yes that is definitely closed
<OlivierChafik[m]> oh I spoke to fast, no it tells me it's unclosed
<OlivierChafik[m]> but maybe it's saying that after corefinement failed already, or something
<J22> hmm i wonder why .. the top is  a multi point face
<OlivierChafik[m]> ooooh... It keeps the top if I do F5 before F6, but crops it if I do F6 straight away
<OlivierChafik[m]> could you please file it on github?
<J22> ah that again .. i have this with  some  .. that somehow preview data is needed
<OlivierChafik[m]> (I love that model btw haha)
<J22> ( i have so funny  things  that you can render each part  seperately and it is working but not if you try all at once with a flushed cache - different model)
<OlivierChafik[m]> hope they all get fixed together, the smallest test case the better
<J22> OlivierChafik[m]   can you try this with F5 F6  and then Flush Cache  F6 (without preview)  https://bpa.st/7N2Q
<OlivierChafik[m]> oh yes, it eats up one of the legs without the preview
<J22> one face is redundant
<OlivierChafik[m]> i reckon there's one off-by-one mismatch in the poly
<OlivierChafik[m]> yeah we should probably reject such polyhedra
<OlivierChafik[m]> (ideally with some coloring of the offending faces maybe)
<J22> no the issue is not from the redundant face .
<J22> it is how  quad calculate
snakedGT has joined #openscad
<J22> https://bpa.st/3PPQ   corrected code
Junxter has quit [Quit: Leaving]
snaked has quit [Ping timeout: 240 seconds]
<OlivierChafik[m]> btw, BOSL2 has a very nifty debug_vnf helper: https://pasteboard.co/1xyeNYfDiLnH.png
<J22> ( i have one with  Points() )
Junxter has joined #openscad
<OlivierChafik[m]> oh yes most likely!
<OlivierChafik[m]> the smaller the better, i like simple polyhedra better than that example with randoms tbh haha
Junxter has quit [Max SendQ exceeded]
<OlivierChafik[m]> (fingers crossed that they have the same cause)
Junxter has joined #openscad
myosotis has joined #openscad
<gbruno> [github] UBaer21 opened issue #4166 (Fast CSG render without Preview missing face from quad) https://github.com/openscad/openscad/issues/4166
<gbruno> [github] UBaer21 edited issue #4166 (Fast CSG render without Preview missing face from quad) https://github.com/openscad/openscad/issues/4166
<linext> so that adapter i posted yesterday worked, sort-of
<linext> the problem is the probe is not protected from bottoming out
<linext> the electronics allows the auto-level probe to crash into the bed and keep going
<linext> so i'm printing a crash-stop so the probe doesn't take that hit
<linext> i don't want to break my probe off
<gbruno> [github] UBaer21 edited issue #4166 (Fast CSG render without Preview missing face from quad) https://github.com/openscad/openscad/issues/4166
LordOfBikes has quit [Ping timeout: 240 seconds]
LordOfBikes has joined #openscad
use-value has quit [Ping timeout: 250 seconds]
use-value has joined #openscad
myosotis has quit [Quit: myosotis]
J2249 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
myosotis has joined #openscad
use-value1 has joined #openscad
use-value has quit [Ping timeout: 268 seconds]
use-value1 is now known as use-value
gunnbr has quit [Read error: Connection reset by peer]
gunnbr has joined #openscad
qeed has quit [Quit: qeed]
voxpelli has quit [Read error: Connection reset by peer]
voxpelli has joined #openscad
snakedGT is now known as snaked
myosotis has quit [Ping timeout: 256 seconds]
qeed has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
nq has quit [Quit: Leaving]
lastrodamo has joined #openscad
zauberfisch has quit [Quit: No Ping reply in 180 seconds.]
zauberfisch has joined #openscad
<gbruno> [github] MichaelPFrey assigned issue #4144 (brackets in comments are parsed for collapsible block) https://github.com/openscad/openscad/issues/4144
SadE54 has joined #openscad
<SadE54> Hi , i starting to play with openscad , but I'm stuck at exporting my simple objects to stl (Get No top level geometry to render ) . I can F5 + F6 🤔
<J2249> SadE54  so after F6 you see an object?
J2249 is now known as J22
<J22> btw use 3mf for export it is much smaller
<J22> maybe you can !paste your code
<J22> paste!
<J22> SadE54  sounds it might be 2D  and  stl (or 3mf) are 3D
<J22> or maybe you used `%`
<SadE54> here's the code :
<SadE54> height = 20;
<SadE54> Points = [[0,1,0], //P1
<SadE54>           [0, 0.5, height], //P2
<SadE54>           [20, 0.5, 20 + height], //P3
<SadE54>           [20, 1, 0], //P4
<SadE54>           [0 , -1, 0], //P5
<SadE54>           [0, -0.5, height], //P6
<SadE54>           [20, -0.5, 20 + height], //P7
<SadE54>           [20, -1, 0]]; //P8
<SadE54> Faces = [ [0,3,7,4], //BOTTOM
<SadE54>             [0,3,2,1], //FRONT
<SadE54>             [4,7,6,5], //REAR
<SadE54>             [1,2,6,5], //UP
<SadE54>             [0,1,5,4], //LEFT SIDE
<SadE54>             [3,7,6,2]]; // RIGHT SIDE
<SadE54> union(){
<SadE54>     for (i = [0:1:4]){
<SadE54>         rotate ([0,0,i*90])
<J22> (use bpa.st to paste the code and  copy the paste link here )
<SadE54> oops sorry for the wrong placed paste !
<SadE54> I tried again , and it seems I get the warning at the F6 step
<J22> ok i see  so this is i bit tricky
<J22> your geometry has  fliped faces  .. so the order of the face is in the wrong direction
<J22> so the inside is outside
<J22> you can see this with F12  and then F5
<J22> the pink faces are causing the problem
<SadE54> i tried to define faces in CCW order but it's not enough ?
<J22> for CCW order you still need consider the direction
<SadE54> ok thanks , I guess I have to go deeper to understand how faces direction are working :)
<J22> just use F12  ..    the faces rely on the points so if you change the point order the faces will also flip
<J22> (there are some tools in libraries to help)
<J22> SadE54  here https://pasteboard.co/OnLbKUHOTPhy.png as example
<SadE54> thanks you very much for the help !
<SadE54> what tool did you used to see direction ?
<J22> it is an update for the UB.scad  library    module Points(points=Points, mark=Faces[2],hull=false);
<SadE54> 👌
af has quit [Quit: WeeChat 3.4]
af has joined #openscad
<InPhase> SadE54: See the description of the "right-hand rule" here: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#polyhedron
<InPhase> SadE54: It is understandably tricky to keep track of ordering in a 3D space where the faces are on all sides of an object. But it really helps sometimes to be able to hold your right hand out in front of you, orient it to the face you're considering while visualizing (or looking at) the model, and use that as a guide.
<InPhase> I added that right-hand rule to the manual 2 years based on how keeping track of the same sort of problem is done in physics. It has worked successfully there since the late 1800s. :)
toulene has quit [Ping timeout: 272 seconds]
toulene has joined #openscad
Guest7280 has joined #openscad
Guest7280 has quit [Client Quit]
Guest721 has joined #openscad
Guest721 has quit [Client Quit]
<gbruno> [github] t-paul closed issue #4144 (brackets in comments are parsed for collapsible block) https://github.com/openscad/openscad/issues/4144
<gbruno> [github] t-paul pushed 1 modifications (Merge pull request #4168 from MichaelPFrey/mfr-fold only process syntactically relevant brackets for folding (fixes #4144)) https://github.com/openscad/openscad/commit/3bff4cb2f3ae25edca0a4babe94d4ac0ad28b358
<gbruno> [github] t-paul pushed 2 additions 4 modifications (Merge pull request #4167 from MichaelPFrey/mfr-2022-03-09 Adding support for gradient backgrounds.) https://github.com/openscad/openscad/commit/3576d5a9903442f8fdf88aaa204cc1b3c98a311d
<teepee> peepsalot: oh, looks like those merged did cause conflicts again. looks like we may want to go ahead with the moves soon-ish :)
<teepee> looks good from my side, it's a huge improvement and if we find some extra changes, we can do that whenever needed
<teepee> so I'd say it's better to move forward with the current setup preventing potential conflicts with every new PR coming in
<OlivierChafik[m]> yes, the earlier the big bang move happens the better :-)
<OlivierChafik[m]> Btw, slightly improved (+ fixed) the auto completion in https://ochafik.com/openscad (e.g. completes files in use/include statements)
<teepee> cool
<teepee> that feature is in the native editor too, but it's unfortunately quite tricky
<OlivierChafik[m]> (won't tough the autocomplete again until I'm ready to get proper parser)
<teepee> so we may end up with better code completion in the web editor :)
<OlivierChafik[m]> yes I saw that, so cool!
<OlivierChafik[m]> hah, not there yet. Also, need a fast visualizer
<teepee> maybe we should check if that could be provided by openscad directly
<OlivierChafik[m]> absolutely, I was just thinking exporting the AST as JSON
<teepee> there's the LSP PR which at some point would serve a similar purpose
<OlivierChafik[m]> or provide the lexer context as a library, if we build OpenSCAD as a library
<teepee> and mabe there's a way to not just run wasm openscad via main, but call the features
<OlivierChafik[m]> LSP?
<teepee> language server protocol
<OlivierChafik[m]> ooooh yeah that would be grand
<OlivierChafik[m]> although tbh I think we can get quite far w/ good regexps for now
<teepee> yeah, I assume that even may be needed for a good result
<teepee> as AST means basically error free parsing
<OlivierChafik[m]> Amazing! Wonder how that will plug w/ the inbrowser monaco, but I assume well
<teepee> in theory, it monaco would support that, it would be ideal, as it would hand over all the processing into actual openscad calls
<teepee> and at some point it would be same for other editors like vscode, and hopefully (for me) also NetBeans :)
<OlivierChafik[m]> yeah what I've started doing is 1) remove all comments 2) parse N=, function N, module N and add N to the list of autocompletes. Next will be to parse dummy lists of parameters
<OlivierChafik[m]> (and I'm detecting statement context to provide module snippets vs. expression contexts for vars & functions)
<teepee> I'm thinking a combination of AST based parsing (e.g. for imported libraries that are expected to compile without errors) and more relaxed stuff for the current editor would be ideal
<teepee> but of course it's also the most messy solution :D
<teepee> I'm not sure how LSP works regarding imported files though
<teepee> buf if the logic ends up there, it would work for everyone and every editor supporting LSP
<OlivierChafik[m]> yeah... for completion we really don't need more than regexps tbh. For code outlines, context breadcrumps and refactorings, that's another matter
<teepee> removing the need for all those special implementation
<OlivierChafik[m]> (mmh ok I'll also need some micro parser to get the function/module parameters right, since they can have nested default value expressions; e.g I wanna parse `module Foo(x=[1, 2], y)` --> `Foo: [x, y]`
myosotis has joined #openscad
<OlivierChafik[m]> but yeah whatever we have needs to handle partial inputs, and a single solution seems easier to maintain
<OlivierChafik[m]> anyway, just wanted to pop by to say hi, off I go / have a great day all!
* teepee waves
pa has quit [Ping timeout: 250 seconds]
pah has joined #openscad
<gbruno> [github] thehans pushed 304 additions 13 modifications 304 removals (Merge pull request #4161 from thehans/organize_src Organize source tree.) https://github.com/openscad/openscad/commit/3b6312b819d29df4329ec187b3f936ea3af21277
<peepsalot> teepee: yeah seems that it always marks conflicts for the branch that moved things, but they are trivially resolved with a git pull and no manual changes needed
<teepee> yep, I've seen that a number of times, that local git can resolve cases that github flags as conflict
Guest4451 has joined #openscad
<Guest4451> Hi everyone! OpenSCAD beginner here. I was trying to make something that I thought was pretty trivial, but I kinda got stuck pretty quickly. What I want to draw is a ring that has a gap on one end. Something like this: https://snipboard.io/Fe2Ihy.jpg
<Guest4451> This is easy of course: difference a smaller cylinder from a larger cylinder and then difference a rectangle on the edge. Thing is... I also want to round the edges of the gap. And this... appears to be a bit harder than I expected =/
<Guest4451> I tried using minkowski, but that ruins all the dimensions of the model (the diameters are pretty crucial). I thought about using hull() or polygon() in combination with linear_extrude, but I fail to see get something  working. Anyone got some pointers for me?
<Guest4451> (I also had a look at the Round Everything library, which looks super awesome, but I have no clue where to begin to utilize it for my purpose)
<teepee> I guess my approach would be rotate_extrude of a circle + 2 spheres placed at the ends
<teepee> what's the specification of the gap?
ferdna has joined #openscad
<Guest4451> That appears to be the easiest method indeed. I tried replacing circle with cuboid, but it doesn't seem to work. Any idea what I might be doing wrong?
<Guest4451> rotate_extrude(angle = 360 - gap_a) translate([hole_d / 2, 0]) cube(clamp_t);
<Guest4451> (It's not drawing anything)
<peepsalot> rotate_extrude only takes 2D inputs
<teepee> yep, so square() instead of cube()
<Guest4451> that makes a lot of sense!
<teepee> also you probably want square(center = true), with the default alignment the result could be a bit confusing
<Guest4451> Yep! Thanks! After changing the sphere's to cylinders I got exactly what I needed! Thanks a lot you both!
<Guest4451> I was about to ask "But how would I do it with polygons?" (Because I also want to learn the hard way. Because I can imagine that not all shapes can be made with a circular extrude)
<Guest4451> But... I found this: https://www.thingiverse.com/thing:5186085/files
<Guest4451> It's exactly the same thing as I'm trying to make, and it uses polygon. So Imma investigate and check how it works before bothering you guys :)
<othx> Guest4451 linked to "arc() Module for OpenSCAD by SavageRodent" on thingiverse => 1 IRC mentions
<myosotis> I made some C-clips for my wife to attach some plastic to metal poles that look super similar to that but with rounded ends
<Guest4451> Well, that's exactly what I'm making :)
<myosotis> https://pastebin.com/UdGg3YGU in case you like it
<Guest4451> For a different purpose though. These will be placed on some kind of foot, to clip testtubes in. 2 on each testtube so it can not roll away. Then I hope to model some kind of "snap" interface on the feet so multiple of these clips can be snapped together to form a row or clips.
<Guest4451> Thanks for the code mysotis! I will have a look for inspiration :)
<myosotis> np, I made the params configurable, since I had to go through a bunch of test prints before I got one working
<myosotis> the high $fn value was important for my purpose. the sharp edges were hard on the plastic sheeting and kept tearing it
<Guest4451> Same, my model will also have to be very parametrisable. Because there's a variety of sizes in testtubes.
<myosotis> well the idea works fine for what I used it for. PLA maintains it's strength long enough for about 1 season, but definitely won't hold tight forever
Guest4451 is now known as Opifex
<Opifex> I usually use ABS, but It's not as if these clips will be under much stress. I think the hardest part will be to find the right thickness of the clip, so it is flexible but still rigid enough to keep everything from coming loose.
<InPhase> myosotis: PLA is very long-lasting as long as it's made a little bit thick.
<InPhase> It's low infill thin parts that tend to get deformation damage, with the exact threshold needed for longevity being somewhat of a function of the forces involved.
<Opifex> It really depends on brand. There can be huge differences between two spools of PLA.
<Opifex> I have PLA that has been exposed to moisture and sun for years and is still good. But I also have PLA that has become unprintable after been on the printer for just a week due to it becoming fragile as eggshells.
<InPhase> I have PLA parts under mechanical strain that have lasted 6 years by now. I have no reason to expect they won't last a decade or more.
<myosotis> yeah, I found a thickness that made the clips last just long enough to be useful, but still be grippy and flexible. They served their purpose :)
<myosotis> So just to get you started Opifex, the Thickness / Width of the c-clips I shared lasted outside for about 6 months before they wouldn't hold well any more.
<myosotis> using PLA
<Opifex> Mine will be used indoors with minimal sunlight shining on it.
<InPhase> If they need to be a little flexible to be put on, then PLA is probably the wrong choice. Try PETG for that. It's not that it's "stronger", but that it will flex more forgivingly.
<Opifex> And a failure isn't necessarily disastrous.
<Opifex> And they'll be ABS, so I'm not worrying :)
<Opifex> Good point by InPhase indeed. So another reason to use ABS in my case.
<Opifex> But still, I think PLA is perfectly fine here. Since it doesn't have to flex that far and often.
<myosotis> I only had pla at the time. this was a successful money saving operating. it was fine =)
<InPhase> PETG allegedly becomes brittle under long term UV exposure, which could be an issue for long term outdoor applications that need to flex, especially with thinner parts.
<InPhase> But the nice thing about PETG is that it's mostly the properties of ABS, but prints easily like PLA.
<myosotis> but I totally like that my stupid 10 minute greenhouse project sparked an entire convo about what materials I should have used.
<myosotis> I did print a thin pla shower rod holder that's been holding up to the water for about a year so far just fine
<myosotis> I thought it would have fallen apart and made me re-design it by now.
<Opifex> I think there should be some kind of law that states that any conversation remotely related to 3D printing will eventually lead to a debate about PLA vs ABS/PETG :)
<Opifex> Similar to Mac&PC
<Opifex> Something like Godwin's Law
<InPhase> Well, I think ultimately the printing hobby and practicalities require a stockpile of a few different material types.
<InPhase> I keep a large stockpile of PLA for color variety, a small number of PETG colors, a transparent filament, and I think I currently have one flexible TPU roll.
<InPhase> PETG I mostly do black and white, since I can usually make one of those work when I need a PETG solution.
<InPhase> TPU I only have in blue, as I used it for a lot of child toys, and never made it through the first roll.
<myosotis> I have 1 roll of black pla
<myosotis> I mostly just make utility parts and prototyping stuff on it
<InPhase> Oh, and I have one roll of glow-in-the-dark PLA as well, mostly for child toys, but I ended up using it for a few extras, like a glow-in-the-dark cap for a small LED lantern I assembled.
<InPhase> I've probably put $500 into filament across 6 years of printing, but I've printed probably only about a third of that amount of filament.
<InPhase> Per year I suppose that's not too much money for a hobby with practical utility.
<J22> Opifex  https://pasteboard.co/STeOO1Ssz6nc.png   the Cring()  module from ub.scad
<myosotis> I'm definitely ahead on filament cost vs saved money, but probably still a few bucks behind if I include the price of the printer
<InPhase> I probably saved much more money than that just on things that otherwise could have used contractors to solve.
<Opifex> J22: Damn, should have known that before! :D
<Opifex> Looks like exactly what I was looking for indeed.
<Opifex> But I'm going to try and do it the hard way. Because I want to learn how to use polygon properly.
<myosotis> fancy, I skipped beveling the outside edges. it was my next step if the clips kept eating the plastic sheeting
<InPhase> That's a simple enough part that a sphere minkowski will work adequately fast.
<myosotis> this was my second openscad project after I'd had my 3d printer for about 1 week.
<myosotis> the closest to building a 3d model I'd ever come before this, was opening blender, getting confused, and closing it again.
<J22> if you rotate_extrude  a square with offset(2)  ..   rotate_extrude(angle=220)translate([20,0])offset(2)square([2,10]);
<peepsalot> Opifex: here is a version with a single polygon and 4 arc() function calls (using my own arc function): https://bpa.st/DKVQ
<Opifex> Thanks! Imma have to study a bit before I understand how that works though :)
<myosotis> lmao, I should have just pasted my c-clip in here and said "This is the greatest model ever with no room for improvement"
<InPhase> myosotis: https://xkcd.com/356/
<myosotis> there's always a relevant xkcd
<myosotis> not quite this time, but this one seems the closest to cuningham's law: https://xkcd.com/386/
<Opifex> Now I wonder what the equivalent resistance is...
<J22> Opifex  offset(2)polygon([
<J22> for(i=[0:5:220])15*[sin(i),cos(i)],
<J22> for(i=[220:-5:0])14*[sin(i),cos(i)],
<J22> ]);
<myosotis> I made it far enough into my electrical engineering education to be able to find the answer, and to not care
<J22> resistance is futile!
<Opifex> After you graduate, all things you found boring in your classes will become super interesting.
<Opifex> I used to hate math in uni. But now... I never use math. So whenever I get to rewrite some kind of formula, I'm super excited :)
<myosotis> oh no, I do system architecture for web-ish projects right now
<myosotis> I just tinker as a hobby.
<Opifex> I'm currently doing software integrations for wireless gateways
<myosotis> I'm fascinated by the intersection between the real world and the digital world. and I'm confused that more hardware hackers don't write any code, and more coders don't do anything with hardware
<Opifex> That's why my field is Embedded software :D
<Opifex> btw. a more on-topic question: is there an easy way to make snap-connectors in OpenSCAD? Or will I have to draw them from cratch?
Virindi has quit [*.net *.split]
drfff has quit [*.net *.split]
ccox_ has quit [*.net *.split]
ubitux has quit [*.net *.split]
hiredman has quit [*.net *.split]
<J22> Opifex what is a snap-connector?   like a ratched?
<myosotis> I'm thinking something like https://www.thingiverse.com/thing:1818594 is what we're going for
<othx> myosotis linked to "OpenSCAD library: simple pin and block snap connector by Bushmills" on thingiverse => 1 IRC mentions
<myosotis> since he wants a C clip to hold things, I bet he wants to snap them into a vertical hanging grid or something
<J22> Pin()  (from ub.scad)
<myosotis> wtf
<Opifex> Sorry, I'm not a native speaker so I don't really know what to call it.
<Opifex> For example these things: https://www.thingiverse.com/thing:1673421
<Opifex> There's a male and a female side that allows two parts to be attached to each other.
<othx> Opifex linked to "Test tube connectors for Modular Ant Formicarium by onasiis" on thingiverse => 1 IRC mentions
<myosotis> how long have these libs been a part of openscad?
Virindi has joined #openscad
drfff has joined #openscad
ubitux has joined #openscad
ccox_ has joined #openscad
hiredman has joined #openscad
<Opifex> I don't think that's what I'm looking for
<J22> ah  like a dovetail?
<Opifex> A dovetail would be an example, yes. But there's many more solutions. I just don't know if there's an easy way to go in OpenSCAD. Like a library that already does this or smt.
<myosotis> that BOSL library will easily create dovetails for you
<Opifex> Oh, I am using BOSL2 already! Maybe I should indeed use the dovetail :))
<Opifex> Instead of making it too hard on myself.
<myosotis> you can boolean those objects with existing parts to "attach" them or create the cutouts
<myosotis> yeah man, if you're already using that lib, I'd def at least see if their dovetails will work for you
<myosotis> the best solution is the one that will let you move on to the next problem the quickest
KimK has quit [Ping timeout: 240 seconds]
pah is now known as pa
<J22> you use  a  sphere and  a  difference with a bigger sphere
<Opifex> thanks for the great suggestion!
<Opifex> It even includes a "spacing" parameter if I understand correctly. Which is impervious when 3d printing
<Opifex> (Wait, I thing impervious was not the word I meant. I meant essential)
<J22> offset(-1)offset(1) {
<J22> translate([0,-6])square([1,12],center=true);
<J22> circle(2);
<J22> }
SadE54 has quit [Quit: Client closed]
<J22> and the female is just a square where you remove that with another offset
<Opifex> Oh, wow! That looks great too!
<Opifex> imma try to draw that once I got this version printing.
<Opifex> This is what I came up with:
<Opifex> Gonna print this as a first prototype :)
<myosotis> i I understand this right
<myosotis> those tabs are mounted vertically?
<myosotis> can you design it so they're rotated 90 degrees and work with gravity?
<Opifex> yes, but they will be on a flat surface. Not mounted on the ceiling.
<Opifex> Ideally I can just press another one in it, without picking up the existing chain.
<Opifex> So I made the connector vertical intentionally.
<Opifex> One thing I only just realized is that the "extra" parameter of this module doesn't do what I thought it did. I assumed that it allowed for some extra clearance between the dovetails. But it's only a lengthwise stretch.
<Opifex> That doesn't make it very useful for 3D printing...
<myosotis> you can always scale the part afterwards
<Opifex> True I guess... but that feels kinda hacky
LordOfBikes has quit [Remote host closed the connection]
<InPhase> myosotis: There. A 20-second render perfectly smooth C-clamp. https://i.imgur.com/evfEJDq.png https://bpa.st/JDRQ
<InPhase> Consider the problem successfully overthought.
<myosotis> what's hacky about it? all 3d modelling is fake
<myosotis> InPhase, that's one sexy clamp. thanks for overengineering this
<InPhase> I also made the brute-force equivalent C-clamp, but that took the latest release 44 minutes to render: $fa=1; $fs=0.4; minkowski() { sphere(5); linear_extrude(height=30) projection() rotate_extrude(angle=250) translate([30,0,0]) square(0.01); }
<InPhase> Sometimes the 44 minute solution is a better solution, as long as you never have to change it. :)
<InPhase> But I find myself needing to change nearly everything I make.
<myosotis> my original c-clip takes < 1 sec to render on my laptop
<InPhase> Yeah, it really goes up the smoother you make things with the traditional approaches.
<myosotis> I mean the original was already past the resolution of the printer I'm using lol. like I said, the older I get the more pragmatic I become
<InPhase> That 20 second version has 1.2 million facets.
<InPhase> I could have driven down the facet count by adding in a special routine to put more steps in the edge and fewer in the arc sweep, but since it was down to 20 seconds, it wasn't worth it at that point. That would have been overengineering the overengineering. :)
<myosotis> lol it's less than a square inch
<InPhase> But... It looks pretty.
<InPhase> And you could make a giant one. :)
<InPhase> Put the giant one on a shelf, and stare at it and stuff.
<myosotis> my cat would roll it onto my head while I slept. I swear they're plotting something
<J22> InPhase if you try to print that axial (for strength) you want a little flat cut to sit on
<InPhase> J22: Yeah, although it will usually work itself out with a rounded bottom.
<InPhase> You just put down a little bit of gluestick glue, and it will hold.
<J22> and squeeze the first layer .. with 200% flow - Ü
<InPhase> That way you don't have to put any conceptual impurities into your beautiful rounded model. :)
<J22> right is it not the math fault if the printer is not able to print this proper
<InPhase> *thumbsup*
LordOfBikes has joined #openscad
<gbruno> [github] ochafik opened issue #4169 (lazyunion-difference-for.scad test actually fails? (wrong expectation)) https://github.com/openscad/openscad/issues/4169
ur5us has joined #openscad
myosotis has quit [Quit: myosotis]
ur5us has quit [Quit: Leaving]
<Opifex> Let's say you had to build a gearbox, or something with a lot of gears and mechanical parts. What library would you use?
<Opifex> Last time I used BOSL2, but there's several other libs. I don't know which one is best.
<J22> depends on what you need ..   also there are different  standards  like some use "module" for the size
<Opifex> I think modul is the most industry standard of working with gears, so I'd say libraries that use that are at an advantage.
<Opifex> But I'm very open minded here. And the question is also project-agnostic.
<Opifex> I'm just curious what libs you guys use for making gears.
<J22> i developed my own for cycloidal gears that can be combined without being configured as pairs
<Opifex> Interesting! Is it on Github? Or is it closed source?
<J22> libraries!
<J22> else i like this one https://www.thingiverse.com/thing:1604369 for evolute gears
<othx> J22 linked to "Getriebe Bibliothek für OpenSCAD / Gears Library for OpenSCAD by janssen86" on thingiverse => 3 IRC mentions
<J22> ub.scad can be found here http://openscad.org/libraries.html
<Opifex> oh, you created ub.scad?
<J22> yes
<Opifex> Hats off to you! :)
<J22> thanks ( but i think BOSL2 is more professional ) however it fit my needs
<Opifex> For gears? Or in general as a library
<Opifex> ?
<J22> in general
<Opifex> I haven't used UB yet, but I can agree that BOSL2 is very professional.
<Opifex> Ah, ok. I will try your lib for gears :)
<J22> keep in mind that cycloidal gears work a little different to involute gears  (which are a special case of cycloids)
<Opifex> Mhmmm, looks like my OpenSCAD is struggling rendering the gears example.
<Opifex> Btw. is there any documentation? Because that's a big plus for BOSL. It has great docs.
<J22> if you call the module with (help=true);  it will show all settings in the console
<J22> but there is not that detailed documentation and wiki like you have for BOSL (at least for now)
<J22> however i am happy to help
<J22> opifex what error did you get?
<Opifex> Aha, that help=true parameter is very neat!
<Opifex> I'm not getting an error (lots of warnings though). It's just that the preview becomes incredibly slow.
<Opifex> Can barely rotate or look around
<J22> use ! to enable just one object
<J22> gears have a lot of  vertices
<J22> there is a switch so the gear is only displayed as cylinder .. to make it easier to navigate
<J22> perview=false
<Opifex> using ! makes it go a lot smoother indeed.
<Opifex> I had already tried setting fn to 30, but it didn't make a difference
<J22> the gear has its own fn  which is the fragments per tooth  (24 for preview)  so 30 should make it worse
<Opifex> Could I lower it to 10? Or will the library override it?
<J22> you can set it to 5  .. just put fn=5  in the module call
<J22> but don't render with that as the resulting gear will not have the geometry
<J22> cycloidal teeth need more  vertices as the are not a curve but more like an S
<Opifex> It doesn't appear to change anything
<Opifex> But nevermind. It works just fine by checking them one-by-one.
<Opifex> Would you say cycloidal gears are better suited for 3d printed gears?
<J22> https://pasteboard.co/99dm26Qt8Cvq.png   here difference between  5 and 24
<J22> cycloidal gears are very difficult to make without 3d printing - which is why they are not used (except in clocks)
<Opifex> Yes, I read that. And I can imagine a curved surface requires some very specialized tooling.
<Opifex> But since I'm printing them anyways, this is not an issue. So I wonder, do you think these have an advantage over involute gears? (Because I read that involute gears have a lot off stress in a single point of the teeth, while with cycloidal this is more spread)
<J22> you just can not mill  or mould them which makes them expensive in mass production
<J22> involute are more forgiving for misalignment   but  if you have them set proper i think they running better .. but 3d printing is not that super surface finish so for small gears you will not experience  a big difference .. for bigger teeth maybe
<J22> a very big advantage is that they make great pumps
<Opifex> Mhmmmm, okay. I think I'll stick with involute for now. It sounds like it's the safest bet.
<J22> probably Ü
<J22> another big advantage of cycloid gears is that they role and don't need grease  - so they can be used in dusty environments
<Junxter> i use iterative re-mash to help design with lots of gears
ferdna has quit [Quit: Leaving]
la1yv has quit [Ping timeout: 250 seconds]
la1yv has joined #openscad
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
gunnbr has quit [Quit: Leaving]
myosotis has joined #openscad
Xeha has quit [Ping timeout: 240 seconds]