Artea has quit [Read error: Connection reset by peer]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
themind has quit [Ping timeout: 252 seconds]
themind has joined #openscad
mmu_man has quit [Ping timeout: 252 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<J24k97>
So SCADvent is comming soon .. maybe we make/add some https://en.wikipedia.org/wiki/Code_golf this year - to get multiple solutions (days) for something
<J24k97>
pca006132 i found flipped faces again (only special conditions) with linear_extrude this time https://imgur.com/a/QQaxSHe
<J24k97>
use<ub.scad> linear_extrude(1,twist=5)rotate(180/16.0)Cycloid(z=16,modul=1.5,fn=8); // change the rotate a little and it is gone (or fn or z)
<InPhase>
Simplified a bit: use<ub.scad> linear_extrude(1) rotate(3) Cycloid(z=16,modul=1.5,fn=8);
<J24k97>
Ü
<J24k97>
probably the "zebra" issue or if points are too close and float causing micro intersections - the created polygon has a path but also without the issue persist
<J24k97>
workaround is an offset(.001) or slightly different rotation
<InPhase>
So are your points actually ordered well inside that Cycloid?
<InPhase>
It has so many options and flow paths it is difficult to even know what part of it is manifesting this shape.
<InPhase>
Maybe you can more quickly than me extract out the points in use, and make a testcase which is independent of it?
<InPhase>
Like if it were a single polygon call on a functional form, or even just a polygon call on a list of points, that would be good.
<InPhase>
After feeling like I was falling into a rabbit hole trying to extract from that module, I tried to reproduce the issue with some similar shapes made by for loop, and it didn't cause an issue.
<InPhase>
But I'm not sure what the difference is.
<InPhase>
J24k97: Yeah, I really think point ordering must be a mess here.
<InPhase>
J24k97: When offset(0.001) fixes it, that actually fixes bad ordering.
<J24k97>
but also fn change fixes it or just the z (number of teeth)
<J24k97>
and if i remove the path the issue is still there when auto ordering it.
<J24k97>
InPhase i just wanted to extract the points (had closed scad) now i can't replicate this
<J24k97>
ah your simplyfication was the issue 180/16 is not 3
<InPhase>
I extracted the points successfully now, I think, and did a polygon of that, with the same rotate and color applied, and it doesn't repeat the issue.
<InPhase>
I don't understand.
<J24k97>
So i made the same polygon with extracted points - no error visible
<J24k97>
at least our results are matching
<J24k97>
InPhase - how did you extract the points? via console?
<J24k97>
I assume we only get rounded (5digit) values from there
<J24k97>
6 digit
<J24k97>
and probably some values are float e⁻¹⁵
<InPhase>
J24k97: I echoed inside your routine.
<InPhase>
And yes, might be a rounding issue. If so, not sure how to assess that.
<J24k97>
scad shouldn't be able to use values as small as the precision .. if all scad values are rounded to e⁻¹² we probably didn't such issues
<InPhase>
J24k97: Sharing what I got to. I tried with and without that color, with and without that convexity, with and without that paths entry at the end of the long line.
<InPhase>
J24k97: Maybe I missed something, but I'm basically just confused about what's different.
<J24k97>
Yeah i found one with z=9 fn=8 that showed them even without rotation
<J24k97>
would need to use some special echo that extracts the real value used
<InPhase>
Oh, you know, one oddity is you both start and end with 12,0
<J24k97>
yes there are probably multiple points at the same position
<J24k97>
as each tooth starts at the same point the next ends
<J24k97>
which is that i think small float deviations cause micro intersections
<InPhase>
That could certainly be the cause of the issue.
<InPhase>
Can those be trimmed off?
<J24k97>
it sure can be coded more elegant (is an older module)
<InPhase>
I do see now points that are identical in sequence, and were rounded.
<InPhase>
There are certain polygon point arrangements for which failures would be marked "not a bug". But it would be valuable to reduce examples of this down to the simplest possible failing testcase.
<InPhase>
I was hoping to get a failing list of points, and keep truncating it until I got the smallest failure case.
<InPhase>
Then we might actually know what the problem really looks like. :)
<J24k97>
as the module is 1.5 this is causing float numbers