Topic: Inters behavior

[Latex]

Hello everyone!
I've been using the inters method recently and i had unexpected results.
I use the formula with 4 points on my drawing (here, everything is okay) and the result for the fonction is nil.
I do call the function this way :

Code - Auto/Visual Lisp: [Select]

1. (setq i (inters pt1 pt2 pt3 pt4 nil))

This way, it should means that the two lines are parallel right ? In fact, they are not.
So, right before my call to inters method, I've printed on the console the different values for pt1, pt2, pt3 and pt4.
After that, I manually tried to execute; on the console with my drawing opened; the inters method with the actual values of the two lines and there, inters gave me an actual intersection point instead of nil.
I feel like I'm missing something huge with inters, anyone experienced the same kind of problem ?

Ps : Im working on autocad 2010.

Thanks in advance,
Best regards,
Latex_

[ymg]

Latex,

First and foremost you are not applying a method but
you are calling a function.

Now the last argument in your call means that lines
defined by pt1 pt2 and pt3 pt4 are extended to infinity.

Are you sure your point are in the same plane ?

If not, even though the lines have an apparent intersections
there is no true intersection.

ymg

[Lee Mac]

Does your UCS=WCS when the function is evaluated in each case? -
Note that the inters function will accept & return points expressed relative to the active UCS.

[roy_043]

To my knowledge the inters function is not related to any coordinate system. If all points are WCS points the return value will be a WCS point. If all points are current UCS points the return value will be a current UCS point.
I suspect it is either a rounding issue or a 2D/3D issue.

[Lee Mac]

To my knowledge the inters function is not related to any coordinate system. If all points are WCS points the return value will be a WCS point. If all points are current UCS points the return value will be a current UCS point.

All points are expressed in terms of the current UCS. If all four point arguments are 3D, inters checks for 3D intersection. If any of the points are 2D, inters projects the lines onto the current construction plane and checks only for 2D intersection.

If the active UCS is different at the time of each evaluation, the points could be projected to a different plane in which there may not be an intersection.

[irneb]

To my knowledge the inters function is not related to any coordinate system. If all points are WCS points the return value will be a WCS point. If all points are current UCS points the return value will be a current UCS point.
I suspect it is either a rounding issue or a 2D/3D issue.

The inters function doesn't care about the UCS ... you're correct. It only looks at the actual values you pass it - which may have nothing to do with any UCS.

But ... the "lines" defined by the 4 points are still in 3D space. Which means that even though they "look" as if they intersect, that may very well not be the case. E.g. the 2 lines may have differing Z values, or they may not even be parallel to the XY plane. To test this see if the fillet command works on these lines. Note trim/extend has a further option which projects the lines onto the USC's XY plane (or some arbitrary plane relevant to the current view orientation) and then trims/extends them, but fillet doesn't.

If you find this to be the case you could always do such "projection" manually by simply changing each point's Z value to 0. That would "project" the lines onto the WCS's XY plane. But then your result from inters would also have a Z value of 0. You could then attempt to obtain the 2 z values for the projected intersection by using the relevant distances on the projected lines and then using the vlax-curve functions to obtain the points along the actual 3d lines.

[irneb]

All points are expressed in terms of the current UCS. If all four point arguments are 3D, inters checks for 3D intersection. If any of the points are 2D, inters projects the lines onto the current construction plane and checks only for 2D intersection.

If the active UCS is different at the time of each evaluation, the points could be projected to a different plane in which there may not be an intersection.

That's actually quite interesting. What happens if you pass it one 2d point and the rest as 3d points while in some UCS other than WCS? Would the inters function automatically trans the 3d point from WCS to the new UCS or is it just assumed that the 3d xyz is in the same UCS as the 2d xy?

If the later then that statement in the help is actually erroneous, it would mean the UCS has nothing to do with the inters function at all. It would simply assume some WCS relevant to the point provided and do no translations. But the projection would still work - just that it would work on all 4 points as if they're specified in the same WCS ignoring anything about how the XYZ axes are moved / rotated / tilted in order for a UCS.

Actually from my own tests this is exactly the case. No matter how I change the UCS, if the points are in WCS coordinates the result on inters do not change. It's only when you've converted or obtained the 4 points relevant to the UCS when this actually has any effect. E.g. if you've picked the points using getpoint while a different UCS is active. But still that doesn't mean that inters even looks at the UCS, the UCS relevancy comes from the getpoint function (or whatever else you used to obtain the 4 points).

[roy_043]

... In short:
The inters function does not take the current UCS or current elevation into account. And if any of the points is 2D, all points will be turned into 2D points by removing their Z-value. The documentation is indeed confusing.

Code: [Select]

(inters '(-1 0) '(1 0 3) '(0 -1 3) '(0 1 3)) => (0 0)
@ Latex: Assuming the point values come from a dwg it may be useful to post the dwg.

[Lee Mac]

Thank you for the clarification Irneb & roy, I appreciate your time testing the claims made by the documentation -
The inters documentation is indeed quite confusing.