Crazy common face
-
@tig said:
... this is because it's quite possible to 'cross-thread' the direction of a face's outer-loop edges, as they are initially drawn, swapping from cws to ccws on the same face. Where the edges cross over they will usually initially split, but SketchUp occasionally mistakenly considers them all to be part of the same loop, and forms one face using the whole loop - instead of the more obvious two...
TIG thank you for getting back to original post.
So it'd right to say that Dave R rather recklessly
relocated this from the 'SU Bugs' subforum? -
It's a 'feature' of the program !
OK... once it was a 'bug' - however, it was well reported long ago - but they just can't seem to fix it - then it's no longer a 'bug'
it's now a 'feature' 
-
It seems that there is a plugin [$] to solve this problem.
-
Use the query tool to check xyz for all 5 verts. You'll see the object isn't co-planar.
But considering it is 2 tris it shouldn't matter as tris are always planar.
It's a weird one but not knowing how the result was gotten adds to the mystery.
-
It's a rare occurrence.
The 'bow-tie' face...
Usually it appears from CAD imported geometry or some convoluted code-generated faces.
It's hard to make manually, because the default auto-breaking of the edges kicks in as the bow-tie's edges cross over and makes two triangles.
Even settingSketchup.break_edges=falseresults in a bow-tie that doesn't form a face because SketchUp recognizes it as not face-able.
However if you then select just those crossing bow-tie edges and use
Sketchup.active_model.active_entities.add_face(Sketchup.active_model.selection.to_a)it will form a face for one triangle only although the edges forming the loop are longer that the sides of the face
Sketchup.active_model.active_entities.add_face((Sketchup.active_model.selection.to_a.collect{|e|e.vertices}).flatten.uniq)also produces the same odd result.
However, this then Intersects as expected to split the one triangular face off from the unfaced parts of the edges...
I suspect it's a tolerance issue.
The four points aren't quite coplanar enough to auto-split as the edges cross BUT are considered coplanar enough to keep a face
-
@rich o brien said:
Use the query tool to check xyz for all 5 verts. You'll see the object isn't co-planar.
But considering it is 2 tris it shouldn't matter as tris are always planar.
It's a weird one but not knowing how the result was gotten adds to the mystery.
May be I'm missing something...
Look I took original shape and just aligned it to world UCS. all 5 vertices have z=0.000000
(so they ARE co-planar in plain English)
-
When rotated 'flat' the Z value of each of the bow-tie's vertices positions report as '0.000000'...
BUT with a little coding
Sketchup.active_model.selection.to_a.collect{|e|e.vertices}.flatten.uniq.each{|v|p v.position.z}
the 'real' Z values are actually this:-6.93889390390723e-017 1.1518563880486e-015 -1.15046860926782e-014 -2.35922392732846e-016 0.0Note that there are 5 listed because somehow you have managed to split the crossing lines, but kept the one face with all of the edges taken as the twisted loop ! A 'true' bow-tie has only 4 vertices - with 2 crossing edges near the center...So... all Z's are effectively '0', BUT still NOT exactly '0'.
SketchUp has to decide if these are '0' enough for its purposes.
It decides that they are indeed flat enough to keep a face, so it adds one.
However, when it was forming the face it decided that the crossing lines didn't intersect so the lines get just one face with a twisted loop.
BUT then it also decides that the crossing lines DO intersect and it splits them near the center, but it still keeps that one face, when logically it should have split it into 2 !This is rare, but I do agree that it's plain weird...
-
Something isn't correct with that geometry...
If I run Vertex Tool > Make Planar it will immediately make 2 faces. This suggests that the geometry isn't planar and that the tolerance is so small it is outside SU's size limit.
So even though the Query Tool reports all verts are at 0.000000 (6 decimals) the actual position could be 0.000000# (7 decimals or more).
EDIT - TIG reported the discpreancy also. This isn't truly planar
-
That SuperDraped geometry is in effect produced using SketchUp's Intersect methods etc.
Again it's twisting a face's loop and not splitting the face it into the logical sub-faces.
I also suspect that the face's vertices won't be exactly coplanar [resulting from SketchUp's own internal accuracy issues]...
I'm sure we can all reproduce it if we try... BUT the bottom line is that it is fixable at the geometry level with a little work. It doesn't seem readily fixable at the program level.Clearly it is a 'bug' by most common definitions... BUT it's not new, it is known and was reported... However, filing this away in 'Bugs' would get a lot less exposure and traffic than it has where Dave eventually put it...
So as it's not been fixed [or perhaps it's just not fixable at the program level] - so it has become a 'feature' of the program -
...A software bug is an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result...
http://en.wikipedia.org/wiki/Software_bug
-
Amen!
Advertisement