Deleting an edge leads to model disappearing



I would like to report a behavior that might be a SketchUp bug. My version is 17.2.2555 SketchUp Make 64 bit on Windows 10.

  1. Open this model
    lavice, chyba sketchup.skp (1.4 MB)
  2. Orbit around without any problems.
  3. Delete the edge labeled “Delete this edge…”
  4. Orbit to the left to see the bench from the front.
  5. Whole model disappears.

A few notes:

  • If I first delete the label “vruty” and then the edge it works OK.
  • The edge was created by rotating the horizontal (seating) part of the bench and I wanted to clean-it up.
  • As I have found a solution how to workaround the issue, I don’t need any help. Though fixing the possible bug might help others :slight_smile:



I can confirm this behavior - and it happens in Pro 2018 as well.

First, a couple of digressions:

  1. I changed the category of this post to Technical Problems --> Sketchup (was Technical Problems --> Sketchup Free). The Sketchup Free forum category is not for any free version of Sketchup (which includes Make and Free). It is specific to the web version of Sketchup: “Sketchup Free”
  2. I removed the comma from the filename - not sure if I needed to, but I’ve heard that commas can cause problems on some systems.

I think the origin of the problem is that the label “vruty” is attached to one of the two faces which are combined when you delete the indicated line. I don’t know the internals of SketchUp, but I’ve heard there are problems when deleting labeled items - the label becomes dissociated with any model geometry and SketchUp becomes buggy. Evidence for this? When you delete the indicated line, the “vruty” label disappears - but I’m betting it still exists internally and SketchUp just doesn’t know where it’s supposed to be displayed!


Yes, you can reproduce this behavior by drawing a rectangle, add a label text on the face, draw a line to divide the face and then erase that line. The attached label sometimes disappears, sometimes it will 'fall 'just next to the face. Applying a zoom extends will expose difficulties in navigating.

Reproducing the detached text bug

Congratulations!! So far as I know, this is the first reproducible example of the singular text bug that has been reported off and on recently. When you delete the dividing edge, the text moves off to the outer reaches of the solar system and destroys the ability to zoom correctly. Hopefully with a test case in hand the Trimble team can fix the bug.


This relates to the reported issue with text randomly located miles from the rest of the geometry.

It seems that if you delete some entity - like a face or edge or vertex - which has a text entity linked to it, then that text gets relocated randomly - miles away.
This then causes the model to appear to zoom erratically.
It looks like the model has disappeared, but actually it’s still there.
Unfortunately the far away text now messes with the zoom…

The ‘Team’ need to address the issue and make these ‘orphaned’ text entities’ locations default to their former ‘anchor points’ in their current context.
Since each point ‘attribute’ relates to a specific face, edge or vertex - and that no longer exist, it might be difficult to realize ?
So perhaps text entities need to have a ‘point’ property separately assigned [used] as an attribute when they are first added or edited, which can be used during the ‘bereavement’.
Since a text entity already has a position ‘point’ property, then perhaps using that should fix things ?
That could then be used to reorient the text entity should it’s ‘parent’ entity cease to exist !
This does not seem difficult ?

Pinging: @TheOnlyAaron @ChrisFullmer


To explore this some more, I did the following:

  • Drew a 10x10 rectangle at the origin on the z=0 plane
  • Drew a diagonal from the midpoint of one side to the midpoint of the adjacent side, dividing the rectangle into a triangle and a 5-sided polygon.
  • Attached a leader text to the approximate center of each of the two faces

Examining the model’s entities, as expected there is a face with 5 edges in its outer loop, another face with 3 edges in its outer loop, and the two text entities.

Then I deleted the diagonal edge drawn in the second step above, leaving just a rectangle again.

The label attached to the triangular Face blew up. The label attached to the 5-sided Face shifted over a bit but stayed present, evidently attached to the restored rectangle, but not updated for its new area. I could see no rationale for the new anchor point of the text. It seemed to swap the x coordinate into the y position and create a new arbitrary x value.

At this point I re-examined the model’s entities and found that the 5-sided face had been reused (same id) but converted to 4 edges again, the triangular face no longer existed, and the two texts were still present.

The results say to me that, as @TIG speculated, the Text contains some link to the original Face - though this is not exposed in the Ruby API and not accessible via its #point method - and goes singular when that Face is deleted.

Edit: evidence that the Text does contain a link to the Face: if you select and move the face, the text moves along with it!


When the label text is used to display the area of a face, it seems logical that when you erase the dividing line, the label attached to the former area is no longer needed and should be erased or recalculated.


Every text entity that is ‘attached’ to some other entity in the model has a ‘point’ - which is simply got from its position.
When its associated entity - face/edge/vertex - ceases to exist, then surely that text’s ‘anchor’ should revert to its ‘point’ - in 3d-space in the current context.
At the moment it seems random.

I disagree that this kind of text should be deleted along with its ‘parent’.
If you add text pointing at a face and decide not to use its default ‘area’ string, then you add a custom string - “Kitchen Floor”.
You’d probably be disappointed should the text vanish with the floor face.
You could easily recreate that face, and reattach the temporarily ‘orphaned’ text…


I was suggesting that, when used as area-tool, erasing the label together with the lines is ‘wanted’ as behavior, for the area changes. (Perhaps its use, also)

Label tool in action with that other, longstanding bug


You’re conflating the “delete-face-zoom-off-to-infinity-with-text-tag” with the other separate issue, where dividing a face sometimes returns the wrong area. due to incorrect splitting.
In you example, what does the incorrectly tagged 4m² corner show in Entity Info when it’s selected.?


Here’s another example of how leader text is mismanaged when it was anchored to a face and you edit that face. Watch how the anchor point jumps across to the other half of the face when I draw a dividing edge. And, of course, when I delete the edge and then zoom, the camera flies off to never-never land.



32 m2 , it is somehow connected with the inner square but ‘negative’

so the main square is 10x10=100m2
the little ones are 2x2=4m2
middle 6x2=12m2
the inner should be 6x6=36m2 but displays 32m2

both inner and the upper right square display 32m2 (36-4) in the entity info and as label…


Clearly this issue is a complete mess !

Perhaps fixing the deleted-face-text-tag-disaster could go some way to resolve the other obvious messes with text-tags of faces that get edited…

This cannot beyond the “wit-of-man”,


My weird logic would require that when you erase an entity with a text leader attached, the text ought to be deleted as well (as happens, for instance, in Archicad and Revit). The same with associated dimensions. Or then the text ought to be transformed into screen text.

Nice that this issue seems finally to be nailed.


This topic was automatically closed after 91 days. New replies are no longer allowed.