Intersect Faces causes triangulation

[TommyK]

I have been getting bugs when I try to intersect faces quite frequently lately. When I intersect a simple cube into a face, the face gets triangulated:

The triangulation can be easily erased, but it is starting to get annoying doing this so often now.

Interestingly, if I scale down all the geometry down by a factor of 10, the triangulation does not happen. I think perhaps there is a mismatch between the precision with which SketchUp deals with one kind of operation (creation of planar faces) and another (intersection of face).

If you observe the image above (and the model attached), you’ll notice that the vertices of the face on the Z-axis varies by a maximum of 0.000414mm - this amounts to 0.000016 inches. As I understand it, SketchUp treats points spaced less than 0.001 inches apart to be the same point for tolerance purposes. But it seems that when dealing with faces/planes (or maybe just the intersection tool), the tolerance is much smaller (by a factor of about 100, I think).

Therefore, I think there is a bug to be resolved here.

On a further note…
I have been getting what I think are tolerance issues quite a lot when dealing faces lately. I have been getting lots of duplicate faces, for instance when bisecting a face with a line. It happens most often with highly developed models, not at the beginning stages of building.

I suspect that rectilinear, axis-aligned geometry start to go ever so out of line (but still within Sketchup’s tolerance), after multiple changes to the axes of a component, which performs transformations to the geometry. For complex models, changing the axes while modelling is something that is very useful, and not something I am prepared to give up just yet.

The model attached is a piece of a larger model I have been working on for some time. You can try to intersect the face with the group, and see the triangulation happen:
Component_11.skp (56.9 KB)

[john_drivenupthewall]

I’m not sure this is a ‘bug’ as it’s is due to the seemingly random hidden edges…

however, if you Intersect ‘all’ with model whilst in ‘Wireframe’ view, it does not split any surfaces…

john

[TommyK]

Hmmm… You’re quite right. Intersect Faces > With Selection creates the triangulated hidden edges, while Intersect Faces > With Model does not.

The plot thickens…

[g.h.hubers]

Your model’s top face isn’t coplanar to begin with. You can see that in the text labels that you attached to the different vertices.

This is what the top face looks like in front view when scaled up vertically by 1000,000x to exagerate the vertical differences:

[slbaumgartner]

Small errors are inevitable when floating point arithmetic is used in operations such as transformation, calculation of vertices for arcs and circles, intersections, etc. It would seem that unlike the tolerance test applied to nearby vertices, SketchUp does not have a test for coplanar when performing operation such as @TommyK showed, and surprisingly small off-plane amounts can cause triangulation or failure to form faces at all. We see examples here on the forum fairly often.

I speculate that any test for coplanar would itself suffer computer arithmetic effects and might therefore be unreliable. That could be why SketchUp doesn’t even try…

[g.h.hubers]

@slbaumgartner

I speculate that any test for coplanar would itself suffer computer arithmetic effects and might therefore be unreliable.

Strangely when I select the face > Intersect Faces (with model) > I get no triangulation.
When I select the cube component > intersect Faces (with model) > triangulation.
When I select both the cube component and the face > Intersect Faces (with model) > no triangulation.
When I select both the cube component and the face > Intersect Faces (with selection) > I get a different triangulation.

[TommyK]

@g.h.hubers

Your model’s top face isn’t coplanar to begin with. You can see that in the text labels that you attached to the different vertices.

Yes, this is inevitable when using a computer’s floating point numbers. However, the inaccuracy is well within SketchUp’s declared tolerance of 0.001inch, therefore SketchUp recognises the original face as coplanar.

@slbaumgartner

It would seem that unlike the tolerance test applied to nearby vertices, SketchUp does not have a test for coplanar when performing operation

It must be the case that Sketchup does test for coplanarity, as Intersect Faces > With Model seems to work.

Having done some vector mathematics myself in this area, there is a difference between checking if two faces (with vertices) are coplanar within tolerances, and checking if two planes are coplanar within tolerance. The first’s unit of tolerance is length, the latter’s unit of tolerance is angle. They are not simply interchangeable.

I think the way to fix this from SketchUp’s end is to check in their code how coplanarity is decided. Also it might be the case that in their code, they split faces into triangles, then do the intersection operation, then stitch those triangles back together. They may simply forgotten to stitch the triangles together in the Intersect Faces > With Selection operation.

@g.h.hubers

Strangely when I select the face > Intersect Faces (with model) > I get no triangulation.
When I select the cube component > intersect Faces (with model) > triangulation .
When I select both the cube component and the face > Intersect Faces (with model) > no triangulation.
When I select both the cube component and the face > Intersect Faces (with selection) > I get a different triangulation .

…The plot thickens even more!

[jimhami42]

It might be worth noting that when drawing on the ground plane (x/y), the z coordinate of the point will always be exactly zero. This is not always the case when drawing “in the air.”

[added] You can draw a rectangle with lines by using the [x,y,z] coordinate input option. Apparently, while you cannot create a line shorter than 0.001", you can create a coordinate to six decimals by entering somethng like [1,1,0.000001] in the VCB (Value Control Box).

For tolerance purposes, the four corners of this “square” are treated as co-planar.

Repeating this with [1,1,0.001], the lines are no longer thought of as being co-planar.

[TDahl]

@jimhami42

It might be worth noting that when drawing on the ground plane (x/y), the z coordinate of the point will always be exactly zero. This is not always the case when drawing “in the air.”

A factor which impacts this behavior is that the numeric value of zero can be represented EXACTLY in the standard IEEE floating-point format, whereas virtually no other whole numbers can be represented EXACTLY (nor can nice fractions or even low-precision small decimal values, such as 1/3 or 0.1 or 0.01 or 0.001).

The magic and the drawback of the floating-point format is that the values which can be represented EXACTLY are discretely and non-uniformly distributed on the number line, packed fairly densely near the zero origin and spread quite far apart at huge offsets. This behavior is how floating-point (with fairly small binary representations such as 64 bits) can simultaneously represent huge values (with correspondingly sparse resolution) - such as 10 raised to the power of 300 - and also represent small values (with very high resolution) in the ordinary human range closer to zero.

The term “floating point” comes from the fact that the decimal point “floats” or effectively moves back and forth within the binary representation, yielding varying precision in order to accommodate such a wide range of number space.