<othx>
ccox linked to "Concentric Shapes by ccox" on thingiverse => 1 IRC mentions
<InPhase>
ccox: Aye, similar.
<InPhase>
lf94: There you go, the one I was waiting to see you attempt is up. :)
<InPhase>
lf94: My interest is because I'm confident there is a very efficient sdf representation for that, but I'm not sure if the curv language has the syntax for it. And it sounds like it might be very inefficient done by brute force.
ciphersalad is now known as fling
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
rvt has quit [Ping timeout: 256 seconds]
rvt has joined #openscad
LordOfBikes has quit [Ping timeout: 252 seconds]
LordOfBikes has joined #openscad
<JakeSays>
is there a way to keep the tabs but close the editor?//////
<InPhase>
You can hide the editor, then unhide it when you want to change tabs.
<lf94>
Checking
<InPhase>
JakeSays: Also, ctrl-Tab still changes between tabs while it's hidden.
<InPhase>
Although you're flying a little blind. Only the title bar changes, and I can't guarantee the title bar even exists properly on all platforms.
<InPhase>
But it works for me in a test, ctrl-tab and then previewing again switches it up.
<lf94>
It's just a star lol
<lf94>
Why is this bad for openscad?
<lf94>
Or curv
<InPhase>
It's easy in OpenSCAD.
<lf94>
SDF could be `star >> onion`
<lf94>
And take a intersection
<InPhase>
It's the equivalent of 90 boxes if you try to assemble it in pieces though, so it will overflow the limit you provided earlier.
<InPhase>
But, they happen to be rhythmic pieces.
<InPhase>
(I'm ignoring the rounded tips because I anticipate you will choose to ignore the rounded tips. But bonus points to you if you can get those as well.)
<JakeSays>
i'd really like the tabs to remain w/o the editor
<JakeSays>
i'd also like to have a preview view for each open document
<InPhase>
JakeSays: Oh, if you want multiple preview windows, just open another copy of OpenSCAD.
<InPhase>
I routinely keep many copies open.
<InPhase>
Tabs are actually weaker, because previewing or rendering one can lock out the other one.
<JakeSays>
i dont want more than one open.
<JakeSays>
what do you mean, lock out the other
<lf94>
Oh you make it with 90 boxes in openscad. Yeah no, I would not do that in curv. This is easily expressed as an SDF shape.
<InPhase>
JakeSays: Well when you preview or render something that takes a while, each OpenSCAD process can do nothing else useful during this time.
<InPhase>
JakeSays: So I use external editors, each attached to its own OpenSCAD process.
<JakeSays>
sounds like there's a lot of global state going on
<JakeSays>
is that a limitation of one of the libraries, or is that by design?
ferdna has joined #openscad
ochafik has joined #openscad
<lf94>
teepee change day 2 so everything in printable lol
ochafik has quit [Ping timeout: 252 seconds]
<InPhase>
Day 24 might be printable with enough tiny stepper motors...
<InPhase>
Day 22 though... lol. Not only is day 22 probably not printable, I am anticipating "<lf94> I give up..." :)
Jack2136 has joined #openscad
Jack21 has quit [Ping timeout: 256 seconds]
<JakeSays>
is there a reason behind the calendar days appearing in an irregular sequence?
<lf94>
It's like a real advent calendar.
<JakeSays>
i'm not familiar with the layout of an advent calendar
<lf94>
It's random lol
ur5us has quit [Ping timeout: 252 seconds]
<InPhase>
Oh. I had never seen a randomized advent calendar before. But when I search, I do see some 1/4th of them appear to have randomized dates with the 24th larger.
<InPhase>
I thought teepee was just being edgy. ;)
linext has quit [Remote host closed the connection]
linext has joined #openscad
Colt has quit [Remote host closed the connection]
NoGare[m] has quit [Ping timeout: 260 seconds]
Colt has joined #openscad
NoGare[m] has joined #openscad
stefanct has quit [*.net *.split]
Cadair has quit [*.net *.split]
Azelphur has quit [*.net *.split]
fardog has quit [*.net *.split]
Azelphur has joined #openscad
stefanct has joined #openscad
fardog has joined #openscad
Cadair has joined #openscad
_whitelogger has joined #openscad
t-paul[m] has joined #openscad
ferdna has quit [Quit: Leaving]
PovilasCNC has joined #openscad
ccox has quit [Ping timeout: 252 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
ccox has joined #openscad
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
<Jack2136>
JaskeSays It is funny how everybody is in his bubble of "known reality" I just had another person asking why the days are jumbled - And it is a totally valid question - but for me (my childhood experience) you had little presents each day and searching for the correct number to open was half the fun.
Jack2136 is now known as Jack21
<Jack21>
This year i got a big box with over 24 paperbags and i have to search for the one i am allowed to open - as they contain parts in a certain order to build something (some years ago i had a PCB to solder and each day a few components .. a resistor a led ..)
GNUmoon has joined #openscad
<teepee>
yes, random as in suggested by a run of: seq 1 24 | shuf
<teepee>
Jack21: I've synced the designs
<Jack21>
teepee thanks .. i make little changes when i see room for improvement so at least they are fine when we make the rep public (also the non linked extra files in there )
ur5us has joined #openscad
<teepee>
maybe not too many changes for already open doors :)
<Jack21>
ill try - and only if something needs a fix
ur5us has quit [Ping timeout: 252 seconds]
<teepee>
yeah, I think that's fine
lastrodamo has joined #openscad
<Jack21>
in the end it always means that insufficient quality was delivered before .. Ü
<Jack21>
so i think №6 is printed
PovilasCNC has quit [Ping timeout: 240 seconds]
PovilasCNC has joined #openscad
<teepee>
insufficient is waaay to strong, imagine how book authors feel after selling the first batch and finding out there's a couple of mistakes :)
<teepee>
I guess they all wish for epaper books to fix issues on one side, but also probably don't want to fix all and any books of the past ;-)
<teepee>
like always the medal has 2 sides or so
<teepee>
the current calendar state is awesome, as proven by the images produced with the scripts
mhroncok has joined #openscad
<Scopeuk>
we've never restricted it to "just printable" goodness knows some of my nonsense from last year wasn't
<Scopeuk>
it would be cool to do a fully printable trinket a day etc sort of thing but the logicstics are chalanging
<Jack21>
or when (software) industry had to get it right before updates over the air or internet - today even your grill is updating its firmware
<Scopeuk>
its been neat so far, and I have a tpu version of day 1 on my desk which has been fun to fiddle with
<Scopeuk>
Jack21 no software is ever completely right, it just has a small list of known defined problems and issues
<Scopeuk>
and I say this working in avionics
<Jack21>
haha i like how MS put it - "we have the best tested software" .. each fix would cause more problems
<Scopeuk>
genuinely some issues fall into the category of fixing them carries a bigger risk of introducing a bigger problem than the risk posed by the issue remaining
<Jack21>
what du you mean with trinket - like batteries included?
<Scopeuk>
it does suggest there is something wrong with the model
<Jack21>
the amf isn't loaded by autodesks software
<veverak>
:/
<veverak>
hmm, thing is, that I do not care so much about "correctness" of the model of the servo
<veverak>
it's purpose is informational
<veverak>
anyway, I have to go play a teacher now, I can try to download the model again (maybe they changed/fixed something?) and than try some tool to fix this
<Jack21>
have a repaired 3mf now .. what should i do with it?
<veverak>
can you get it to me?
<veverak>
I have stuff like email or something
<Jack21>
where to upload?
<Jack21>
322kb
<veverak>
technically you can anywhere, the thing is publicly available model
<Jack21>
let us know if the problem persist .. i assume the amf had issues - intressting though that scad render and export it without errors but produce a faulty geometry
<Jack21>
it is something with the central screw and attached parts
<Scopeuk>
Jack21 I pulled that down and openscad then complained that the geometry wasn't closed,
<Scopeuk>
3d builder was happy to open it and generate and stl that worked however
<Scopeuk>
IIRC when geometry is loaded but no operations are performed openscad just passes the geometry as is to the output engine so it will carry across errors in the base file
<Scopeuk>
as a general rule its only adding a binary operation to the mix that forces it through the internal processing and highlights the issue
<Jack21>
oh yes .. ( i used Microsoft to repair that file - should have known - but i analyzed the geometry and didn't got an error)
<Scopeuk>
its possible its valid 3mf but not a valid manifold model. 3mf is rather expansive
<Jack21>
there are 6 objects (shells) in that file
<Jack21>
InPhase yes that was meant .. so it is not just passed through to export
<InPhase>
The majority of non-manifold complaints are in one of two categories, internal failures from code without difference/union overlap, which we've declared a usage error, or an imported stl file that was never manifold to begin with but then it got blamed on OpenSCAD.
<dalias>
why is fixing bad stl files so hard? :(
<InPhase>
Warning about those solves only the problem of telling the user where to look for the source of the issue, but that's pretty important I think.
<InPhase>
dalias: Incinerating garbage is easy. Recycling 100% of unsorted garbage is challenging.
<Jack21>
we just throwing hull() in those cases - Ü
<InPhase>
"OpenSCAD turned my rabbit into a sphere..."
<dalias>
:)
<InPhase>
"Yes, we only process spherical rabbits. Next customer please!"
<Jack21>
Dear User we are explicitly Sorry but you seem not to be ready for concave geometry
<Scopeuk>
dalias it mostly falls down to having to infer intent from the data presented. so much data is thrown away when and stl is generated, it looks like the input to a human, but that's about it
<InPhase>
Scopeuk: Well it could be done the same way the human does. Remeshing from a visible ray trace. Although one has to assume the object has no hollow features of importance to do this, which some designs do intentionally have. So that assumption cannot be consistently made.
<InPhase>
But perhaps throwing away internal features for non-manifold objects would be a better failure mode than throwing away the whole thing.
<InPhase>
It is a valid assumption that the vast majority of non-manifold imports were not intended to have internal features.
<InPhase>
Usually these just come from software that only cares about the externally visible surfaces, because it wasn't designed for 3D printing.
<Scopeuk>
"your input model was poor, we did our best, it may now be complete garbage, you need to check"
<Scopeuk>
yeh there are a lot of broken models out there derived from video game models etc
<Jack21>
it ONLY looks ok .. sorry
<InPhase>
It would be fair to throw a warning if a repair was made, "WARNING: Non-manifold object from file ... remeshed to visible surfaces"
<Scopeuk>
I would say it's dangerous not to
<Jack21>
without premium account we only process registered geometry
<veverak>
just note: so far I relied on admesh :)
<veverak>
and my Haskell thingy that generates stl from scad generates makefile with step A. openscad it B. admesh it
<Jack21>
copy from a copy ends terrible - i wonder if you have complex geometry and convert this with different software into different formats and loop this .. what would happen
<InPhase>
veverak: Relied on admesh... But what fraction of non-manifold stl imports have you successfully repaired?
<InPhase>
The success rates for most people seem very low.
<InPhase>
If someone has a ritual with high success rates that's important to know.
<Scopeuk>
automatic stl repair is up there with weather prediction in computational complexity :P
<Jack21>
Ü
<veverak>
InPhase: not sure?
<veverak>
this is "automation" part
<veverak>
I made it do so once and did not really check how many times it was necessary
<veverak>
however, at some point htere definetly was a problem with my stl export and admesh did solved it
<veverak>
(there would be no other reason for me to implement this)
<InPhase>
Okay. So a success of at least one. :) That beats zero I guess.
pa has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
pah has joined #openscad
GNUmoon has joined #openscad
<veverak>
Jack21: files still be broken, but I got more time to play with it now
<Jack21>
where did you get an error and on both files ?
<veverak>
ERROR: CGAL error in CGALUtils::applyUnion3D: CGAL ERROR: assertion violation! Expr: itl != it->second.end() File: /build/openscad/stage/usr/include/CGAL/Nef_3/SNC_external_structure.h Line: 1144 with just FIX
<Jack21>
i checked the 2nd and 3rd file with scad and other software .. non showed an error
<veverak>
interesting
<veverak>
so minimize again
<dalias>
scopeuk, the problem i've had is not that the fixing tools do a bad job of inferring intent. it's that they produce output which is still not a manifold >_<
<Scopeuk>
yeh that definitely happens
<dalias>
if it just looked bad i'd accept that an fix it
<Jack21>
21.10.19 is the version i use - also involved CGAL by adding a cube() for render
<dalias>
but i can't do any csg to fix it because it's not a manifold :(
<dalias>
seems like you could do a really dumb "fix" by starting with each triangle as independent and extending solid opposite its normal stopping when you hit any other triangle
<Jack21>
veverak maybe an other stl in your setup is also damaged
<dalias>
like determine the maximal convex body attached to each triangle that's compatible with the remaining triangle set
<dalias>
and then the result is the union of all those convex bodies
<veverak>
Jack21: switched to that version and tried cube too... this is weird
<veverak>
dalias: I can check it eventually, but weird thing is that mergin other stl files into one with union works
<veverak>
damn this
<veverak>
I have to prepare a vid. of moving robot for tomorrow that uses this
<Jack21>
you can try to add some render() so intermediate steps get rendered
<veverak>
it's "replace it with gray box"o'clock
<veverak>
I will solve this later, thanks for help
<veverak>
Jack21: yeah, I can try that
<veverak>
last time I used some other tools to fix meshes, I may try to play with those too
<Jack21>
you are teacher .. just delegate this to your pupils for extra points
<Jack21>
meshlab could work
<veverak>
I teach embedded, not graphics
<veverak>
that means: they allready have enough reasons to hate me
<Jack21>
.oO( have to embed the graphics)
mhroncok has quit [Ping timeout: 240 seconds]
mhroncok has joined #openscad
<lf94>
teepee: feel free to relay my completions to reddit, or whoever is using reddit
<lf94>
and twitter
<Jack21>
like anonymous everybody can use #scadvent
<Jack21>
but it is nothing printed nor SCAD .. so you can past this to r/curv
<Jack21>
nah seems there is no sub
<Jack21>
lf94 you are two days behind - Ü
<JakeSays>
Jack21: an "advent electronics project"? lol that does sound like a lot of fun!
<Jack21>
sure is if you have no clue what you are building
<JakeSays>
definitely
<JakeSays>
i would've loved that as a kid
<Jack21>
.. wait what why is there a 600v mosfet
<teepee>
Jack21: lib3mf version 2.x is just in master now (2.2.0 as of now)
<lf94>
Jack21: two days behind? not really, the code was mostly written, I've just been dealing with some things :p
<lf94>
Are you U?
<Jack21>
I am me
<lf94>
Ü
<lf94>
Or is that supposed to be a big smile face lol.
<Jack21>
teepee ah so we can hope ..
<JakeSays>
lol i've wondered that myself
<Jack21>
Ü ⇐ :)
<teepee>
Jack21: openscad code actually supports it, but it's not available on any platform
snaked has joined #openscad
<Jack21>
teepee i wasn't aware that we had issues with 3mf (only that we don't use all options like color author thumbnail etc)
<teepee>
issues is maybe the wrong word
<teepee>
thing is they completely changed from 1.x to 2.x
<teepee>
and 2.x supports double precision
<Jack21>
sounds good
<teepee>
so it's more like "stuck with old version due to big effort to get new version going"
<Jack21>
but at the moment it stores things as small as nm that should be fine or?
<Jack21>
probably some rounding problems when points get clamped down
<lf94>
The ideal way to do this one is to sketch the hanger
<lf94>
for proper dimensions
<lf94>
For this I just did a smooth union.
<lf94>
InPhase:
<lf94>
Jack21: I did read the code X)
<InPhase>
lf94: Looks good. :)
<lf94>
Even the star itself would be better as a sketch.
<lf94>
Which is essentially what the openscad code does, but sketching with cubes
<lf94>
Neat thing about mine: onion t will create an outline of t thickness. But since it jumps to another isosurface, it's rounding that amount as well
<lf94>
onion 1 will create an outline of thickness 1 but also rounded corners of 1 radius
<lf94>
I need to get Day 5 submitted later too.
<InPhase>
lf94: https://youtu.be/-pdSjBPH3zM?t=2433 This is what I wanted to share with you after you tried Day 6. From this timepoint at 40:30 through about 58:00, where he demonstrates how to get huge numbers of elements without increasing computational time at all. This is one of the serious benefits of sdf design if you can exploit it in your designs.
<othx>
InPhase linked to YouTube video "Live Coding "Greek Temple"" => 1 IRC mentions
<InPhase>
lf94: It could simplify the star design in a pretty straightforward way, but it looks like you already got that one pretty efficient. But if you can figure out a way to be clever with your function design, it should enable the huge number of boxes from day 2 to be super fast.
<ccox>
Zauberfisch: you're welcome, glad I could help.
<InPhase>
lf94: If you haven't seen any of his videos, Inigo Quilez is a certifiable genius at this sort of thing. :)
<lf94>
InPhase: I've been studying IQs stuff for the past couple months X)
<lf94>
I use his star in Day 6
<lf94>
generalized star - there is a specialized 5 point star
<InPhase>
Oh, that's what the IQ in your code was for.
<lf94>
It's quite simple though
<lf94>
Also, there is a tradeoff for "massive amounts of elements without increasing computation time"
<lf94>
symmetry
GNUmoon has joined #openscad
<lf94>
Also, the issue with day 2 is not SDFs, but how Curv generates code.
<lf94>
Day 2 can easily be done in shadertoy with good performance
<lf94>
Doug's working on the shape compiler immediately due to day 2 lol
<lf94>
I could probably do an "infinite" nested star
<lf94>
And then just intersect how many layers I want.
<lf94>
Not in the mood to try and derive that though
<InPhase>
I figure with the right functional form the shape compiler would never even get a pass at it, since there wouldn't be anything to compile. It would be one shape modulo'd a bunch.
<lf94>
Day 2 requires specific placement of cubes
<lf94>
That's the issue
<lf94>
So it will require a union
<lf94>
(a union of a zillion cubes placed at certain places.)
<lf94>
That's why I was at least trying to go a pixelized variant
<lf94>
I could've had a pixelized oval sphere thing
<lf94>
and cut into that
<lf94>
but it's not the same as the actual day 2 result.
<JakeSays>
i think it's funny how many openscad like systems just compile to openscad code
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
<Jack21>
lf94 would that "onion" work on 3D and round the corner of day 1 ?
<lf94>
no :\
<lf94>
the issue is day 1's is not an shfzf
<lf94>
sdf
<lf94>
but a gdf
<Jack21>
gdf ?
<InPhase>
lf94: Well Day 2's has a periodic placement in x, which makes it seem like modulo should work, but the only issue is that they are overlapped. It seems like it should still be calculable though.
mhroncok has quit [Quit: Leaving.]
<lf94>
you're free to try X)
<InPhase>
That would require reading some docs on the mystical syntax of Curv.
<lf94>
No, you can try directly in GLSL
Guest69 has joined #openscad
Guest69 has quit [Client Quit]
<InPhase>
Yeah, that sounds more viable. But some other time. A little loaded up right now.
<Jack21>
do the downloads are tracked on the website .. or visits for the calendar?
<Jack21>
i bet in the end something nice but simple gets more attention as some complex math where only a few understand why a Meatball is so special
lastrodamo has quit [Quit: Leaving]
LordOfBikes has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 240 seconds]
LordOfBikes has joined #openscad
<InPhase>
Jack21: Yeah. My examination of thingiverse stats convinced me it's very tough to predict what will be seen as desireable. :)
<Jack21>
like stock market - it is just a big beauty contest and you have to find out who the other find worthy
<InPhase>
Also, I scanned back in the log to remind myself what that conversation was that led me to make the meatball originally. It was lf94 challenging to make a "metaball", and I thought it would be funny to instead make a meatball.
<Jack21>
more funny on reddit where ppl get thousand upvotes for posting a video of some one printing shit from someone else
<Jack21>
haha .. just checked metaball .. nice
<Jack21>
have you seen my animation this morning .. cuz it was bit like metaballs