<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]>
(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
<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]>
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 .
<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 🤔
<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. :)
<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]>
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!
<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
<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?
<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>
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 :)
<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.
<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?
<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)
<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>
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
<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.