Faces on faces problem
-
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.
-
@mac1 said:
If you want to trace over each and every face that is your call.
The trace method works when I trace over any one edge of each missing face. The 'make face' plugin method requires that I first select every edge of a missing face (& of course no edges of anything else) before it will form the face.
So for me it is an easy call to make because there are far fewer steps involved. Better yet, there is no need to find & select all the edges. Depending on the complexity of the model, that can require a lot of tedious orbiting & zooming to make sure just the right edges are selected.
Advertisement