Two (for the moment) quick questions about Validity Check. I’ve seen a number of posters suggest they turn it off (@Box comes to mind).
I’ve had a number of models that have been more “broken” by it than fixed. What are the pros and cons of “auto fix”?
Also when I do use it and look to see what it’s fixed, like this for instance. What do I do with this information to see what it has "fixed? Do I enter that into the ruby consol? Or What?
I don’t believe I have ever said turn it off, I have said it can break things and I don’t use the autofix function, but I do use it.
Thanks Box, that has cleared everything up for me! LOL
I can assure you the information given in the results box may as well be written in ancient amaraic for all the good it does me.
I get that, the only way I know whats been “fixed” is when I look closely at my model and discover missing faces.
So is it good or bad?
Thoughts?
I personally leave it to check but not autofix, I like to know that there is something that needs fixing, by SU’s standards, but don’t like it to fix it without me knowing, because sure enough it removes faces.
I receive lots of models to fix that pop up this message, which tells me the OP has turned it off, but it alerts me to certain possible problems.
I think on the whole it is a good thing, but it should be fixed to understand small faces and it should give results in plain English.
Good or bad is a bit black or white, I’m not sure I would miss it if it wasn’t there.
I’ve fought with this for years, and I wish someone could explain the algorithm it works from. And translate the “ancient amaraic” so if I missed it, I could see what got changed. Heck, if I knew what was getting “fixed”, I might not make the mistake, to begin with.
So @Box, what is your criteria for letting autofix, fix your models?
My Models? Never needed it. 
I know this got directed at Box, but surely someone can add more insight to this? @TheOnlyAaron, @DaveR
I have SketchUp set to perform a validity check when saving a file (but not at any other time). When SketchUp reports a problem, I let SketchUp “repair” the model. Then I run Solid Inspector2 to see what damage has been done (98% of the time, the model is worse off after the repair has been performed). Then I manually fix the model (sometimes trivially easy, sometimes rather tedious). I do want SketchUp to resolve the internal geometry problems it detects, because otherwise it’s a ticking time bomb that will probably cause more problems in the future.
Regarding the understandability of the repair messages, that is an interesting software design problem (speaking as a professional software engineer). There are at least two difficulties:
More user-friendly descriptions can probably be devised.
Identifying the affected edge and face entities in a textual message is more of a challenge, I would say. Edges and faces do not have user-assigned names (and even if such a feature were available, I would not want to invest the time in giving every single edge or face a unique and meaningful name). Thus, SketchUp reports internal identifiers for the affected entities, which are meaningless to the user.
One enhancement suggestion I would have is for the “repair” process to highlight in some bright color the edges and faces which are going to be affected, BEFORE committing the change to the model geometry. Let the user orbit around to look at the “proposed repair.” It might be helpful for the user to see “ahh, that little fillet in the corner is going to be wiped out, OK, good to know.”
Thank you Tom, so far that’s the best insight as to what’s going on during a “fix”.
I leave these settings turned off most of the time. CleanUp3 will do a validity check and I use that fairly often. I have a few tiny components I use in some of my models that I know will fail the validity check. They work fine for what I need even knowing they are problematic and it’s never seemed worth my time to make new ones so I just skip it.
I wouldn’t expect it to wreck your models unless you have a bunch of smaller, highly detailed shapes.
This can be an issue with The Dave Method, once you have deleted the large copy the original small one can be decimated by Validity check. Or if you work in meters and scale down to mm to export for an exact 3d print, the scaled down version can also be ruined. (often seen as unprintable by the printer software too)
Which is why we recommend working larger and exporting at the correct units.
I don’t find validity problem related to using the Dave Method. Generally it happens for me when I create bad geometry.
Doesn’t always happen but can happen.
I’ll add the model for you. It should ask you to fix when you open it, say later and it should be ok, then fix and it will break.
Thread Test.skp (221.6 KB)
Well darn it, I’m glad I posed this question, it’s getting interesting.
If you select the geometry within the large component and make it a group, then delete the large one and explode the small one, you will have a solid group that will survive validation.
We’d like the number to be a persistent ID number so a Ruby search of entities could find it by pid.
Problem with the auto mode is that it’ll often delete the object so a subsequent search would be fruitless.
This will likely not happen.
Ie, this formally logged request was denied, tagged “wontfix” (aka will not do) and closed …
