Erratic behaviour of edge intersect in simple geometry

Maybe I’ve to review some of my own beginner videos… thanks for the tip.

1 Like

Those sound like good rules, which I haven’t seen. Would you be so kind as to provide a link to where they are documented in case I need to refer to them?

-Gully

I’ll point out that the shape above can be drawn without the errors by using more conservative (for lack of a better term) methods. As always there’s more than one way to do things.

Shep

1 Like

Ok No overlaps!

The point I’m getting at is that at certain times a simple line does not cut a face even when drawn correctly on the face.
This is not a feature or a rule or something that should need a work around. It is a tiny flaw in the program that is worth bringing to the developers attention.

4 Likes

@Box

Thanks for bringing this up. I tried modeling this the way you first described and got the same result also. I won’t be so frustrated any more when a face needs to be redrawn to register correctly.

I think this is another manifestation of the same problem as discussed in this topic, where it arises in a different way:

In both cases there is erratic behavior of whether or not Edges that by all analysis are on a Face do or do not cut that Face. Seems like a hole (pun intended) lurking deep in the logic somewhere.

Yes, I very nearly posted it to that thread.

Shall we put all our bugs in one basket? Did I say bugs? I meant features.

Shep

On the tests that did not intersect correctly, try selecting all > r-click and Intersect.

Until SU7, edges did not auto break when things intersected and we would have to intersect. It took awhile to get used to as many people developed workflows that took advantage of the lack of auto intersecting. Smustard developed a plugin to revert to the pre-SU7 functionality for those people.

I’ve noticed BreakEdges doesn’t work 100% “as expected” since it was added, and selecting and intersecting was still needed sometimes. But when trying to duplicate the OP sample, I found if I paused a bit to be sure the inference engine kicked it, breakedges could work as expected.

2 Likes

Under the hood, faces in SU are triangulated. One of the special things about SU, is that co-planar faces can appear as a single face. You see the triangulation when manipulating geometry as in folding. In the animation, it did not look like all the ziggy-zag edges where planar as shown by the hidden geometry.

I’m not really sure how long you want me to pause to wait for the inference to kick in, usually when the tool tip tells you something is on face etc should be enough.
As for select all and intersect, sure I can do that, but I already pointed out that doesn’t always fix it.
Here it is again, and as you can see is easily reproducible. The edges are broken because you can select them individually, but they are still connected.
It may not behave the same way on your system, perhaps it is a graphic card issue or some sort of system setup, but it does happen, is reproducible and it’s not just on my computer.
It’s not bad modelling, it’s a flaw in the software, which is why it is worth pointing out and not glossing over. It is the very definition of a Bug.

1 Like

Here’s another look. This “feature” was covered in a different thread with only two simple planes. In this view I add a hexagon to show how the problem is amplified.

All we want is to make a great application better.

Shep

1 Like

@Step, I can’t see how you could call this a feature rather than a bug, the sequence Box mentioned.
What is the relation between what you are doing and his example.

@Box. This failure of correctly splitting a face into two or more faces has been mentioned several times in the past. I think even your example can be brought down to the breaking an unwritten rule in which SketchUp fails to create faces in a correct way. It has to do with splitting up an existing face with newly drawn geometry into two or more faces where bounderies have only one mutual vertex. I had to look closely at you example but yes, it is there.

Create the exact same shape within the large rectangular box but this time without that large face.
SketchUp doesn’t fail. In the end draw one of the large sides of the rectangle to fill in its face. All parts are selectable as single faces.

It is a long known (I would say) bug. Do not make SketchUp split up a face with only one mutual vertex in its loops.

p.s. Two simple examples:

  1. Draw a rectangle. Select one side and rotate it 180 degrees about the central axis perpendicular to this edge. You’ll get a flat buggy sandglass.

  2. Draw a rectangle and on its face create a triangle that touches in one corner by only one vertex.
    Selecting faces reveales an error.

Take example 2). Do the same but first delete the large face. Later fill in the large face by tracing one side of the rectangle. Selecting faces won’t reveale any error in split faces.

1 Like

Which part of all this haven’t I made clear.
You are even calling it a long term Bug, I am just bringing it to people’s attention.
I’m not specifically complaining about it or theatening to storm off and use some other software!
I am simply pointing out a distinct, repeatable inconsistency in the way edges interact with faces.
It’s what people do when testing software, if they find something that isn’t quite right they point it out so it can be fixed. They don’t jump on people and say that is the way it has always been so learn to live with it.
@Shep has simply brought another inconsistency from another thread here to help consolidate them rather than making more threads. It is wholly relevant if you read all the posts.

Box, was the first part of your last post addressed to me?
If so, like you I call this a bug, one that somehow needs to be fixed. But unfortunately it has been there for a long time.
I was trying to find a pattern in why your example shows this odd behavior and only pointed out that it also fits unwritten odd/incorrect rule of new faces sharing oly one vertex in their boundaries.
If you were offended, sorry about that, my bad choice of words I guess.

Since the bug is there, a workaround is to have a second mutual vertex in both loops and then slide one vertex on top of the other where it should eventually be.

1 Like

I’m Sorry Wo3Dan, I did bite there…
It was just that I know there are work arounds, I know how to fix it etc
It was simply that I found an easily repeatable sequence of drawing something that shows perfectly the problem that has plagued people from time immemorial and people keep telling me how to get around it.
I just wanted someone who had the ability to do something about it look at it so that they might be able to work out why it does this. I was being helpful but I’m only coming across as obnoxious.

@Shep, I have always seen the hidden geometry you show during operation like folding. But In my case, the display of hidden geometry disappears after I’m done moving/folding/whatever unless I’ve done something to alter the plane.

Try typing a value for rotation instead of angle snapping. This was discussed elsewhere but I can’t quickly find the thread.

Shep

Reading Box’s “bite”, (sorry Box;-) and rereading your (quoted) post I now see that you pointed to an entirely different weird behavior.
Somehow here SketchUp doesn’t like an input without having done the full operation.
As you said, typing in a rotation value before clicking an end rotation triggers the hidden lines.
Typing in a value after that second click makes hidden lines disappear immediately after numerical input. So does, as it seems, retyping the same value in the first case. This corrects the visible mistakes.
Odd behavior, to say the least.

28 posts and no reaction from one developer or SketchUp team member. Do they work on the solution and want to surprise us?