Christina and Chris D, and others no doubt, have made code for taking care of text that has gone to an infinite distance away. It works by looking for NaN values in the point of the text object.
I have a customer’s model where five text objects, some dimensions, and even a construction point, are all in illegal territory. The point check that works for text doesn’t work for dimensions or construction points, so I looked at the bounding box for a while. Unfortunately, the center of a completely illegal bounding box is a legal value, (0,0,0) usually. So I started looking at the corners, and then at the max and min values.
There are some problem cases where the object is a long distance away and cause problems, but not far enough away to be NaN. So, I check for anything that is an unreasonable distance away in any direction. These are my lines of Ruby now (the first line is Christina’s one for just taking care of the text):
Sketchup.active_model.active_entities.grep(Sketchup::Text).each { |t| t.erase! if t.point.to_a.any?(&:nan?) }
Sketchup.active_model.active_entities.grep(Sketchup::Drawingelement).to_a.each { |t| t.erase! if t.bounds.max.x>100000 }; nil
Sketchup.active_model.active_entities.grep(Sketchup::Drawingelement).to_a.each { |t| t.erase! if t.bounds.max.y>100000 }; nil
Sketchup.active_model.active_entities.grep(Sketchup::Drawingelement).to_a.each { |t| t.erase! if t.bounds.max.z>100000 }; nil
Sketchup.active_model.active_entities.grep(Sketchup::Drawingelement).to_a.each { |t| t.erase! if t.bounds.min.x<-100000 }; nil
Sketchup.active_model.active_entities.grep(Sketchup::Drawingelement).to_a.each { |t| t.erase! if t.bounds.min.y<-100000 }; nil
Sketchup.active_model.active_entities.grep(Sketchup::Drawingelement).to_a.each { |t| t.erase! if t.bounds.min.z<-100000 }; nil
The lines fix the model, but not without doing 10x zoom extents. Here is a video of how the model changes after the repairs are done, and up to 10 zoom extents later. Note how it also has the problem where the blue axis is solid downwards, no dotted blue up axis line, at least until around the 4th zoom extents.
It seems to only work on text. If I use that code the model is still stuck in its outer space zoom level, and zoom extents doesn’t help. I believe there still to be some dimensions and one construction line that needs fixing at that point.
If I run my lines of code after trying your one, the model gets fixed (other than many manual zoom extents.
I realized though that it may have just been the force zoom extents you were pointing out. If I add these lines to my code, all is good:
On the axis thing by the way, it’s hard to select the axes, but when I do, Reset is grayed out. The upside down blue axis is not because the axes need resetting.
Something else I meant to ask: Is there a version of SketchUp where the going off into infinity zoom extents problem was known to be fixed? The customer who I am trying to help is using SketchUp 2018 (most recent Windows version of that).
i.e. write and post code that is easier to modify and read…
# Ruby Console is multiline, no need for all the nil's
# use references to make SU's life easier
model = Sketchup.active_model.active_entities
# grep and each are not both needed
model.grep(Sketchup::Text) { |t| t.erase! if t.point.to_a.any?(&:nan?) }
# do things once wherever possible, easier to change
max = 100000
# grep returns an array so no need fot to_a either
model.grep(Sketchup::Drawingelement) do |t|
tbb = t.bounds
# use spacing for readability and :or or :||
t.erase! if
tbb.max.x > max ||
tbb.max.y > max ||
tbb.max.z > max ||
tbb.min.x <- max ||
tbb.min.y <- max ||
tbb.min.z <- max
end
without the model, I haven’t tested, but it’s easier to ‘fix’ if it doesn’t work the same…
and de-tab for best appearance on here…
edit: to actually remove the :each from the :grep on line:2 in the code & the any ? fix…
I didn’t yet write one extension, so these are early days for me and Ruby!
Aside from fixing if t.point.to_a.any ?(&:nan?) } to if t.point.to_a.any?(&:nan?) }, your version worked as well, other than doing a lot of ‘nil’ puts.
It was surprisingly hard to find an article that told me for sure that Ruby uses || for Or.
Is there any way to view more than one input line in Ruby Console?
Thanks for that try. Reading your notes, you don’t allow for dimensions or construction points that are NaN or a ver long way from the origin. It doesn’t get close to fixing my test case.
If the goal is to delete those Dimensions, you can use the Preference panel to select all dimensions?
Window->Preference->Dimensions select all
Hold shift to deselect around the origin.
Deleting guidepoints could be done ( with some collateral damage) via the [menu]Edit->Delete guides?
The snippets provided in this topic will be very helpful for many users with problem models. I’m sure it will be a great relief to save most of a large model rather than having to start over. I just want to emphasize some (possibly unavoidable) limitations of the fixups that may leave some follow-up issues and work the user might not have expected.
The codes repair various kinds of defects by erasing the offending entity. In many cases that is the only sensible fix, but sometimes not. For example, CAD users are notorious for scattering model content at large distances from the model origin. That’s a difference between how CAD allows one to work and what SketchUp supports; it does not always mean those distant items are useless junk. It might be possible to salvage model content by moving them closer to the SketchUp origin. But that requires some judgement. My point is that users should be prepared for the fact that non-junk content may be lost that could have been salvaged with a more elaborate approach. (By the way, although there is no harm in checking for it, I have personally never seen anything except a leader text that has nan (not a number) values in its position, only very large but numerically legal values).
In the reproducible cases that trigger the stray leader text bug, the entity that the text was attached to was destroyed during an edit of the model. For example an edge dividing a face into parts was erased, causing two abutting coplanar faces to merge into one. The SketchUp engine, prior to 2019, went off the rails trying to recalculate the point and offset vector for the leader that attached to a deleted face. Saving the text by moving it to the origin (or any other point) is an incomplete fix in that the only way to repair the problem is to create a new leader text anchored to whatever the original was supposed to label and then erasing the defective one. There is no way in the GUI to reattach a text to a different entity, and though the 2019 Ruby API provides a way, someone has to identify where the text should attach. That is really no easier than recreating the leader text. So the main benefit of this kind of fixup is to reveal the original contents of defective texts that need to be recreated or dropped. Since human intervention is required in any case, that could be done just as well by printing the text strings to the Ruby Console.
If there are more than a few, relocating groups or component instances with bad transformations by placing them at the origin may create a mess of them all piled atop each other and whatever was legitimately at the origin. They won’t destructively interact, but the will be follow-on work separating them and then putting them back where they belong. There is no way in any of the fixup snippets to identify which entities were relocated vs originally at the origin. Again, this is left as followup work for the user.
This is admittedly opinion and personal workflow, but I don’t see much advantage in running a script to deal with errant construction lines and points vs just erasing all (a single GUI command) and regenerating the ones you really need. I’ve seen some models with dozens of construction lines going every which way. Frankly they become useless because one can’t easily tell which ones are supposed to align with what especially in 3D.
Perhaps a compromise would be to put the rogue elements into a new component, that is also then removed from the scene. The scene would have no bad elements in it to cause zoom extents issue, but the Components in Model list would have a new component named ‘Recovered’, or something on those lines. If the user wants to check out what it includes, they would safely plop it out somewhere near the original to take a look.
I tried this version too. It only puts information about the five text objects, and it doesn’t fix the model. If I run John’s tidy version of my code, I can then zoom extents 10 times to get a good model.
I don’t think the model I’m testing is confidential, I’ll PM it to you, with a before and after my fix version.
Colin, As promised several days ago here’s the RBZ. I’ve added a minimal user interface and the ability to change the maximum distance that an entity can be from it’s origin.
The RBZ will install a new item in the Extensions menu named ‘SW Rescue My Model’
