@Inside "Look, Ma... No Rays!"

[John Uhden]

The @delta function has yet another use.
See attached. Chew it up. Spit it back. Let's see if we can move on.

 

[R. Robert Bell]

Warning... typo:

(cond
((= (type Object) 'VLA-Object))
((= (type Object) 'Ename)
(setq Object (vlax-name->vla-object Object)) ; <- Look ma', no function! <vbg> ) (1 (setq Object nil))
)

 

[R. Robert Bell]

Aside from the typo, I tried it on some tricky plines, and it passed. Looks good until Doug gets a hold of it!

 

[Joe Burke]

John,

Very slick. Figured you had something up your sleeve...

Wrote this just to be sure I understand how it works. It's the same basic idea, yes? I know it doesn't work if the test point is inside a bulge segment. I didn't expect it to.

;; p - point to test
;; ptlst - closed pline point list w/o bulged segments
(defun test (p ptlst / res)
(setq ptlst (append ptlst (list (car ptlst))))
(setq res
(apply '+
(mapcar '(lambda (a b) (@delta (angle p a) (angle p b))) ptlst (cdr ptlst) ) ) ) ;(print res) (equal (abs res) (* 2 pi) 1e-10)
)

Joe Burke

 

[John Uhden]

Very good, Joe.
Basically you're iterating at a sample rate of 1.0 parameters. Change that to
0.5 and you're picking up the midpoint of each bulged segment. I found that the extra evaluations for the closest point to be critical, thus the stepped process rather than mapcar. Anyway, circles, ellipses, and splines don't have a 'Coordinates property, and their end parameter is not a whole number.

I'm not as dumb as I look; I asked Doug to check it out yesterday. Doug quickly found the bug with coincident adjacent vertices, such that (vlax-curve-getpointatparam) returns nil for the midpoint (+ param 0.5)
parameter.

 

[John Uhden]

Thank you, Robert. Hey, at least half of the function looked blue in TextPad!?

 

[Doug Broad]

John,
Very nice. I tried a bunch of figure and it seems to work very well with them all. Preliminary results are very good.

Regards,
Doug

 

[John Uhden]

It wasn't quite right.
Attached is @Inside2.lsp

 

[Joe Burke]

John,

Thanks for the update.

Question to you and Doug: my sense is both your functions are equal in terms of reliability. So which one would you use under fire? I tend to think something which does the job, without creating objects, is preferable. i.e. "Look, Ma...
No Rays!"

On the other hand, watching Doug's function avoid the vertices is way cool.

Joe

 

[John Uhden]

I gave up rays two threads ago because the intersectwith method returns only one point for an intersection with collinear (one or more right on top of the other) polyline segments. No offense to Doug, but I didn't even look at his function. I do think the deflection version needs some more work... elevation of PIQ vs. ClosestPoint, plus a procedure to increase the sampling rate for bulged polyline segments only. Then there's the whole issue of testing for nested objects, which would require that WCS2OCS thingy to find the ClosestPoint.