Hybrid parallel

[Steven P]

On 10/20/2025 at 12:25 PM, PGia said:

Hi again.

This may also happen to others: sometimes I have two polylines and I need to get something like a common parallel to both. A sort of hybrid parallel from the original two.

Is it possible that this topic has been discussed in the history of this forum and there is a LISP to solve this problem?

 

Thanks in advance.

 

I guess the solution is to programme how you currently do this - what is your manual method?

 

As for a solution, haven't looked how SLW210 does his but might expand MHUPP to use both polylines and find the mid points using all verticies.

[mhupp]

I guess you could do like

(setq i (+ i 0.01)) 16 vertex poly would then create a 1600 vertex poly

 

And then run overkill on the created polyline to remove all collinear vertexes.

[PGia]

2 hours ago, Steven P said:

 

I guess the solution is to programme how you currently do this - what is your manual method?

 

As for a solution, haven't looked how SLW210 does his but might expand MHUPP to use both polylines and find the mid points using all verticies.

 

Basically I try to draw a polyline equidistant to the reference lines.

To do this, I draw perpendiculars from each point of each polyline to the closest segment of the other. Sometimes several points are concentrated in one of the polylines while in the other polyline there is only one long segment. In these cases, I draw all the perpendiculars that intersect that long segment, but for the last point, I already draw a line to the end of the long segment. When the perpendicular from a point goes to the next segment to which the previous ones were in the opposite polyline, then the perpendiculars must continue being made from the opposite polyline.

I suppose it is a bit complicated to explain and understand, so I attach images of what I mean.

 

 

My method isn't perfect, but it's pretty close.

I thought there would be a better method, one that would be more geometrically rigorous than mine.

 

As for Lee Mac's code, I must thank him for sharing his knowledge and his great code I've tested it, and the result is pretty close to what the true axis between the two polylines should be. But it still deviates in the pivot areas. Also, the result varies depending on the order in which the polylines are selected, and this isn't good. A robust method should produce the same result in both cases.

 

My idea was that it should be possible to obtain an axis in which any perpendicular to it is equidistant from the reference polylines.

 

But I'm starting to think this isn't so easy.

Edited Thursday at 03:27 PM by PGia

[SLW210]

Can you post a drawing with your manual center line?

 

I always pick in the same direction, never noticed the line was different if selection reversed, I'll see if I can find out why.

 

Your examples are much more extreme than anything I would have, could you say what those are and how they are generated?

[PGia]

21 hours ago, SLW210 said:

Can you post a drawing with your manual center line?

 

I always pick in the same direction, never noticed the line was different if selection reversed, I'll see if I can find out why.

 

Your examples are much more extreme than anything I would have, could you say what those are and how they are generated?

 

I've attached a small example drawing.

I've tried all the codes: @roy437, @Lee Mac, @mhupp and @SLW210 

The SLW's code seems to return the same result as Lee Mac's.

I've run each command twice, changing the selection order of the polylines, and saved the result in a single layer. As you can see, none of them return the same axis when the selection order is changed. Also, in some turns, there are significant deviations from the "real" axis. The problem is that my manual method also doesn't capture the real axis, although it's quite close, and in some turns, it also deviates slightly.

My axis is also drawn (in the red rectangles) on the "myaxis" layer, and I've left the perpendiculars I used to calculate it in green.

AxisExample.dwg

[mhupp]

Why there is deviation depending on selection order at least for mine. the lisp looks for the poly that has the most vertx and uses that to calculate points off of. if the polylines have the same number the it goes by selection order. 

I suspect all of these lisps fall short because the points are only being calculated from poly1 to poly2. were your manual way the other half of the points are need from poly2 back to poly1.

 

So you need to run it twice

get all the vertx mid points from p1 closest to p2

get all the vertx mid points from p2 closest to p1

 

The hard part the hard part is then puting them in the right order to draw the mid polyline correctly. im setting the first point and then getting the closest point, should work for what you want to do but could give 0 length segments or out of order. 

 

-edit

added in @SLW210 test if for selecting polylines

