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.
As has been discussed ad nauseam in this forum for many years…
the Edge > Color > By Axis feature has a certain tolerance window.
In no way is it definitive proof edges are truly on axis.
Query Tool yields definitive information provided Units are set to Decimals and Precision maximized.
Inference locking via the Arrow Keys insures modeling operations are perfectly on axis.
Edge > Color > By Axis and Preferences > Drawing > Display Crosshairs are akin to training wheels on a bicycle. With practice, they readily become unnecessary and rather burdensome accoutrements.
As the title of this topic says, the thing that fools many newbies is that the fixed tolerance and the (undocumented) calculation used in color by axis have no relationship to the units precision set by the user.
I need to tell this to my colleagues. I don’t really struggle with drawing on axis, but I get troubled when I am using models provided from someone else. And initially thought color by axis will help me to evaluate, though it wasn’t really helpful.
And once again I must ask, would it be possible to create a tool to check suspicious edges?
Select the tool, click on an edge and it highlights red, green, blue or balck.
This is actually a much harder problem than it might sound. It is, of course, quite easy to check whether an edge is exactly on axis. Just see if the x or y or z values of the vertex locations are identical.
The difficulty is that as you build a model, SketchUp often has to calculate the coordinates of locations instead of just copying them from an existing location, and all calculations on a computer are subject to potential error due to finite-precision arithmetic. As a simple example, where two edges cross there is initially no vertex at the intersection. SketchUp has to calculate where the intersection falls based on the math forumlas for the edges. That calculation suffers from computer arithmetic precision. So, even though the intersected lines ought to be exactly on axis, they may be created as good as possible yet be slightly off.
So, whereas the exactly on axis tool is easy to make, it would fail to accept these “as good as possible” edges. That would be just as bad as the current situation, because SketchUp was designed with computer precision effects in mind. Rejecting these edges would create false alarms about things that really can’t be fixed by the user and will cause no downstream problems.
It would be feasible to build a Tool with a user-specifiable tolerance in the on-axis test (instead of the fixed tolerance current used). That would make the Tool much more technical because the user would need sufficient technical sophistication to understand the boundary between problems and good-enough. Needing such sophistication isn’t much better than the current situation of needing to know how to probe the exact location of points to diagnose misalignments.
If you activate the leader text tool (the one with this icon, not 3D text, and click on a vertex that is in the current edit context, it displays a text with the x,y,z coordinates of the vertex. The display is affected by your current units precision setting.
The main limitation of the query tool is that it is totally dynamic. That is, the values are displayed in the status area and a floating text as you move the cursor. You have to remember or write down the coordinates of one vertex to compare them with another. In contrast, the leader text method leaves a separate text on the view for each click, so you can compare without needing to remember (a major boon for us old guys who suffer from CRS). Admittedly, the text method is a bit fussier to use, though. You have to be careful where you place the text and sometimes it seems to need extra clicks to get ready for a new vertex.
Steve (slbaumgartner), I absolutely agree on the numeric precision aspect you discuss. But something has crept into SketchUp for Mac in the not too distant past, and it may be related to our 32-to-64-bit transition. When intersections are calculated and new vertices are generated, there should be consistency as to when new vertices are and are not generated, but this consistency is just not there anymore.
I have a sample file that I just submitted to tech support that illustrates crazy behavior just trying to generate a four-sided n-gon between two of these “by-axis” colored lines (link to example file). The endpoints of the lines are off by a significant amount in the z-axis (0.014" over 38.6" span which is not anywhere close to pushing limits of calculations with either well-implemented integer or single-precision floating point), yet SketchUp can’t consistently generate the expected polys when the endpoints of the lines are connected and diagonals are also drawn. Because of the way the edges are highlighted, I expect SketchUp to generate a four-sided poly when connecting the endpoints, then subdivide that into four 3-sided polys that all touch in the center when drawing the diagonals. But knowing that the color-by-axis can’t be trusted and the lines are not truly parallel, my lowered expectations are that I will get four nearly co-planar 3-sided polys, two of them sharing one diagonal and two of them sharing the second diagonal, making a tetrahedral volume. But neither of these results is what I get. I get two 3-sided polys and one piece of ■■■■ that is reported as a face but is actually a 3-sided poly with attached lines that can’t be separated or trimmed. Basically it’s a failed operation with a garbage result.
While this unexpected poly generation behavior is not directly related to the color-by-axis issue, it’s indicative of incorrect handling of numeric precision which plagues me and that should simply not be present at the scale and precision I’m working. It’s just wrong behavior, as is the implementation of the color-by-axis math to determine when to change the color of line segments. It just happened to be the color-by-axis behavior that pushed me over the edge Being a C/C++/Obj-C developer that deals with this kind of stuff in my own apps, I’m much less inclined to let them get away with this kind of behavior.
Thanks for the replies. I didn’t really know about the text tool being used that way (though something tells me I knew about it once upon a time), and I’ll have to check out the plug-in.
It would be nice, instead of inspecting vertices, to be able to select a line segment and see an information box giving start AND end point co-ordinates for the line.
Your sample file begins with two long lines which are not coplanar.
Those I copied and pasted in place in a new model file.
Then, I drew lines connecting their ends as in steps 2 & 3 of your sample file.
The result is a closed loop of four edges, none of which are coplanar.
Drawing the first diagonal (step 4) creates two triangular closed loops and two faces, just as it should.
Drawing the second diagonal (step 5) creates two more triangular closed loops and two faces, just as it should.
Given those first two lines in step 1 of the sample file are not coplanar:
The two diagonals drawn in steps 3 & 4 do not (cannot) touch where they cross in 3D space.
Here’s the model created from a copy of the two long lines in step 1 of your sample file. Nothing Wrong Here.skp (20.5 KB)
Interrogated the geometry.
Context click on a face > Select > Connected Faces
Notice Entity Info reveals there are four faces, just as it should.
Hi George. You’re on the Windows version, so you may see different behavior… But please try to select, then cut, then paste each of those four faces into a different location in the model and let me know what you get. You may not be seeing the nonplanar yet twisted face that lies within. I’ve attached a screen shot of these four faces from my 2016 Mac version.
not 3D text, and click on a vertex that is in the current edit context, it displays a text with the x,y,z coordinates of the vertex. The display is affected by your current units precision setting.
Being a C/C++/Obj-C developer that deals with this kind of stuff in my own apps, I’m much less inclined to let them get away with this kind of behavior.
