论坛里面有Autodesk的人吗？有个Bug请反映给Autodesk

cairunbin · 发表于 2019-4-1 17:02:00

ObjectArx的Curve.GetDistAtPoint方法，一直存在bug，调用前，都需要先调用GetClosestPointTo（）方法，将点位尽量计算到曲线上。但是，我现在碰到一个bug，即使事先调用了GetClosetPointTo方法，依然会抛出eInvalidInput异常。下面两行代码，运行到第二行line.GetDistAtPoint方法时，AutoCAD抛出eInvalidInput异常。
这里说明一句，下面两行语句里面有三个点：(695939.053,3919395.056,0),(695937.577789435,3919396.40646429,0)，(695938.134733118,3919395.8966167,0)。其中，第三个点的的确确位于头两个点的连线上，三点共线。也就是说，从理论上，下面两行语句完全没问题。复制代码
我将上述代码改进，加入GetClosestPointTo调用，如下：
复制代码
但是AutoCAD2020依然抛出异常。
请AutoDesk公司的大侠帮忙看看，看看是不是AutoCAD自身的bug，或者是我的代码自身有问题。
另外，我说一件让人哭笑不得的事情：我在Autodesk的论坛里面，发布了关于这个问题的帖子。题目用了AutoCAD's Bug等字眼，结果帖子发出没两分钟，就不见了。弄得我摸不到头脑，还以为没法出去，或者发出去了自己找不到了。然后，我又费了九牛二虎之力，又发了一份类似的帖子（英语水平限制，写篇帖子这个费劲）。结果大家猜得到，没两分钟，第二份帖子也被Autodesk和谐了。这和谐的速度，可比兔子快得多。经过这两次，我好像明白了什么，第三份帖子，就没敢出现Bug这个词，结果，顺利发出，并得到了回复。
这件事，元芳，你怎么看？

cairunbin · 发表于 2019-4-2 11:09:00

我在Autodesk公司的论坛提问了同样的问题。他们给我如下回复：
Hi
This is a well known issue due to a lack of accuracy when working with big coordinates (far away from the origin).
You can try to move the line closer to the origin, make your computations and move back the line and your result.
复制代码
虽然，这个方案可以解决问题。但是，当文件很大时，如果需要遍历整个数据库，这种方法还是很费时的。
我怀疑，之所以出现这个问题，是Curve.GetDistAtPoint()方法的实现算法不完善造成的。Curve.GetDistAtPoint()方法是virtual的，其子类应各自实现这一方法。而Line类在实现这一方法时，明显没有考虑到Tolerance.Global，因为，我在运行前，已经将Tolerance.Global设置为(0.000001, 0.0001)，这已经很大了。而Line、Point3d等类的成员，均使用double类型，double类型的有效数字位可达15-17位。如果考虑了Tolerance.Global的设置，完全不应该出现问题。另外，如果在我的代码中，将Line类型替换为Polyline类型，则不会出现问题。这从另一个侧面也说明了Line.GetDistAtPoint()的编码实现存在问题。