Coplanar lines don't intersect

Hi, I’m working on designing a theater building (just the right half at this point, since the left half will be a mirror image). I wanted to layout rows for the floor seating. Since there aren’t any arc guidelines (guidearcs?) in SU, I simply selected the curve at the front of the stage, on the floor, and used the follow-me tool to create arcs at 5’ intervals. Here’s the big picture (note the selected lines indicating the location of the problem):

In the next picture, you can see when I select the face, that the lines do not create a separation between faces:

Same thing from below the face:

Even though the lines cross in the same place, they don’t bisect each other into four lines; they remain two:


And again, same thing from below (reverse angle):


If I can see the same selected lines from both sides of the face, then they must be coplanar with the face, right? So why don’t they act like it? The only reason I drew the line along the side was to break the arcs at the end of the rows. How can I “cut” the rows at the guide line?

Here’s my model (SU Make 2017), if that helps…

TheaterWedgeErr.skp (282.3 KB)

Can anyone suggest what’s going on here? Or is this a bug?

First, you could use layers for different elements of construction

I do not know how you drew those arcs, but it was easier for me to redesign from scratch.

After the first offset, you can double-click inside and the next circle will automatically copy at the same distance.

Hi, @mihai.s, thanks for your response…

Sure - I could use layers. I have used them for other models I have done. Not sure why I didn’t use layers in this one (yet).

In my original post, I mentioned “I simply selected the curve at the front of the stage, on the floor, and used the follow-me tool to create arcs at 5’ intervals.” Actually, instead of “follow-me”, I should have said “offset”. Sorry for the confusion.

I suppose that’s another (non-so-intuitive) way of doing it; however, it doesn’t really answer the main questions from my original post:

  1. If I can see the same selected lines from both sides of the face, then they must be coplanar with the face, right?

  2. So why don’t they act like it?

I suppose it does answer my third question:

  1. How can I “cut” the rows at the guide line?

But it sounds like your answer is: “Try starting over, using some other approach, and just hope that you don’t run into the same problem again.” If feels like you got lucky and I didn’t. But I don’t really understand why my approach fails, so I haven’t really learned anything new about how to use SU successfully. It still feels like I came across a bug in SU Make…

Unfortunately it’s not quite that easy. When lines are extremely close to a plane they will sometimes bleed through the far side of a surface.

In this case it appears that your ground plane is very slightly out of level. This could have been caused by a slight move of some connected geometry at some point. Generally judicious and frequent use of components or groups can help prevent things from sticking to and affecting each other, also care with using the inference engine and when moving objects. Once a very tiny error gets introduced it can often get compounded if not caught early and corrected. It appears that one corner of you floor is not in plane. Sampling various areas of the problem section reveals a bunch of different z values (the third number, a tilde before the number indicates that it’s approximate, not exact, which is a problem) and looking at edges colored by axis can help reveal which edges are “level” and which are off axis. The rectangle I drew is “level”, clearly many of your edges are not. My guess is that a slight move was introduced to some section of the lower floor that dragged everything with it.

This is why your lines and surfaces are not behaving as expected, because they are not actually intersecting or touching the plane in some places, but separated by tiny spaces in the z direction. Stretching out the affected geometry shows the errors.

It’s likely that other areas of the drawing are out of square. Sorry to say it might be easier to start over, once the errors are baked into the walls and attached architecture it can be very tedious to fix.

1 Like

I wanted to show you a way to draw that element so you can move on to your project. It is possible that those lines and arches only appear to be in the same plane, but they ar not, or… software to have a problem (less likley).

endlessfix explained very well in detail the most probable cause.

1 Like

Hi Riley (@ endlessfix), thanks for your response. I didn’t respond before now because I was too disheartened (no joke).

Sorry, it’s not clear to me what your third image [TheaterWedge.jpg] is intended to show… Can you clarify that for me?

I consider this a #bug in Sketchup Make. The SU team may need to escalate this to the OpenGL developers, but it’s a bug. There should NEVER, EVER be bleed through. This is virtual reality - the physics of this reality are under the developer’s control. This problem has been complained about for years with no apparent effort to solve it, and it has caused unsightly blemishes on my models too many times. (Fortunately, I’m just a hobbyist, so I haven’t been wasting time & money photoshopping these things out of presentations.)

Thanks for finding this.

I have been using components & groups for years for precisely this reason. I have been using SU for 10 years; I am a pretty detailed, careful person; and I have encountered this problem many times in my early models, so I know that this is something to watch out for. Somehow, in spite of all that, it happens again… extremely discouraging!

As for the inference engine, I find that it has not gotten better, but worse. Whenever I try to draw something, the inference engine goes a bit crazy trying to find other geometry that might be related. Quite frankly, it drives me nuts. And I have had to re-do Line operations a number of times because it shifted my end point to something nearby that it thought I might have meant (when I didn’t). I wish the inference engine would go back to the way in was in SU Make 2015…

