<johnstein>
Hello I'm working through the chapter1 tutorial. I'm a pretty experienced programmer and have done some CAD programming many years ago. I'm primarily using OpenSCAD to create STLs for 3d printing (I've been using tinkercad for basic stuff so far but now I need parametric models). My question is, in chapter 1 it recommends ensuring you always overlap primitives by 0.001 to avoid situations when one object is sitting directly on top of another. is this
<johnstein>
really the best practice? (seems like it should be ok, but it also seems a bit of a hack solution)
teepee has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
ferdna has joined #openscad
josephl has quit [Read error: Connection reset by peer]
raboof has quit [Read error: Connection reset by peer]
<Joel>
ali1234 thanks for sharing!
<JakeSays>
johnstein: it is, unfortunately
<JakeSays>
ali1234: hmm. are the github builds fast?
<ali1234>
not for this repo, no
<ali1234>
it takes like 15 minutes
<JakeSays>
well, faster than your local machine
<ali1234>
but it takes like 3 minutes on my PC
<JakeSays>
oh
<JakeSays>
lol
<ali1234>
github actions VMs are not fast at all
<JakeSays>
not much advantage then
<ali1234>
the advantage is you dont have to upload built files from your dev system. you get a clean build, every time, automatically
<JakeSays>
i don't upload stls anywhere
<JakeSays>
just to my printer
<ali1234>
well people asked me for them
<JakeSays>
well, via slicer
<ali1234>
not everyone has openscad
<ali1234>
but this is a general thing for github actions, not just for openscad. it can build anythng of course
<JakeSays>
i know
<ali1234>
it is just a VM and you can run whatever commands you want on it
<ali1234>
but they are not handing out super fast CPUs for free :)
<ali1234>
even with how slow they are they still had people crypto mining on them
<JakeSays>
i haven't needed to share stls yet, but i think i'd just commit them when i pushed the source
<ali1234>
i think that's bad for a few reasons. it bloats your diffs and your repo, and it obfuscates how to actually build your own stl if you do want to modify the scad
<ali1234>
if you fork my repo and push changes to your fork, my workflow file will build your changes for you. you don't even need openscad :)
<ali1234>
you do have to know where to find them in the UI though
<JakeSays>
nah. ci isn't worth the effort for this.
<ali1234>
i mean, i sometimes have this problem with my own code that i wrote. i forget how to compile it. but with CI i can just check
<ali1234>
even if it has a makefile, there's still dependencies
<ali1234>
CI by definition covers absolutely everything you need to reproduce
<JakeSays>
i understand that
<ali1234>
i don't use CI for everything of course. sometimes i just upload STLs and the scad to thingiverse, if its something simple
<ali1234>
but that 32blit case is not simple, and it is not finished either
raboof has joined #openscad
<JakeSays>
i always automate my builds with scripts locally. all ci would do is invoke a script.
<ali1234>
yeah, that's all mine does. in addition to apt installing openscad in the vm
<ali1234>
and then zipping the result and adding it to the release page
<ali1234>
but the core makefile can be invoked locally if you want
<JakeSays>
to be perfectly honest i don't share a lot of code. it's way too much hassle
<ali1234>
i have never found it to be a hassle. maybe what i share is too esoteric
<johnstein>
JakeSays: thanks. so am I on the right track thinking that if I'm creating some sort of stairstep pyramid with, say, 20 layers of thin cubes with t=10, that if I'm overlapping every layer, the second layer from bottom is offset -0.01 and the top layer will need translated -20 * 0.001 down to account for the translations below?
<JakeSays>
oh i have. people start bitching and demanding things. then i end up having to explain to them what they can do with themselves.
<ali1234>
the trick is to just completely ignore them lol
<ali1234>
johnstein: you don't really need to do the overlap thing on every single object
<ali1234>
it is mainly to avoid z-fighting in the previews
<JakeSays>
johnstein: well, with an epsilon of .001, it'll be quite awhile before you get to the point where it's causing errors
<ali1234>
for inner surfaces you won't see that anyway
<JakeSays>
ali1234: what do you mean when you say inner surfaces
<ali1234>
like if you put two cubes right next to each other. the faces that are touching
<ali1234>
you dont see either face, so epsilon is not required
<ali1234>
they can be in the exact same place, the renderer will figure it out
<JakeSays>
that's not always true. i had issues with two tubes not overlapping inside of a solid block.
<JakeSays>
i was creating tunnels
<JakeSays>
well, wire guides
<ali1234>
yeah, in that case you do see the inner faces, kind of, because it's all reversed
<ali1234>
i assume you were differencing?
<JakeSays>
yes
<ali1234>
johnstein: if you're really paranoid about it, what i'd do is make all the cubes touch the ground and just modify the height of them according to the step
<ali1234>
so you start with a short, wide cube, and end with a very tall thin one
<ali1234>
then they are guaranteed to overlap and you still dont need to worry about epsilon
LordOfBikes has quit [Ping timeout: 260 seconds]
<ali1234>
but basically don't worry about it unless it actually becomes a problem in the end result, or the z-fighting annoys you
<JakeSays>
what is z-fighting
<johnstein>
ali1234: thanks for the tips. I'm not paranoid yet :) but it was a weird caveat to read in the chapter1 tutorial and I wasn't sure what the main issue was
<ali1234>
it's when two triangles are in the exact same place so they flicker because of float imprecision in the depth buffer
<JakeSays>
ah. not sure i've seen that
<johnstein>
if it's just a visual thing I probably won't worry too much. if it's going to result in a malformed STL though, I might decide to care more
<ali1234>
you have certainly seen it if you've ever played basically any 3d video games ever
<JakeSays>
ali1234: well that explains it. i've never played one.
<othx>
ali1234 linked to YouTube video "Z-Fighting" => 1 IRC mentions
<johnstein>
all my stuff will end up in my 3d printer in the end
<JakeSays>
johnstein: it's not just a visual thing. if not careful you'll end up with designs that aren't 'two manifold complete'
<ali1234>
johnstein: slicers will normally do the right thing if there's a tiny gap. if there's geometry where it should be, which is possible, then you might have to start adding offsets. but don't worry about it constantly. it's pretty rare
<JakeSays>
and that can cause issues with slicers
<ali1234>
*shouldn't
<ali1234>
it's something you need to be aware of, which is presumably why they bring it up in chapter one, but it isn't a constant problem in every project
<johnstein>
JakeSays: yea that was the terminology I couldn't remember. I've run into a few models where Cura was complaining. they printed OK though
<JakeSays>
i'm making it hard for doordash drivers to not find my house
<JakeSays>
and i'm proud to say there's not one drop of solder used
josephl has joined #openscad
<peepsalot>
I'm trying to fix the view all calculation for preview. wondering if I should do a separate calculation of bounding box for thrown together mode though?
<peepsalot>
basically is it better for the thrown together view (camera position/zoom) to match that of normal preview, or to actually have all the components within view in thrown together
<peepsalot>
because it basically causes intersection and difference to act as union
<peepsalot>
InPhase: what do you think?
LordOfBikes has quit [Ping timeout: 256 seconds]
paddymahoney has joined #openscad
LordOfBikes has joined #openscad
<InPhase>
peepsalot: So it appears the current system still matches Preview to Thrown Together, even though Preview is the more correct display mode. I guess we agree that's the worst solution.
<InPhase>
peepsalot: I would say the bounding box of the display should match what's display. That's the only logical scenario.
<InPhase>
s/what's display/what's displayed/
<InPhase>
If you ever really wanted to see the one in the view of the other, you can accomplish this by not resetting it between the two. But I think that's a less common workflow than the base case of just seeing what you actually made visible.
<peepsalot>
ok, makes sense. just wanted to get an outside opinion
<InPhase>
Random thought: It would be really nice if it said something like: Compile and preview finished, 2021-11-10, 9:29:41pm
<InPhase>
Why? Because on simple models I am all the time hitting save in my vim window, glancing over at the preview, and it previewed so fast I'm not sure if it actually did it, so I do it three more times to watch the console window flicker the scroll bar to be sure.
<InPhase>
And this is stupid. :)
linext_ has joined #openscad
linext__ has quit [Ping timeout: 264 seconds]
ferdna has quit [Quit: Leaving]
pah_ has joined #openscad
pah has quit [Ping timeout: 250 seconds]
<ccox_>
InPhase - with a timestamp, you'd still preview 3 times until the second changed.
<InPhase>
Well I could look at my watch. Although I might still do that anyway now out of habit. :)
<InPhase>
But at least then I'll know how late it's getting!
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
arebil has joined #openscad
nspuma has quit [Remote host closed the connection]
linext__ has joined #openscad
linext_ has quit [Ping timeout: 250 seconds]
nspuma has joined #openscad
<ccox_>
Eh, add a ticket for it. I just finished my benchmark update and might have time now to dig through the code.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
little_blossom has quit [Quit: little_blossom]
little_blossom has joined #openscad
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
GNUmoon has quit [Ping timeout: 276 seconds]
pah_ has quit [Ping timeout: 240 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 246 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 256 seconds]
pah has joined #openscad
Jack21 has joined #openscad
pah has quit [Ping timeout: 256 seconds]
pah_ has joined #openscad
GNUmoon has joined #openscad
Polsaker has quit [Quit: OH NO OH SHIT WHAT'S HAPPENI-]
Polsaker has joined #openscad
siege has quit [Ping timeout: 260 seconds]
siege has joined #openscad
nspuma has quit [Ping timeout: 250 seconds]
arebil has joined #openscad
whileone[m] has quit [Quit: You have been kicked for being idle]
pah_ is now known as pa
pa has quit [Changing host]
pa has joined #openscad
lastrodamo has joined #openscad
ur5us has quit [Ping timeout: 246 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
pah has joined #openscad
pa has quit [Ping timeout: 260 seconds]
pah has quit [Ping timeout: 256 seconds]
pah_ has joined #openscad
mhroncok has joined #openscad
califax has joined #openscad
pah has joined #openscad
pah_ has quit [Ping timeout: 256 seconds]
pah has quit [Ping timeout: 245 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 240 seconds]
pah_ has joined #openscad
arebil has joined #openscad
pah_ has quit [Ping timeout: 264 seconds]
pah_ has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
pah_ has quit [Ping timeout: 240 seconds]
pah has joined #openscad
<JakeSays>
InPhase: i would prefer to have an actual api exposed that an editor could call to interact with openscad. it'd be a lot more effective than depending on file watching
<teepee>
that's sadly not viable with and allocation of 0.013 developers per day :)
<JakeSays>
teepee: LOL true
splud is now known as n2
n2 is now known as splud
<InPhase>
teepee: A form response laying out the new criteria: https://bpa.st/GIGQ
<InPhase>
teepee: Just received that last night.
<teepee>
looks the same as I posted yesterday, not sure if you saw that
<InPhase>
I did not... Missed that link.
<teepee>
for openscad the extra missing piece is the credit card
<teepee>
no problem, it did not really have much more info anyway
<teepee>
would need someone with that internet credit card thingy :)
<teepee>
I forgot the name unfortunately
<InPhase>
Requesting a credit card sounds inappropriate for open source projects anyway. Although that will not deter us for the work projects I suppose, as we have an organization-level card, which is the appropriate sort of thing to use.
<teepee>
one of those virtual credit cards would be ok too, just have it for one month and then delete the number
<teepee>
no idea if there's such services here in germany
josephl has quit [Ping timeout: 256 seconds]
raboof has quit [Ping timeout: 268 seconds]
josephl has joined #openscad
raboof has joined #openscad
JakeSays has quit [Ping timeout: 260 seconds]
JakeSays has joined #openscad
<JakeSays>
ali1234: hey i was looking at some of your 32blit-case code and noticed in several places that you extrude a square instead of using a cube. why is that?
josephl has quit [Ping timeout: 250 seconds]
raboof has quit [Ping timeout: 250 seconds]
ochafik has joined #openscad
raboof has joined #openscad
ochafik has quit [Ping timeout: 268 seconds]
<ali1234>
JakeSays: probably because i want it centred in x and y but not in z
<ali1234>
or because i want to apply rounding to it in 2d before extruding
<JakeSays>
ali1234: ah ok.
<JakeSays>
ali1234: i also noticed something like offset(4) offset(-4) - what does that accomplish?
<ali1234>
it is a really weird device to program for. it doesn't have graphics acceleration that is useful for games, but the CPU is so fast it can just emulate them. but also the RAM is super limited.
<JakeSays>
it doesn't do much for me as a gaming device, but i see lots of use as a controller
<ali1234>
controller?
<JakeSays>
yeah. for controlling various things
<ali1234>
it doesn't have wireless
<JakeSays>
doesn't need it
<JakeSays>
most embedded controllers aren't wireless
<ali1234>
so like a control panel on a machine?
<JakeSays>
it'd be a decent front end for, say, a bunch of other MCU's
<JakeSays>
yeah
<ali1234>
the only external interface it has is USB
<ali1234>
unless you hack the board
<ali1234>
it can do OTG though so that's nice
<JakeSays>
i'm not familiar with that mcu, but if it were an atsame-e70 it'd have can capabilities, which would be very handy
<ali1234>
one thing i have been working on a lot is multiplayer gaming over a USB link cable
<JakeSays>
*atsam-e70
<ali1234>
the MCU has CAN, but all the pins are used up for other things
<ali1234>
you can't even buy the chip because of shortages
<ali1234>
but yeah it is really stupidly powerful for a microcontroller
<ali1234>
if it had a MMU, it could run a real operating system no problem - as long as it fit in memory
<JakeSays>
so you're not using the graphics accelerator on it?
<ali1234>
nope
<JakeSays>
why not?
<ali1234>
it doesn't actually do anything that we need
<JakeSays>
oh
<ali1234>
the framebuffer does use the DMA and some hardware pixel format conversions, but not the chromart stuff
<ali1234>
that is mainly for compositing multiple different framebuffers together - and there isn;t enough RAM to have multiple framebuffers in this chip
<JakeSays>
right
<ali1234>
so like say you make a control panel and you want to make it have a nice jpeg backdrop. it is ideal for that. but not much use for sprite based games
<ali1234>
it is nothing like sprite accelerators you'd find on SNES etc
<ali1234>
the chip and chromart can actually drive 4K panels i think. but theres no way to have a 4K framebuffer in the chip
<ali1234>
until they make one that has like 16MB RAM
<JakeSays>
you could add external memory
<JakeSays>
iirc the m7 has an external memory controller
<ali1234>
not sure if that is possible. you can have external QSPI flash which you can use to store static images in addition to code
<ali1234>
so you could stream a huge slideshow off that
<JakeSays>
it also has a separate memory controller
<ali1234>
it might not be exposed though. remember there's a limited number of pins on the package. every one has like 8 functions
<JakeSays>
right
<ali1234>
it can't do all these things at the same time
<JakeSays>
i'm just saying the chip supports it
<JakeSays>
like, you'd probably have to offload some other functions to another device to free up pins
<ali1234>
yeah. they are using a close relative chip for a 3d printer controller board. smoothie board i think its called
<ali1234>
that's what it is really meant for. using it in a game device is not the target for this chip, it is only possible because of the CPU clock being so high
<JakeSays>
right. it's a microcontroller, not a gp cpu
SebastianM has quit [Quit: Bye]
califax has quit [Remote host closed the connection]
ali1234 has quit [Remote host closed the connection]
ali1234 has joined #openscad
<Jack21>
did anyone testet that minkowski fillet - not only is convexity missing .. size 1 and 2 are interchaged leaving a huge cube
<teepee>
"that" ?
<InPhase>
Jack21: Make sure to test offset(4) offset(-4) separately from offset(-4) offset(4)
<teepee>
is there one in the tips&tricks page?
<teepee>
ahh, yes, not sure, I think I tried at some point
<teepee>
on cadhub there's another option that might be a bit more sophisticated
<InPhase>
Jack21: Where you get symmetry, is that offset(4) offset(-8) offset(4) gives the same result as offset(-4) offset(8) offset(-4), both of which apply both the inner and outer rounding.
<teepee>
hmpf, where is it?
<Jack21>
the offset_3d (r=-2) leaves a big cube as size 2 is bigger size 1
<InPhase>
Jack21: But then there are cases where the order gives a subtle difference, like this: https://bpa.st/YY5Q
<Jack21>
and the operation for the hole chain is so slow that shouldn't be in "tips"
<Jack21>
inPhase the 2D is fine (i have that in my lib)
<Jack21>
nice but i wouldn't use the Servo as this is only a dummy for cutouts, and the rainbow Ttorus speciality is the twisting < Ttorus(r=2,r2=+0.5,pitch=6,twist=360,angle=720,scale=0.4)R(90)cylinder(.1,d1=2,d2=0,$fn=6); > was this auto generated?