Faces on faces problem
-
<[quote="livemixer"]Using SU 7, I often import dxf files that are missing faces & have extraneous lines, something like this:>
...If you select one of those extraneous lines you will note it is not segmented as you would expect. Change your model units precision to .xxxxxx and use the text tool and you will note a very slight ~.00003 difference in the x dimensions between right and left even thought the edge display " color by axis" shows all at least parallel to the green axis.
I used the move tool so difference is .0000, used the make faces plugin and all faces formed as I would expect. Of course I had removed the extraneous lines as noted above.BTW the way I made the changes: Selected the right end of large rect and moved so error is zero; selected the right or left slats as a group and moved bottom ends to zero error; never touched the window. This made the large rects four corners zero error but the slats bottom zero and tops still with the same error=> tops tipped in. I tried face formation twice and worked ok. Why ok now? I have guess but too much analysis to prove.
You MAC may not work the same because possible difference the operating system numerical accuracy. TIG maybe can answer. If it does not then try correcting alignments in total.
-
-
@mac1 said:
Change your model units precision to .xxxxxx and use the text tool and you will note a very slight ~.00003 difference in the x dimensions between right and left even thought the edge display " color by axis" shows all at least parallel to the green axis.
I used the move tool so difference is .0000, used the make faces plugin and all faces formed as I would expect. Of course I had removed the extraneous lines as noted above.Very clever! I always suspected that some kind of precision issue was at the heart of this problem, but I never thought about using the text tool at max display precision to explore it. Thanks very much for that tip -- it will come in handy for exploring other issues as well.
Once you called my attention to it, I noticed there was also a similar x axis difference top to bottom everywhere except on the vertical edges creating the leftmost outside face, so some of the endpoints were offset as much as .000006" along the x axis from those reference points (2.250000" for the front edge & 0.750000" for the back one). So I guess the moral here is to pick one reference point & use it for all the endpoint moves one wants to be aligned perfectly along an axis, right?
What I find most interesting about this is that the trace line technique works even though the edges are not in perfect alignment. It somehow causes all the connected edges to "snap" into alignment, at least if they are close enough to aligned to begin with. I have no idea what tolerances are involved for this to work reliably, but judging from my model I'm guessing it must be greater than .000006". Any thoughts on that?
-
@livemixer said:
What I find most interesting about this is that the trace line technique works even though the edges are not in perfect alignment. It somehow causes all the connected edges to "snap" into alignment, at least if they are close enough to aligned to begin with. I have no idea what tolerances are involved for this to work reliably, but judging from my model I'm guessing it must be greater than .000006". Any thoughts on that?
there's a tolerance built into sketchup which will allow faces to form.. i never explored enough to find where exactly the tipping point is but i know it's there..
but, if you take your model then scale it up a few hundred times, you'll get the 'there's a problem in your model.. should i fix it? " (depending on how your prefs are set up)
in which case, sketchup will add hidden lines in order to break the surface down into multiple surfaces which fit inside tolerances
-
example --
i formed faces on the model then scaled it up 1000x.. then tried to save it which is one way to trigger the 'don't panic' message..
so, since the scaling has caused the minuscule errors to become larger errors, here is the fixed result :
point being -- be very wary of bringing in models from other software.. ESPECIALLY if you didn't draw it in the other software and convert it yourself..
i always redraw DWGs that i'm given by architects etc.. It may seem like more work but once you start finding these tiny errors in their files, it becomes much more work fixing them instead of just drawing it fresh..
-
another popular sketchup rant / bug report is "intersecting faces sux! sketchup doesn't work right!" (or whatever).. but the reality is the user has a bad model but they're trying to blame sketchup..
here's your model with faces and not scaled.. i will intersect the orange box with the existing..
so now, since i've divided the face up into smaller pieces by way of that intersection, i've messed with the face forming tolerance (i.e.- on the non intersected version, the face was still forming because it was out .0005" over a length of 6'... but the intersection has caused it to be out .0005" over a length of 2' which is outside of tolerance .. (i'm making these exact numbers up.. just trying to get a point across))
-
@unknownuser said:
another popular sketchup rant / bug report is "intersecting faces sux! sketchup doesn't work right!" (or whatever).. but the reality is the user has a bad model but they're trying to blame sketchup..
I think there is some justification for blaming SU. For one thing, it's a bit silly that the tolerance for creating faces from nearly aligned edges is below what the app can display -- I've tried zooming in on models like my example to extreme levels & never reached a point that shows that the lines don't intersect. Scaling the model up by extreme factors helps, but there is always still some minimum distance below which this becomes a problem.
At the least, the display should always be zoomable in to resolve the minimum distance the app supports. Anything below that should be considered the same point & all points in that neighborhood should be merged into one vertex without users having to do anything to cause it.
As it is, it seems that at least sometimes the maximum available display precision is greater than the precision of the underlying calculations, & that is more than a little silly.
-
Why should one be able "see" an error like this? On command SU should readily flatten or straighten to grid without the user having to study the intersections visually. It also seems silly that to draw something (macroscopic) one should need to, or want to, observe every corner at (virtual) microscopic levels.
Imported dwg from 2d applications has the same issues, though probably not as bad. So is it a CAD user error, CAD application or dwg format shortcoming or SU improperly importing the file? And SU not being able to fix it is worse. The plugins don't work that well on this either. Best is to simplify and cleanup everything before importing. Of course for a shape like this it could be drawn-up rapidly.
-
@livemixer said:
I think there is some justification for blaming SU. For one thing, it's a bit silly that the tolerance for creating faces from nearly aligned edges is below what the app can display -- I've tried zooming in on models like my example to extreme levels & never reached a point that shows that the lines don't intersect. Scaling the model up by extreme factors helps, but there is always still some minimum distance below which this becomes a problem.
At the least, the display should always be zoomable in to resolve the minimum distance the app supports. Anything below that should be considered the same point & all points in that neighborhood should be merged into one vertex without users having to do anything to cause it.
As it is, it seems that at least sometimes the maximum available display precision is greater than the precision of the underlying calculations, & that is more than a little silly.
nah.. there's no way our screens can show the real precision.. sketchup can calculate down to a millionth of a millimeter.. our screen can't come anywhere close to that type of precision.. and even it it could, our eyes could never ever see it without using some high powered microscopes..
if you have 96ppi on your screen then you're looking at each pixel being ~.3mm across.. no where close to .000003 which sketchup has.. and you'd have to zoom in x100,000 in order to start seeing any gaps..
but sketchup has a good inference engine.. i've never.. and i mean never had this issue pop up when i use it's inferencing to create a drawing.. it's inferencing works at least as accurate as it's tolerance and that's what is important here..
the other issues are user mistakes and sloppy modeling..**
[edit] **..well, it's not really fair to say it that way.. there are plugins such as artisan that are moving so many vertices around which will eventually lead to one moving such a tiny amount that you could end up with an invalid object resulting in the "don't panic" message..
so things like that aren't user error.. they aren't ruby writer error.. they're just things that are going to happen eventually when all things are considered.. -
@pbacot said:
Imported dwg from 2d applications has the same issues, though probably not as bad. So is it a CAD user error, CAD application or dwg format shortcoming or SU improperly importing the file?
too many factors..
but for one.. the cad apps might have been drawn at higher tolerances.. in rhino, i could set my tolerance to say, .1mm then go on to draw something.. so everything is good and valid within that tolerance but if i put the same drawing into something which is using smaller tolerance levels then there's opportunity for problems.. whereas if i could control sketchup's tolerance then set it to .1mm ,then everything would be fine..
(and we're not able to adjust sketchup's tolerance.. it's set.. we're able to adjust the precision to which it's displayed to us.)
-
While Sketchup has a good inference engine, I can suggest one way to force a failure to generate faces:
Last night I was drafting a floor plan in Sketchup, drawing lines on a very large rectangle on the ground plane. Using various inputs including use of guides. When I reached a stopping point, I decided to delete the underlying rectangle. There were plenty of faces not formed. I was using the inference the whole way. Occasionally faces didn't form due to line overshoots because, instead of using a guide, I just drew a line out to the general area where another was going to intersect.
I actually went through the process of selection and intersection on the base rectangle, Sandbox Drape, Superdrape, and ThomThom's Cleanup tools. After all of that, what solved it was the traceover routine.
It was like the drafting completely ignored the rectangle beneath it.
The above methods may not be the recommended workflow, but it demonstrates or hints at the precision question. -
oh.. right.. that whole tracing on a face thing..
are the vertices actually being placed in the wrong position though? or is some other problem within sketchup which is causing the face not to form?
next time that happens, set the accuracy to .000000mm then measure their heights to see if they were improperly positioned..
but i think the numbers will be accurate and that your example has to do with sketchup sometimes having problems forming a face on top of face (or forming a face in general at times).. which is different than faulty inferencing..
-
I cannot answer the placement of vertices question. I have seen this stuff often over the years. And, I work with no profiles or endpoints displayed.
I will check that-- Yep, I just had the default "precision" on. You only get 3 zeros max. My template is basic, feet and inches. -
Yes, over time I have not gotten a great deal faster, but learned to be more careful. I am mindful of being accurate, or trying to be precise, because small errors become cumulative, and somewhere down the line you will be wondering what went wrong and where, only to discover it is everywhere. You would need some hellacious plugin to make a global, one button correction for loose practices.
-
just some thoughts with no proof:
When you trace a line it is not forcing any snapping but a recalcuation;
Even though the inference engine is used just the simple physical action of clicking the mouse causes small torques movements if one is not careful and cause a bad point. Mouse sensitivity settings may come into play here;
I think the display precision is related to the 32 bit float theoretical 71/2 digit percision. If/ when SU goes to a 64 bit that will be fixed?;
The results can be very much dependent on the algirothm Su uses to declare in plane. It has probably been around for a long time and no one has really looked closely for a more accurate approach? -
i remember this thread
http://sketchucation.com/forums/viewtopic.php?f=15&t=37042
(can't connect the dots)
download steve's model in the first post and you'll see there are face forming problems..
â˘switch to wireframe mode..
â˘select all the lines he's traced so far then move them to the side..
â˘switch back to a face mode..
â˘now, it's not hard to fill in the problem faces.. (though even in this circumstance, i'll sometimes run into a problem making faces.. but the model does have a couple of missing lines as well)but set the units to mm at highest precision.. and measure all the vertices etc.. they are all perfectly flat (perfect being .000000mm) beyond that, it doesn't matter..
but also notice he has triangles in a lot of spots and even those won't form faces.. and a triangle should form a face even if there was an inference error..
point being.. i think the issue raised by mitcorb and the one with the model in the thread are two separate things.. livemixer's model has non coplanar elements which i feel is ultimately attributed to user error.. steve's model (and tim's example) are showing something else that i feel is sketchup's fault.. it obviously should be forming faces in those scenarios.. but it's not a fault due to bad inferencing/placing inaccurate points..
-
@unknownuser said:
nah.. there's no way our screens can show the real precision.. sketchup can calculate down to a millionth of a millimeter.. our screen can't come anywhere close to that type of precision.. and even it it could, our eyes could never ever see it without using some high powered microscopes..
I must respectfully disagree with you about that. If SU treated objects as bitmaps, your argument would be true. But objects in SU are vector based -- they are just sets of coordinates in a mathematical 3 space that are mapped onto the two dimensional pixel grid of the screen. That means they are resolution independent, so at least in theory you should be able to zoom in far enough that a 0.000001 mm long entity maps to hundreds of pixels on the screen ⌠or zoom out far enough that a 1000 m one maps to a single pixel.
Plus, since the 3D space must of necessity be mapped onto a 2D screen, any one point on the screen maps to arbitrarily many points along the dimension the screen cannot display. That means there will always be some uncertainty about where along that dimension a point lies. The inference engine tries to resolve that uncertainty for the user by looking for nearby entities to use as inference points, but since many different entities at greatly different distances along the undisplayed dimension may map to the same few or even just one screen pixel, it may be impossible for a user to tell which point the inference engine has chosen, even with all the visual aids the app provides.
Worse, when many different inference points are sufficiently proximate, either in the 2D view or in 3D space, the inference engine may "jitter" among them so quickly that it becomes almost impossible to choose the desired one. If the proximity is just in the 2D view, users can relatively easily change the view angle or zoom level to get around that but if it is in 3D space -- & you can't zoom in far enough to get adequate separation among those points -- there is no easy workaround.
-
Couple of other comments;
1)All 3d aps have what are called clipping planes including SU, 6 total(2 bottom/top,2 left/right and 2 front/back). Outside the clipping planes rendering is not done which helps avoid the problem but a very dense model can still have problems. I have not run any test but changing those for a dense model should help the issue;
For your posted model, if one: forms the displacement vectors for say the large rect and does a triple scalar product then the determinate for it will zero if planar which it is not(zero). However, using the create face utility you can force SU to declare it to be planar or in some cases it will not( ie left most small rect. while the make face plugin will). SU uses IEE 32 bit float and as such all real number can not be represented ( for example 1/7)and the accuracy is only 7+ digits). IMHO ( putting aside user errors) the underlying problem is the algorithm to make that determination which I will guess has not been looked at in years. This is an issue with it(IEEE 745 float) and programmers must be very careful in their algorithms.
It has been pointed many times the problems with import from CAD programs and to make sure clean up is done before import to SU. There are so many variables the number of test cases to sort out what is really going one can be very large.
One just needs to be aware to this type of potential and be prepared to deal with it. After all no computer program is 100 % perfect. -
@mac1 said:
It has been pointed many times the problems with import from CAD programs and to make sure clean up is done before import to SU.
I am aware of that but it doesn't help with my problem. The dxf files I'm working with came from a commercial CD from a company no longer in existence, & the only other format on the CD is readable only by an app from that company that won't run on OS X. I no longer have a working Mac that could support an OS that runs that app, & even if I did I'm not sure it could export its 'native' format files to any format any contemporary 3D app could understand.
I don't own any other 3D app that does a better job of importing the dxf version of the files than SU 7, so I'm stuck with doing all the cleanup work with that or SU 8.
All things considered, the 'trace edge' trick is the best solution for this issue I have seen. So far at least, it only fails when the edges are far enough from coplanar that I can zoom in & see that without having to clutter up the model with a bunch of text entities at max display resolution. It often works even when the 'make face' plugin fails, suggesting that the tolerance for creating faces from nearly coplanar edges may be different depending on the tool or method used.
I'm sure you are right about much of this being the result of inadequate numeric precision in the algorithms SU uses for its calculations. That certainly isn't a user created error, except possibly in the broad sense that users need to be aware of the limitations that imposes, but personally I think that is a bit of a stretch.
-
If you want to trace over each and every face that is your call. If you use the make face plugin on the model you posted you can make all at once.
Here is some info on the accuracy although it will take some commitment to read.
Advertisement