I have a routine that creates a series of 3d LINEs for the boundary of a group of 3DFACEs.
Does anyone have an autoLisp (not visual lisp, I am using R14) that would join the 3D LINEs into a 3D POLYINE? The 3D LINEs are not in any order.
code to create 3DPOLY from 3D LINes
@marko_ribar wrote:Looking at that uploaded *.lsp and your comment, I guess that R14 doesn't work well with (function) function...
Please try this mod...
HTH.
M.R.
I spoke too soon. After further experimentation with "lins23dpoly-vanilla-foo.lsp" I found the following problems:
In the picture below the blue 3DPOLY left out one line segment. I erased several line segments around the missing line segment and tried again - the red 3DPOLY is the result. "The 3djoin.lsp" posted earlier works correctly, but erases the selected line segments which should be easy to fix.
@CADaSchtroumpf wrote:Sorry, I have an extra parenthesis after the declaration of the local variable.
I have modified the code, please reload it.
I tried your latest version and it works if you select all the lines with one window or crossing box, but if I use 2 or 3 windows or crossing boxes, I get this:
How about a different approach? Jut trace around the Lines, starting from any one of them, adding the far end of each subsequent Line found in relation to the previous one, in a 3DPOLY command, until you get back to the beginning:
(defun C:L23DP ; Lines {to} 3DPolyline
(/ lineA line1 p1 p2 p3 ss)
(setq
lineA (car (entsel "\nSelect one of the Lines to join into a 3D Polyline: ")); starting Line
line1 lineA; working first Line
); setq
(command "_.3DPOLY" ; start 3DPoly command
(setq p1 (cdr (assoc 10 (entget line1)))); working first Line's start
(setq p2 (cdr (assoc 11 (entget line1)))); working first Line's end
); leave in 3DPoly command
(while
(and
(setq
p3 p2 ; previous point for reference
ss (ssget "_F" (list p2 p1) '((0 . "LINE"))); incl. working Line & Lines meeting both ends
line1 (ssname ss 0); first in selection [meets p2 end of working Line]
); setq
(not (equal line1 lineA)); not back to beginning yet
); and
(setq
p1 (cdr (assoc 10 (entget line1)))
p2 ; far end from previous Line
(if (equal p1 p3 1e-6) ; is this the next Line's start?
(cdr (assoc 11 (entget line1))); then -- use its end
p1 ; else -- use its start
); if
p3 p2
); setq
(command p2); feed to 3DPoly command
); while
(command "_undo" "_close"); back off latest and Close [end 3DPOLY]
(prin1)
); defunComments:
You don't select all the Lines -- just one of them.
No (vl....) or (function) functions.
It doesn't matter what the drawn order of the Lines was, nor in which direction each was drawn. *
It counts on the set of Lines being closed as you have said they always will be.
It works in the WCS, but could probably be enhanced to work in a non-World UCS.
It draws the 3DPolyline on the current Layer with all current property settings.
If you have running Osnap on, as long as ENDpoint is among the modes, it will work without the need to turn them off. If you might have [for example] MIDpoint but not also ENDpoint or INTersection or NEArest, it will be misled.
It finds three Lines based on a Fence using the "current" one's endpoints, and the setting of line1 [at line 16] seems to be reliable -- the Line off the starting end of the Fence always seems to be the first in the resulting selection -- but I'm not positive that it will always be. [Some other possible selection approaches could get incorrect results depending on the Pickbox size and/or Zoom level, but this seems unaffected by those.]
In trials in your sample drawing, it sometimes ran into a problem down near the bottom -- some kind of backtracking on itself, always at the same location -- but it didn't always do it, and I haven't been able to figure out what could be causing it [e.g. I couldn't find my suspicions of a non-meeting of Line ends, or an overlap, in the area].
It could easily be enhanced to remove the original Lines.
[And it could use some of the regular enhancements -- command echo suppression, Osnap and blip controls, Layer and other property settings, etc.]
* EDIT: In further testing, I'm sometimes running into more of those hold-ups, which may be related to drawn direction. I'll keep trying to figure out what's going on.
Kent Cooper, AIA 
@komondormrex wrote:What if a user wants to make several 3dpoly with one selection set?
foo.lsp will make a single polyline from 2 or 3 different sets of lines, but they are all joined together.
foo.lsp produces the following results. I have not tried any of the other solutions.
@Kent1Cooper wrote:
.... In further testing, I'm sometimes running into more of those hold-ups, which may be related to drawn direction. I'll keep trying to figure out what's going on.
This seems to have corrected that [again, lightly tested]:
(defun C:L23DP ; Lines {to} 3DPolyline
(/ lineA line1 p1 p2 p3 ss)
(setq
lineA (car (entsel "\nSelect one of the Lines to join into a 3D Polyline: ")); starting Line
line1 lineA; working first Line
); setq
(command "_.3DPOLY" ; start 3DPoly command
(setq p1 (cdr (assoc 10 (entget line1)))); working first Line's start
(setq p2 (cdr (assoc 11 (entget line1)))); working first Line's end
); leave in 3DPoly command
(while
(and
(setq
p3 p2 ; previous point for reference
ss
(ssget "_X" ; incl. working Line & Line meeting downstream end
(list '(0 . "LINE") '(-4 . "<OR") (cons 10 p2) (cons 11 p2) '(-4 . "OR>"))
); ssget
ss (ssdel line1 ss); leave only next one
line1 (ssname ss 0); first [should be only] in selection [meets p2 end of working Line]
); setq
(not (equal line1 lineA)); not back to beginning yet
); and
(setq
p1 (cdr (assoc 10 (entget line1)))
p2 ; far end from previous Line
(if (equal p1 p3 1e-6) ; is this the next Line's start?
(cdr (assoc 11 (entget line1))); then -- use its end
p1 ; else -- use its start
); if
p3 p2
); setq
(command p2); feed to 3DPoly command
); while
(command "_undo" "_close"); back off latest and Close
(prin1)
); defunIt looks for the next Line only at the downstream end of the previous one, by start/endpoint coordinates rather than by Fence selection.
Kent Cooper, AIA
@Kent1Cooper wrote:This seems to have corrected that [again, lightly tested]:
It looks for the next Line only at the downstream end of the previous one, by start/endpoint coordinates rather than by Fence selection
Kent:
Seems to work for most line picks, but the blue lines in the attached picture when picked as the start point still cause problems. I did not check all lines, just picked lines at random.
