SLW210 Posted Wednesday at 09:17 PM Posted Wednesday at 09:17 PM 20 hours ago, PGia said: I exploded the polylines into lines. I also reduced the lineweight to 0, but in both cases the result remains the same. A colleague who still has an old PC with Autodesk Map 5 (= AutoCAD 2002) also confirmed that the same error occurs. If I’m not mistaken, AutoCAD 2002 is basically the same as AutoCAD 2000, so @SLW210’s statement that the "boundary" command works correctly in that version intrigues me. Yes, 2000i fails when zoomed out as well. 1 Quote
SLW210 Posted yesterday at 11:11 AM Posted yesterday at 11:11 AM The only "solution" besides zooming in I could determine, was to copy the polylines in place and use region on them, which seems to be correct in the example drawing. That should be able to be done with a LISP? Boundary.dwg 1 Quote
mhupp Posted yesterday at 12:46 PM Posted yesterday at 12:46 PM Was reading up on this too. apparently AutoCAD boundary command doesn't have a tolerance setting but BricsCAD does. That is why people opt to use hatching and then you can create the boundary from the hatch. and then delete the hatch. I'm confused since their isn't a gap/vertex at that location. 1 Quote
SLW210 Posted yesterday at 02:33 PM Posted yesterday at 02:33 PM It's supposed to use the HPGAPTOL as far as I know. This has been an issue for sometime, now that I looked back into from a few years ago, this problem also occurs with Hatch command. I just tried Boundary and Hatch on a closed polyline object at Zoom Extents and got ... Quote Hatch - Boundary Definition Error A closed boundary could not be determined. There might be gaps between the boundary objects, or the boundary objects might be outside of the display area. Try one or more of the following: • Zoom out until all boundaries are visible. Then specify a new pick point. • Cancel the command and modify the objects in the boundary to close the gaps. • Confirm that the XY plane of the UCS is parallel to the plane of the boundary objects. • Specify a larger value for the hatch scale or use the Solid hatch pattern. • If precision is not needed, increase the Gap Tolerance setting. And despite the first instruction, Zooming In resolved the issue. I normally resolve this with Hatch by using Select Object, maybe Hatch, Select Object, delete the Hatch and keep the Boundary could work for the OP. @lastknownuser's post brought it back to my memory. There is a thread around from a while back on this issue and needing to use Select Object option for Hatch. 2 Quote
PGia Posted 16 hours ago Author Posted 16 hours ago I had no idea about this issue. Many thanks to everyone for the information It really seems that this is AutoCAD’s ancient problem — known since the end of the previous millennium and still unresolved in this one. In any case, it doesn’t seem to be something easily approachable for Lisp programmers, since it is not easy to find published code aimed at solving this AutoCAD deficiency. Quote
mhupp Posted 13 hours ago Posted 13 hours ago (edited) 3 hours ago, PGia said: In any case, it doesn’t seem to be something easily approachable for Lisp programmers, since it is not easy to find published code aimed at solving this AutoCAD deficiency. Idk about that this is a super simple lisp that will allow you to select multiple entites. But if they aren't within the fuzz distance of each other they wont connect. ;;----------------------------------------------------------------------------;; ;; Copy Boundary Entities to join as a single polyline fuzz is 0.1 units ;; https://www.cadtutor.net/forum/topic/99146-boundary-command/ mhupp:06/04/26 (defun C:CBoundray (/ ss ss1 obj) (setq ss1 (ssadd)) (while (setq ss (ssget '((-4 . "<OR") (0 . "LINE") (0 . "ARC") (0 . "LWPOLYLINE") (-4 . "OR>")))) (foreach obj (mapcar 'vlax-ename->vla-object (vl-remove-if 'listp (mapcar 'cadr (ssnamex ss)))) (vla-copy obj) ) (command "_.PEDIT" "_M" ss "" "_J" "0.1" "W" "0" "") ) (princ) ) Edited 12 hours ago by mhupp Quote
BIGAL Posted 10 hours ago Posted 10 hours ago The issue of zoom in Acad and a lisp has been known since I think Acad existed, I know at times have had to use ZOOM C scale to get lisps to work, There may be a way around the problem perhaps using Boundingbox but I certainly have not tested. Quote
lastknownuser Posted 1 hour ago Posted 1 hour ago Just to add something more from me, as I did try to understand this problem as much as I could back then when I was working on my solution. Boundary command probably uses Pixel-Based Areas (Boundary Fill) method, that's why you have to see whole area on your screen. You can google what that is and how it works, but it makes sense to me considering there is a precision problem depending on "zoom" level. As for Hatch, it works the same for "pick points" method (boundary command + add hatch for that polyline), but if you choose "select objects" then it works as completely different method (just math without graphics part) and that's why its more accurate in this example. It all depends what you have as starting variables and what you need in the end. If you can, and its not a problem to select all lines, then CBoundray function from post above will work okay. This works like the Hatch by selecting objects... Of course clicking just one point inside area is simpler and faster, but can give wrong result because of its limitation. And I don't think its an issue with Autocad, its just a method that has its limitation. And it actually works really good otherwise, if you think about it, considering how much zoomed out you have to be and have a short segment to get the error. For example I work with topology, and have area centroids, and I needed to work some analysis with polylines for certain areas. In 99% cases boundary command was good, but with large areas with small boundary segments (like in OP example) I had this problem and needed to avoid it. 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.