<J1A84>
it is a rotate_extruded part that when in contact with the other rotate_extruded edges and a certain $fs/$fn value forms a straight line
<teepee>
whops, no, not seen that before
<J1A84>
i have no idea why .. the values are beyond "echo" as that only show 3 digits but there are at least 6 but the weird thing is that even without connection it happens but when removing the outer parts not
<J1A84>
to get scale working proper you need to move the part into the center so the cut is at 0 else scale will move your part
<J1A84>
also in your code you scale only x .. that would make that part shorter
<J1A84>
i would assume you need to scale Z and leave the other at 1
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
fling has joined #openscad
<InPhase>
J1A84: https://bpa.st/D3TQ I was failing to reproduce the bug repeatedly, and about to give up, when I tripped over one that reliably produces a bug worse than what you reported.
<InPhase>
J1A84: But here's the thing, it triggers the bug in 2021.01 as well.
<InPhase>
Along with a warning in 2021.01 that's not in master: "WARNING: $fs too small - clamping to 0.010000 in file J1A84.scad, line 2"
<InPhase>
So whatever breaks this has been around for a while.
<J1A84>
worse? looks like the same behavior .. just wonder why you can't reproduce with a union()
<InPhase>
This reproduces even if I raise $fs=0.02 so that warning is unrelated.
<J1A84>
yes because the high $fn is overwriting
<J1A84>
set $fn=0; and the other take over
<J1A84>
i first got the problem due to a low $fa value
<InPhase>
Yeah. I see 3881 is the magic value.
<J1A84>
yes 3880 was fine .. i had a 25 degree but with 140 radius so $fs was 0.20 but $fa was low and caused more fragments .. on a small radius $fs need to be lower to trigger
<InPhase>
Hmm. So implicit top level union doesn't trigger it.
<InPhase>
Explicit union does.
<InPhase>
If I move the cube to the origin.
<J1A84>
it should .. but i have lazy union on so i put a render() around (as the example code in the issue)
<InPhase>
I also have lazy union on.
<InPhase>
Adding a render() triggers it. I think that does the explicit union.
<InPhase>
But the explicit union example is clearer.
<J1A84>
with lazy union you don't have the implicit union at top level (afaik)
<InPhase>
https://bpa.st/RXTQ So this is what I think is the minimal clear example of it.
<InPhase>
That or similar is worthy of going in a github issue.
<J1A84>
that is close to the example code isn't it?
<ali1234>
the funny thing is "touch file" still triggers openscad to reload it, but it is still empty. what?
<ali1234>
this is probably a bug in snapd
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<ali1234>
https://bpa.st/YLSA could someone test this with not-snapped openscad please?
<ali1234>
okay tested it with the deb, still happens...
<ali1234>
gonna open a bug unless someone can explain why my script is wrong
<ali1234>
oh i think i know what the problem is. i am truncating but not seeking to zero, thus the file has loads of zero bytes at the beginning
<ali1234>
nope, that is not it
<ali1234>
ah yes, yes it is
<Scopeuk>
ali1234 is that flush sufficient to trigger a notify?
* Scopeuk
isn't completely familiar with the low level detail of pythons file handeling
<InPhase>
ali1234: That's not a bug. echo "" >> tmp...scad does not zero a file out, it appends a newline to it.
<ali1234>
yes, that's the idea
<ali1234>
in the real script i won't be closing the file, i'll be truncating and writing new contents without closing. which does seem to work
<ali1234>
but the problem is i need to seek(0) after truncating, otherwise each write happens at the previous offset, and you get a sparse file
<ali1234>
yep, adding the seek fixed it :)
<ali1234>
cool. now, is there a way to launch openscad with only the preview (and not the code or log) visible, without changing the global configuration?
<InPhase>
There isn't.
<InPhase>
The command line parameters are all completely separate from the gui config files.
<ali1234>
but it isn't open source so i have not looked at it beyond the home page
<InPhase>
Oh, like that. Well that seems worse to my eyes. :)
<InPhase>
It takes the spaghetti code problem and manifests it quite literally.
<Scopeuk>
with stuff like that encapsulation becomes key to making it inteligable
<Scopeuk>
at the top level you are interested in objects position and orientation, its nice to be able to then drill in (similar to how one uses simulink)
<Scopeuk>
no idea if it supports that sort of design hwover
<teepee>
I think something similar to IceStudio would be a better match with potential of scaling to reasonable project sizes
califax has joined #openscad
<ali1234>
in blender you have groups which is basically defining a node with nodes
<ali1234>
so like a re-usable component, or module
<ali1234>
definitely helps keep it manageable
<ali1234>
although people make crazy stuff without groups anyway
<Scopeuk>
ali1234 yeh that sort of thing, atleast its usually easy to migrate stuff into groups
<ali1234>
the cool thing in blender is that every thing is a group, including the top level
<Scopeuk>
thats fairly standard, I used to do a lot of stuff with vvvv which works in a similar way
<ali1234>
and then the top level inputs you define appear in the blender UI. so like an integrated customizer