Coordinate math behind "Color by axis" doesn't match model precision

The OS makes no difference.
A 2016 .skp file is a 2016 .skp file.



Tricky, but doable.
Nothing Wrong Here Again.skp (24.3 KB)




Your sample file consists of four triangles.
By definition, the three straight edges of a closed triangle are coplanar.
Were he alive today, Euclid himself could not ‘twist’ a triangle.



The distance between the faces and supporting diagonals in your sample file is at most .001454"
They’re on the bleeding edge of SU’s .001" point tolerance.

Given OpenGL’s sensitivity to distance, picking one face out of the four requires zooming in extremely close.
Narrowing the camera FOV to 2° alleviates the camera clipping that comes with zooming in that close.

Your sample file demonstrates only one thing:
Attempting to fix tiny off-axis modeling errors is a rather fruitless endeavor.
As has been said in this forum many times, it’s far better and faster to erase bad geometry and redraw.

1 Like

This is going to be a TLDR for most people…

The OS makes no difference.
A 2016 .skp file is a 2016 .skp file.

Who cares about the file format itself… This is about the resulting operations from manipulating the not-perfect geometry.

I assure you that the compiled code that performs the mathematical operations in the Windows version is not identical to the compiled code in the Mac version. It may begin with the same cross platform source code, but the resulting compiled code will have operational differences, and the Open GL implementations will be different which really affects the UI.

Tricky, but doable

Tricky? No it’s not, and I don’t really understand how you’re making it difficult… Just click on the center of a face to select it. That’s how you’ll select a face with all bounding edges (“incorrect” or not). One click, cut, paste. Second click, cut, paste. Third click, cut, paste. Fourth click, cut, paste. Done.

…it’s far better and faster to erase bad geometry and redraw

You can’t always do this. You might begin by evaluating imported geometry, and when SketchUp can’t accurately do that, and then it subsequently generates poor/bad geometry during your repair process, it turns into a cascading waste of time.

You’re dancing around the primary issue here in a defend-the-quirks nature, but I agree fundamentally on SketchUp not being super accurate and having to work within it’s limits. I have never expected it to be super accurate. But I am well within reason to expect it to behave consistently and not lead me astray. I don’t want to spend time working around its quirks. I should be able to rely on tools and get real work done. SketchUp should be capable of handling 0.001 accuracy on a model on the scale of a few inches with no problems. You can’t really argue this. How could you possibly do architectural work to even 1/8" then?

So my first issue is, SketchUp incorrectly displays the internal state of the model. The color-by-axis is just inaccurate, and they really should address this because it’s just incorrect behavior. Not hard to fix - it just takes prioritization.My second issue is, SketchUp can generate seemingly extraneous geometry that confuses things. The example I showed is exactly the kind of mistakes that can creep into a model. Four-sided poly that should be possible according to what’s being displayed, but can’t be generated. Then when you try and build 3-sided polys to work around it, you get twisted and invalid geometry that shouldn’t be possible. I’ve attached the single borked face alone in a skp file, so I’m curious what you think this is…

what_is_this.skp (17.8 KB)

If it weren’t for Vertex Tools plugin and the ability to window around vertices and pull them together into one vertex, I’d completely lose my mind. At least Vertex Tools lets me get to water-tight triangles when SketchUp can’t close up things properly.

After fighting with SketchUp 2016 far more than I ever have since it’s original release, I now believe the math precision that is used to indicate edge color “by axis” does not match the specified precision of the model. When trying to do simple vertex and edge manipulation to repair STL models, I will have two edges that are clearly highlighted in the same axis color indicating them as being aligned to the axis and being parallel to one another, yet I cannot construct planes between them nor remove edges of coplanar surfaces that are between them. And I assure you, if two lines are parallel, any lines drawn between these two parallel lines will be planar. That’s simply the way the math works. So something is amiss in the functions that are used to color the lines “by axis” or something is wrong in the snapping that is placing the vertices of new lines on the existing lines. I have a screen recording of the behavior I’m encountering along with the model that I am happy to supply to tech support.

I’m not sure that I’m responding to comment that started this thread correctly, but this is my comment:

Hear, hear! I have totally found this to be the case as well. It is incredibly frustrating!

Exactly what is?