califax has quit [Remote host closed the connection]
califax has joined #openscad
ur5us has quit [Ping timeout: 255 seconds]
castawayc has joined #openscad
Colere has quit [Ping timeout: 248 seconds]
Colere has joined #openscad
ur5us has joined #openscad
toluene has quit [Ping timeout: 240 seconds]
toluene has joined #openscad
LordOfBikes has quit [Ping timeout: 268 seconds]
LordOfBikes has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
J1A846854 has joined #openscad
J1A8468 has quit [Ping timeout: 252 seconds]
toluene has quit [Quit: Ping timeout (120 seconds)]
toluene has joined #openscad
linext_ has joined #openscad
linext has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 248 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
linext__ has joined #openscad
linext_ has quit [Ping timeout: 246 seconds]
linext has joined #openscad
linext__ has quit [Ping timeout: 240 seconds]
linext_ has joined #openscad
linext has quit [Ping timeout: 256 seconds]
linext_ has quit [Ping timeout: 264 seconds]
linext has joined #openscad
linext has quit [Ping timeout: 272 seconds]
linext has joined #openscad
linext_ has joined #openscad
linext has quit [Ping timeout: 240 seconds]
linext__ has joined #openscad
linext_ has quit [Ping timeout: 268 seconds]
linext_ has joined #openscad
linext__ has quit [Ping timeout: 246 seconds]
linext_ has quit [Ping timeout: 268 seconds]
linext_ has joined #openscad
linext_ has quit [Remote host closed the connection]
linext_ has joined #openscad
lastrodamo has joined #openscad
linext__ has joined #openscad
linext__ has quit [Read error: Connection reset by peer]
linext_ has quit [Ping timeout: 246 seconds]
ur5us has joined #openscad
linext has joined #openscad
linext_ has joined #openscad
linext has quit [Ping timeout: 268 seconds]
Guest13 has joined #openscad
Guest13 has quit [Client Quit]
ur5us has quit [Ping timeout: 264 seconds]
J1A846854 is now known as J1A84
<J1A84>
points for Polygon should have a CCW order or? .. how do i best determine if points are CW or CCW ?
<Scopeuk>
J1A84 as viewed looking down (positive z behind camera) they should progress clock wise
<J1A84>
Scopeuk haha .. lol . No mathematically i need a function where i input points and output CW=true/false
<Scopeuk>
2d or 3d?
<J1A84>
2D
<J1A84>
and is this CW or CCW (example from oSCAD wiki) polygon(points=[[0,0],[100,0],[130,50],[30,50]]);
<Scopeuk>
I guess the expensive and rudimentary way would be to average your positions to get shape center and then check that angle increases, I'm not sure how this would work for complex shapes though
<J1A84>
I thought about counting outer angles (under 180) and inner angles (over 180) and which part is bigger would determine the direction
<J1A84>
for me the example is CCW looking from +z onto the shape ..
<J1A84>
(if the path isn't reversed)
linext__ has joined #openscad
linext_ has quit [Ping timeout: 268 seconds]
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
petaflot_ is now known as petaflot
petaflot is now known as Guest8266
Guest8266 has quit [Quit: leaving]
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
<InPhase>
J1A84: There's no such thing as just CW or CCW because clocks are CCW when you look at them from the back.
<InPhase>
J1A84: Instead the clearer way to talk about point direction is to use a right handed rule thumb direction.
<J1A84>
you have a normal vector
<InPhase>
J1A84: For polyhedron, it's right handed rule thumb pointing in. For polygon it doesn't seem to matter except that you should be consistent. I use RHR thumb in positive z for polygon, because I think that's consistent with the polyhedron rule if you extrude up.
<J1A84>
so what about the example .. is this preferred or not?
<InPhase>
If you wrap your right hand fingers in the direction of those points, you will have your thumb pointing in +z, so it matches my preferred orientation.
<InPhase>
Also if you do circle points with [for (a=0:359.999)
<J1A84>
ok .. so .. i just calculate the cross for a normal vector
<InPhase>
Also if you do circle points with [for (a=[0:359.999]) [10*cos(a), 10*sin(a)]] this is also RHR pointing in +z.
<J1A84>
while [sin,cos] is the other way
<InPhase>
Yes, it would be.
<InPhase>
But since cos, sin is the canonical method for a unit circle definition, the RHR in +z is canonically oriented with the way math is written.
<J1A84>
wait sin is just 90° to cos .. that shouldn't change direction
<InPhase>
It happens that it does because of the way the phase shifts work.
<J1A84>
it turned out that my offset and rounding function need to know the normal vector (CW / CCW) as inner and outer angles get switched
<InPhase>
There are many ways to write down backwards circles, such as [sin(a), cos(a)], [cos(-a), sin(-a)] and [cos(a), sin(-a)]. The last two are mathematically equivalent starting at [1,0] and going into -y, the first one starts at [0,1] and goes into +x.
<J1A84>
we should make statistics with the 5 common reported issues and then put in the template for creating new issues.
<J1A84>
(so people get the answer before submitting)
<Scopeuk>
Are you having one of the following 3 "problems", also I'm going to have a tts engine read this allowed to see if it comes across as really aggressive
<Scopeuk>
I do wonder how many people are self important/absorbed enough to ignore it as clearly not their problems because X/Y/Z
<J1A84>
there should be some bonus system that removes points if your issue is explained in the FAQ ... Ü