;;----------------------------------------------------------------------------;;
;; POLY AVERAGE between polylines, Finds the mid point avg between close polylines donut shape
(defun c:CLOSEPOLYAVG (/ sel1 sel2 ent1 ent2 i ptv ptc mid pts polylst)
  (setq ent1 (car (entsel "\nSelect first polyline: ")))
  (if (not (and ent1 (= (cdr (assoc 0 (entget ent1))) "LWPOLYLINE")))
    (progn (princ "\nInvalid 1st selection.") (exit))
    (setq ent1 (vlax-ename->vla-object ent1))
  )
  (setq ent2 (car (entsel "\nSelect 2nd polyline: ")))
  (if (not (and ent2 (= (cdr (assoc 0 (entget ent2))) "LWPOLYLINE")))
    (progn (princ "\nInvalid first selection.") (exit))
    (setq ent2 (vlax-ename->vla-object ent2))
  )
  (if (and ent1 ent2)
    (progn
      (setq pts '())
      (setq i 0)
      (while (<= i (fix (vlax-curve-getEndParam ent1)))
        (setq ptv (vlax-curve-getPointAtParam ent1 i))
        (setq ptc (vlax-curve-getClosestPointTo ent2 ptv))
        (setq mid (mapcar '/ (mapcar '+ ptv ptc) '(2 2 2)))
        (setq pts (append pts (list mid)))
        (setq i (1+ i))
      )
	  (setq i 0)
      (while (<= i (fix (vlax-curve-getEndParam ent2)))
        (setq ptv (vlax-curve-getPointAtParam ent2 i))
        (setq ptc (vlax-curve-getClosestPointTo ent1 ptv))
        (setq mid (mapcar '/ (mapcar '+ ptv ptc) '(2 2 2)))
        (setq pts (append pts (list mid)))
        (setq i (1+ i))
      )
	  (setq polylst (sortpts pts))
      (setq Flag (if (= (vla-get-Closed ent1) :vlax-true) 1 0)) ; Get closed status
      (entmake
        (append
          (list
            '(0 . "LWPOLYLINE")
            '(100 . "AcDbEntity")
            '(100 . "AcDbPolyline")
            (cons 90 (length pts))
            (cons 70  flag) 
          )
          (mapcar '(lambda (p) (cons 10 p)) polylst)
        )
      )
      (princ "\nNew midpoint polyline created.")
    )
    (princ "\nSelection error.")
  )
  (princ)
)
(defun c:CPA () (C:CLOSEPOLYAVG))  
(defun sortpts (pointlist / pts-sort current next)
  (setq pts-sort (list (car pointlist)))      ; Start with first point
  (setq pointlist (cdr pointlist))               ; Remove it from list as 
  (while pointlist
    (setq current (last pts-sort))           ; Get last point in sorted
    (setq next
      (car
        (vl-sort pointlist
          (function
            (lambda (a b)
              (< (distance current a) (distance current b))
            )
          )
        )
      )
    )
    (setq pointlist (vl-remove next pointlist))  ; Remove selected point
    (setq pts-sort (append pts-sort (list next)))    ; Add to sorted list
  )
  pts-sort
)

 

-edit 

follows your rough but there is one place it deviates a little since your line is longer (left side)

Edited 6 hours ago by mhupp

[SLW210]

I tracked the issue, pretty much what @mhupp stated, it just does it different depending on selection 1 and selection 2.

 

I think at least part of that issue was using vlax-curve-getPointAtDist  and/or vlax-curve-getClosestPointTo changes according to the first selection. Normally good enough for most people.

 

I made headway trying to get the LISP working similar to your manual method, it's fairly good, the main issue is on some polylines, even with your method an actual decision on what is the best line(s) at certain spots is needed. The new LISP I worked on, seems to be pretty good no matter the selection order on all but the long rectangle shape. Working or not, I might go ahead and post what I have Monday when I return to work.

 

I worked out manually why selection order on the one with the straight through the corner and reverse selection there is a little dogleg shape, there is a decision to be made there, I did it both ways and matched mine and Lee Mac's shape.

 

It will be Monday when I get back to work before I have time to keep testing.

 

I wish I had found Lee Mac's code, somehow I missed that one. I would have never made mine, for some reason those rolling ball LISPs never worked out very well for me.

[mhupp]

38 minutes ago, SLW210 said:

I wish I had found Lee Mac's code, somehow I missed that one. I would have never made mine, for some reason those rolling ball LISPs never worked out very well for me.

 

that gread only updates when you move your mouse. so i guess its just in there for testing/visualization. couldn't imagine having to wiggle the mouse to get commands to complete.

[GLAVCVS]

Instead of perpendiculars: why not try it with...

...bisectors?