Topic: Bug in vla-IntersectWith (established)

[mailmaverick]

When I use (vlax-invoke obj1 'IntersectWith obj2 acExtendNone) in which obj1 and obj2 are two polylines, it gives two points of intersection whereas I clearly know that there is only one.

When I do debug of the same in watch window, X, Y and Z coordinates of both points are same.

When I take distance between the two points (I store the result of the intersectwith in a list), it gives distance as 0.0016826

Why is it so ?

[mailmaverick]

File is attached.

Following code is applied :-

Code: [Select]

(defun c:test ()
  (setq ent1 (car (entsel)))
  (setq ent2 (car (entsel)))
  (setq obj1 (vlax-ename->vla-object ent1))
  (setq obj2 (vlax-ename->vla-object ent2))
  (setq pts (LM:GetIntersections obj1 obj2 acExtendNone))
  (princ "\nNumber of intersections : ")
  (princ (length pts))
  (if (> (length pts) 1)
    (progn (princ "\nDistance between intersections : ") (princ (distance (car pts) (cadr Pts))))
  )
  (princ)
)


;;-----------------=={ Get Intersections }==------------------;;
;;                                                            ;;
;;  Returns a list of all points of intersection between      ;;
;;  two objects                                               ;;
;;------------------------------------------------------------;;
;;  Author: Lee Mac, Copyright © 2011 - www.lee-mac.com       ;;
;;------------------------------------------------------------;;
;;  Arguments:                                                ;;
;;  obj1, obj2 - VLA-Objects                                  ;;
;;------------------------------------------------------------;;
;;  Returns:  List of intersection points, or nil             ;;
;;------------------------------------------------------------;;
(defun LM:GetIntersections (obj1 obj2 ExtendOption)
  (LM:GroupByNum (vlax-invoke obj1 'IntersectWith obj2 ExtendOption) 3)
)
;;-----------------=={ Group by Number }==--------------------;;
;;                                                            ;;
;;  Groups a list into a list of lists, each of length 'n'    ;;
;;------------------------------------------------------------;;
;;  Author: Lee Mac, Copyright © 2010 - www.lee-mac.com       ;;
;;------------------------------------------------------------;;
;;  Arguments:                                                ;;
;;  l - List to process                                       ;;
;;  n - Number of elements by which to group the list         ;;
;;------------------------------------------------------------;;
;;  Returns:  List of lists, each of length 'n'               ;;
;;------------------------------------------------------------;;
(defun LM:GroupByNum (l n / r)
  (if l
    (cons (reverse (repeat n
                     (setq r (cons (car l) r)
                           l (cdr l)
                     )
                     r
                   )
          )
          (LM:GroupByNum l n)
    )
  )
)



[GP]

...it gives two points of intersection whereas I clearly know that there is only one..

Move objects close to the UCS origin.

[mailmaverick]

...it gives two points of intersection whereas I clearly know that there is only one..

Move objects close to the UCS origin.

By moving near UCS, it gives correct answer. But why is it so ?

It should give correct answer with any coordinates.

[ymg]

Gian Paolo,

Interesting problem, this kind of coordinates is very common in surveying.

ymg

[MP]

I found a problem with said function years ago when a pipeline design program suddenly stopped working. It took awhile to determine it was caused by objects exceeding a certain threshold distance from the origin. As moving objects was not a practical option I simply wrote my own intersection function. Recommend same.

[ymg]

How about simply copying both object at offset (vlax-curve-getstartpoint obj1)
applying the intersectwith method, delete the copy and  then translate
the resulting list.

ymg

[MP]

Temporary objects are one option but punishing on performance when you're dealing with thousands of intersections. Between the inability to confidently rely on the IntersectWith method and the performance hits with temporary objects why I rolled my own (sorry, proprietary code as simplistic as it is), never looked back and suggested "recommend same".

[mailmaverick]

Writing own code is fine but my query is why this error at these coordinates and not near origin ?

Can this bug be reported to Aurodesk.

[fixo]

Try this code, not sure if this is solution though

Code: [Select]

;; --- grouping list --- ;;
 
(defun group-by-num (lst num / ls ret)
  (if (= (rem (length lst) num ) 0)
    (progn
      (setq ls nil)
      (repeat (/ (length lst) num)
(repeat num (setq ls
    (cons (car lst) ls)
      lst (cdr lst)))
(setq ret (append ret (list (reverse ls)))
      ls nil)))
    )
ret
  )
;; --- intersection --- ;;
(defun _intersect (en1 en2 iflag / ptlist)
  (setq ptlist (vl-catch-all-apply
       'vlax-invoke-method
       (list en1  'IntersectWith en2 iflag)))

  (if (not (minusp (vlax-safearray-get-u-bound (vlax-variant-value ptlist) 1)))
(group-by-num (vlax-safearray->list (vlax-variant-value ptlist)) 3)
    nil
  )
)

;; --- usage --- ;;
(setq en1 (entsel "\n#1 >> : ")en1 (vlax-ename->vla-object (car en1))
      en2 (entsel "\n#2 >> : ")en2 (vlax-ename->vla-object (car en2))
     pts (_intersect en1 en2 0))
      (if (not pts)(alert "out of luck bud")(alert "intersected"))


[ymg]

mailmaverick,

Because Floating Point precision is finite.

I don't know how they do he calculation internally, but every digits before the decimal
point is lowering the accuracy of the decimal part.

As for notifying Autodesk, I am quite sure they know about the problem.

ymg

[mailmaverick]

As for notifying Autodesk, I am quite sure they know about the problem.

ymg

If Autodesk knows the problem, then why don't they rectify it. They are bringing new versions every year with all frills and fancies but such problems (there may be many more like this) are much more important to handle and can have huge adverse effects on calculations by users like us.

[CAB]

You're preaching to the choir. 

[Lee Mac]

Here is an alternative function for intersections between straight-segmented LWPolylines:

Code: [Select]

(defun polyinters ( pl1 pl2 )
    (apply
        (function
            (lambda ( vl1 vl2 )
                (apply 'append
                    (mapcar
                        (function
                            (lambda ( a b )
                                (vl-remove nil
                                    (mapcar
                                        (function
                                            (lambda ( c d )
                                                (inters a b c d)
                                            )
                                        )
                                        vl2 (cdr vl2)
                                    )
                                )
                            )
                        )
                        vl1 (cdr vl1)
                    )
                )
            )
        )
        (mapcar
            (function
                (lambda ( ent / enx lst )
                    (setq enx (entget ent)
                          lst (mapcar 'cdr (vl-remove-if-not '(lambda ( x ) (= 10 (car x))) enx))
                    )
                    (if (= 1 (logand 1 (cdr (assoc 70 enx))))
                        (append lst (list (car lst)))
                        lst
                    )
                )
            )
            (list pl1 pl2)
        )
    )
)
Call with LWPolyline enames.

[snownut2]

I have not tried the code but would it help to set the drawing limits to include the area of intersections in question, or is it strictly an origin issue.