Yes, I have experienced that. The problem is catching it early…

Thanks for offering a way to catch this. How do you look at “edges colored by axis”…?

It would seem from your suggestion that after every draw operation I should go back over all previous geometry to see if anything got moved that I didn’t intend… Seems like a tedious and time-intensive way of modeling.

I wish there were a way to tell SU to not allow such things to happen. Since my models use a precision of 1/16", it would be great if SU would warn me about movements that are less than this threshold (or simply prevent such movements).

In the future, if you have this problem again, you can try to flatten geometry periodically to see if it can close those less than coplaner lines. Try this:
Also, Eneroth has another plugin that allows you to toggle whether lines break or not when intersected. Sometimes helpful when offsetting things and needing to keep lines together till done/:slight_smile:

Also, “edge tools” by ThomThom is a handy one here too as it will find gaps that are hard to see and can fix gaps too if you give it parameters to work with.

Yes I meant to mention edge tools as well. I’ve recently started using it at it’s been great at finding and closing gaps so I can make faces inside complicated linework…even on terrain. A must have for sure.

Hey @tkhoatson, I totally get being discouraged, Sorry I’ve been swamped with work. In the third image I was just using the scale tool to stretch the floor in the z direction to show the irregularities. Selecting an object and trying the scale tool will only show two axis of handles if the object is truly 2d which is another way to check. The “bleed through” can be annoying, it’s a function of openGL processing, it can be handled from within Sketchup by hiding edges or modifying styles, I’ve never had to photoshop anything because of that.

Yup, making a component out of every single element as soon as it exists is the key to keeping everything separate and organized. There is as little raw geometry as possible, and all parts are separate. It’s generally the move tool that distorts models, dragging things with it, so pay special attention when moving anything the does not have a blue bounding box.

The inference engine is usually a great help, but it’s important to understand what it’s trying to do and how it’s getting it’s information to make it work. Do you have length snapping enabled under window>model info>units? Looks like you might have that set to 1/16", sometimes that can make your lines jump around as you described as SK is trying to adhere to that and will find the nearest node that is 1/16" away. I leave mine off.

Coloring Lines by Axis is available by editing the current style under the style window and at the bottom of the edges tab under color. It’s also available as a shortcut under Sketchup>Preferences>shortcuts>view/rendering/edge/byaxis, I have mine set to the “I” key on the keyboard to toggle on and off.

Hi eric-s, thanks for your response…

Just tried it. I selected all of the floor faces (all faces in the same plane as the bottom floor), then used the flatten plane tool. Unfortunately, it flattened all the faces into a single line. And this was not only for the selected faces, but for the whole model! Everything was gone except for a single line! Don’t know what went wrong there… I was really hoping this would get me back on track again.

Hi, endlessfix, no problem about the delayed reply.

Ok, I’m still not sure how you did that…

In fact, that’s what I see when I select the floor face (in the model I posted here) and then choose Scale. There are no Z handles, only X & Y. Not sure how you were able to get different results…

Well, let’s just call it a dis-function of openGL processing… SketchUp developers should escalate this with the openGL team - it’s unacceptable, and we’ve been living with it / accepting it for far too long.

Sure - I’ve wasted lots of time going around hiding lines that shouldn’t need to be hidden. It’s unacceptable. I’m really tempted to give Blender a try to see if I get similar results. (Or does Blender not use openGL?)

I generally don’t move loose geometry (i.e. edges), so I’m really at a loss how my floor could have gotten moved out of the horizontal plane.

I just checked, and it was on. I had this on in SU2015, and it was not a problem for me. At any rate, I have now turned it off. What do you do for “angle snapping”? On or off?

Great - thanks! I never knew about that before. So I just tried it, and I’m still mystified… It shows some of the floor edges are aligned with the axis. Only the lines that are at a different angle are not colored. But if I rotate my model in the horizontal plane to align the other side of the wedge, those edges are colored as aligned. So that didn’t help in this case, either…

I have angle snapping off as well. Color by axis is a useful tool, only lines actually in line with an axis (90˚) will register, so your diagonal line will not, even if it’s flat. It’s also not perfect, no one that I know of is quite sure what exactly the tolerance is but it’s been proven on this forum that some extremely small angles over large distances read as level, probably a function of Sketchups minimum .001" tolerance.

Eneroths Flatten Plane is a great extension, a go to for many of us who work regularly with .dwg files. I cleaned up some of the grouping by isolating the floor into it’s own component, then ran flatten plane on all the raw geometry. Everything looks kosher now. I was able to erase the offending lines from the first post.

The rest of the model is still there in the file, it’s just hidden. But, if your walls were skewed as a result of the move you might want to check them carefully, or perhaps push pull them up again.

TheaterWedge no Err.skp (406.8 KB)

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.