AcGeLinearEnt3d::IntersectWith() isn't working in the same way as on AutoCAD

I have noticed that the function AcGeLinearEnt3d::IntersectWith() isn't behaving in the same way as in AutoCAD. If I use it to determine the intersection point of two lines I get true or false if they intersect. That is the same for ACAD and BC, but if the lines don't intersect (they are to short) when ACAD will anyway report the intersection point together with false, so that you get both information about if they intersect and what the point is (it extends the lines to infinity I guess to calculate the point). BricksCAD just reports 0,0,0 in this case.

Comments

  • Dear Sam,

    you might report such a case (maybe with a small sample dwg + code snippet) to our SupportRequest system;
    of course, we usually try to match ARX behaviour, this seems to be such a case.

    Maybe as a workaround (until fixed) : in case you get "false" for the intersection, you could run intersectWith() again, with the "infinity" flag set ...
    of course, might be performance-relevant, as 2 intersectWith() are then processed.

    many greetings !

  • Hi.
    How do I set the infinity flag in the intersectWith command? I can't se that it can take any flags.
    There are many things that doesn't work in the same way as in autocad. I had a previous discussion about this at the support about problems with the region command, but I got the feeling it wasn't anything you would fix anytime soon, so doesn't feel like any idea to report every issue.

  • Dear Sam,

    ah, my fault, I messed it up with the AcDbEntity intersectWith() function, this case here is about AcGeLinearEnt3d::IntersectWith() ...
    so yes, we should fix it.

    I had a previous discussion about this at the support about problems with the region command, but I got the feeling it wasn't anything you would fix anytime soon, so doesn't feel like any idea to report every issue.

    Normally, we are VERY eager to fix any incompatibility, clearly (you can see in our ReleaseNotes) ...
    the case you mentioned with the regions is a very particular one : ACIS objects are processed by ACIS core libraries, we have good control over it, but not to all extent;
    Autodesk has its own copy of ACIS sources, so they can actively adjust the ACIS core, on their own (and they did).

    So, meaning, if it might not be trivial to adjust/fix the region problem, it is clearly a somewhat exceptional case ...
    in generally, documenting any difference is always worth, it gets into our defect database, and all those issues are processed, earlier or later.

    Another exceptional case : when ARX/AutoCAD clearly shows a buggy behaviour, then we always have to find a valid balance, to keep existing client code working, but without reproducing the buggy behaviour ...

    many greetings !

  • Dear Sam,

    from ARX docs for AcGeLinearEnt3d::intersectWith()

    Determines if two lines intersect and if so returns their intersection point. The intPnt parameter is set to something meaningful only if this function returns a value of Adesk::kTrue.

    so in fact, real behaviour is against the ARX docs :smile:
    and more interestingly, the similar AcGeLinearEnt2d::intersectWith() does not calculate the (imaginary) intersection point, if the 2 linear entities do not intersect.

    So in the end, a particular singularity ... this means :
    a) report such cases to us via SupportRequest system
    b) be careful to rely on such behaviour, especially when it is againts the docs (can change a any version)

    We have adjusted our BRX implementation here, to match ARX :smile:
    should be in upcoming V21.2.04

    many greetings !