I have attached one of the floors from @NewThinking2 (Scott Baker’s) RiverArch model.
Its top face is cracked along two lines. But I have managed to make it Solid, according to Solid Inspector 2 and SketchUp itself, which recognises it as a Solid Component.
I’ve checked the corners with the Utilities Query Tool, and can see that a few of the corners and some edges are ‘off flat’ by almost one thousandth of a foot over a span of several hundred feet. Most of the floor is at an exact height of 931ft. A few corners I measured are at ~931ft, and when measured with the full four decimal place accuracy have somehow got slightly shifted to 931.0009 ft.
If I place the Rotate tool on all the subfaces, they all show with a Blue protractor, indicating that SU thinks they are normal to the blue axis - but they aren’t quite.
How can I ge the top flat and one face, as the bottom already is?
- selecting a corner or edge that was high, and moving on blue, to level it with another corner at exactly 931ft. All that did was form other more numerous cracks without fixing the main one(s).
- selecting one of the just-off-plane small faces, and rotating about the crack line to get it flat either on the red axis, or on the main flat face
- unhiding the cracks, and trying the plugin Unwrap and Flatten Faces on the three not-quite-coplanar faces, to no effect.
What else might I try to fix the cracked top face short of redrawing the whole floor or face?
F91 floor only - top face cracked.skp (235.1 KB)
Indeed, after my successful attempts to make the component solid, I now see that there is only ONE POINT that isn’t exactly at z = 931ft, highlighted with the text tool in the revised attached file.
This has been a recurring problem for Scott and me - large faces that are almost infinitesimally off flat won’t form a single face.
Is there room for a Feature Request to make Sketchup slightly more tolerant of such small errors, and/or to have it round all corner positions (at least on flat or vertical faces) to the average for the whole face?
Because the bottom of the form is entirely coplanar you can simply take a side view and with perspective OFF use a fence to select the flaky top surface and all of the vertical parts - then ‘delete’.
Then PushPull the remaining bottom face up 2’.
The tolerance issues are sidestepped.
There seem to be a few ‘chamfered’ floor edges.
Recreate those using PushPull etc as needed…
Thanks. I’ll try that - it’s a method I’ve had to use before, on lower floors.
But it’s usually the creation of the chamfered edges that crack the faces. Even a move of a top or bottom edge along the red or green axis can crack the main face. I don’t quite know why - seems to be internal to the way SU works, rather than careless drawing or movement.
Tried instead deleting the top three face sections, then creating a large rectangle perpendicular to blue axis, with one corner on the intersection of two of the longer upper edges of the floor, then moving it down 1/100 of an inch, then Intersect faces with context.
That got me a single face top floor, after I’d deleted the outer extra bits, and deleting the face inside the inner openings…
But just doing that and nothing else cracked the bottom face.
This is weird. SU is NOT behaving as I think I should expect. Why on earth should changing the top face affect the bottom at all?
I think this is just buggy.
I will try again, TIG, with your suggestion, but it too on previous experience is likely to fail when I bevel the sloping edges.
Perhaps some of the problems you are having stem from the fact, the model is a quarter mile from the origin.
I moved the slab to the origin and it seemed to behave a bit better.
Also, there are so many odd dimensions in this thing. I agree that shouldn’t be a factor but one has to wonder.
F91 floor only - top face cracked shep.skp (131.7 KB)
I used Vertex tools on the top face and Make Planar. Then deleted the offending edges and removed a couple of faces.
No tildes in the coordinates now.
F91 floor only - top face crackedBox.skp (143.1 KB)
It’s a VERY big building. The origin is in fact at one of the ground level corners. But it’s useful to know that moving the origin temporarily helps.
It’s very peculiar geometry - basically, it starts from a semicircular cross-section outer shell of radius 1000’ E-W, with faces sloping in from 800ft N-S at the bottom to 400ft at the top, with a part-circular, part elliptical inner shell surface. So the dimensions get to look very odd very quickly on any one floor.
I didn’t know about those tools - I’ll have to try them.
Will have a quick look at your result tonight, but leave trying those tools myself until tomorrow - it’s getting on for 2am here in UK.
Seems it has certainly done the trick.
Thanks, both, for looking and suggesting ways to get the result we want.
I’ll just add in a little gif showing you what I did to fix it, using Thomthom’s Vertex tools.
Note my use of Fredo’s Curvisard to break the faces, I find it a very handy tool for fixing many edges.
Thank you both! This was a great help and it is in the main model now.
You know, I think I just got lucky on the first try in my earlier post.
After taking another look or two, I think there is some rounding error at work. I don’t know what operations could be causing this.
If you switch to decimal inches and turn precision all the way up you’ll find the bottom vertices are not completely co-planar either and most vertical lines are not exactly 24".
Have there been intersection done with this component, and has Sketchup offered to “fix” you model?
No intersection, AFAIK, and the 2ft was originally generated by a pushpull operation with a typed value of either 24 )inches) or 2’.
Scott said that SU quite often offers to fix his model when saving or closing. I’ve not had it do that on me.
SU is behaving inconsistently in its rounding, it seems to me.
It’s often said in this forum that it merges vertices and lines within one thousandth of an inch of each other. If so, why did several of the edges (before I cleaned up somewhat) have as many as five or seven entities almost on top of one another?
And when all the vertices on the top face (now it’s planar) are exactly 931’ on Z, why does the top face break when you move a top or bottom edge along an axis to make a sloping end face?
The bottom edges certainly are not coplanar.
The only reason the bottom face hasn’t fractured is the bounding edges are still within SU’s tolerance.
Why would one fish for errors using decimal feet?
One thousandth of a foot may sound like impressive precision, but it equates to 0.012”
In terms of SU geometry being off-axis or non-coplanar, missing the mark by 0.012” is no small amount.
Errors accumulate and when one infers to or builds directly upon errant geometry, the errors proliferate.
Here’s a cleaned up version of the model wherein the top and bottom edges are truly coplanar.
Be aware the vertical edges could use straightening up as well.
One could do so by the same method used to first ‘flatten’ the bottom and then the top faces…
• Move endpoint locked to z-axis >
[,,0] > Enter
F91 floor only - top face cracked_FIXED_Geo.skp (106.8 KB)
Just to verify, here’s a report of the vertices via @TIG’s plugin, Export Vertices to CSV v1.3
Vertices_Report.txt (4.4 KB)
Thank you, Geo, for looking at this.
Perhaps misguidedly, but when I tried four-decimal place inches, I couldn’t make sense of the large number of inches. But in retrospect, you are right - if the SU tolerance is 1/1000 inch, I was using too large a unit.
I hadn’t even looked to check these. Since they were drawn initially using PushPull, why and how do they go out of vertical?
And why, when I move an edge on red or green axis to give a slope to the floor edges does it frequently crack the face? I usually can avoid it by moving ‘on face’ to a defined endpoint or edge, but on-axis moves usually don’t work, even if the face appears both a single face, and apparently ‘flat’,
quote=“Geo, post:12, topic:58377”]
here’s a report of the vertices
I see just one that isn’t on z=0.0000 or 24.0000 - at 1998.577462 701.213452 1.175618
Wonder where that is?
Did you move the whole floor to the origin to fix it?
Is the fact that we are drawing (Scott) or editing (me) the floors ‘in situ’ and that’s hundreds of feet from the origin causing some of these problems in the first place?
And could we have used move to
[,,931'] or [,,929'] instead?
Hi John, I have just read this thread without actually looking at your model in SketchUp. But apparently the bottom face wasn’t coplanar. And even if it were, when it wasn’t completely 100% horizontal in the first place, then push/pulling it to thickness of the floor generates 24" edges perpendicular that can’t be vertical either. The bottom wasn’t horizontal.
I doubt if SketchUp is to blame when creating “perpendicular to face” edges.
I now looked at your originally uploaded model here, just to see what might have happened.
The yellow marked Z-values are from some of the endpoints in the bottom face. They show that the bottom can’t be horizontal. To see if it’s not coplanar (lazy to calculate consistent floor slope) I copied the bottom face to above your model. Then added an outstanding edge for scaling purpose (see blue selected edge). I then selected this edge plus face and scaled it twice 100x to exaggerate the “not being coplanar” fact of this face. In side view you can see that there is something wrong with coplanarity. see:
Pulling up the not horizontal not coplanar face (the scaled version!) results a segmented face at the top (first image)
Your original bottom face may have been pulled up this way, all within tolerance but with quite some hidden faults that lead to more things going wrong when continuing with this geometry.
Here, where a slope meets a vertical.
I moved all the geometry such that one corner was at the Origin.
And then attempted to rotate the geometry such that bottom face was parallel with the Ground Plane.
Positioning the bottom face parallel with the Ground Plane proved impossible, because it’s wonky too.
I had to settle for getting just two edges, connected at ~right angles (3 points) parallel with the Ground Plane.
With that, I began moving all the other endpoints vertically to
Typing ‘0’ is easier than typing ‘24’ so I moved the geometry down 24" and used the same process to fix the top.
Accuracy is a matter of technique.
Distance related OpenGL rendering issues begin to occur way out where the buses don’t run.
Miles matter, hundreds of feet from the Origin, don’t.
Of course you could.
The only reason I moved the geometry to the Origin was to make it easier to interrogate.
Many thanks for the explanation.
So we just need to be much more careful when making changes to what started as a rectangle drawn at the right level, using the up arrow key modifier to the Rectangle tool to make it draw perpendicular to the blue axis.
I find it slightly inconsistent that one can have an apparently single face, with corners very slightly off level, but within tolerance, and SU still shows a blue protractor when you start to do a Rotate with the ‘on-face’ inference.
SU tolerates very small angles of ‘off horizontal’ but makes a face, then cracks the face with a small ‘on axis’ move, while all had previously appeared well.
As you say, once the geometry goes even slightly off dead flat, errors compound.
Thus non Coplanar thing is not just me then?! I posted my frustration with this and got the following tip:
“There’s an extension called Archtiect Tools has a function to Flatten geometry or Move Geometry to “Z” which I use a lot to overcome the issues you describe. Edge Tools has a function to detect and remove stray edges nad close gaps. Cleanup3 can simplify geomtery.“
I haven’t tried this but hope it helps. The proposed workarounds you’ve gotten so far seem far too difficult.
I should credit the lister this tip came from… AK_SAM…