I faced one problem with a TraceARay function. Below I painted the problem: I have two points lied on Face A but close to Face B. I try to do TraceARay along Vector, but for Point A I recieve two hits instead of one that is incorrect result. For Point B TraceARay returns a correct result. Maybe there is some sort of tolerance settings for TraceARay?
The code (Python) is really simple:
transf = [ 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0 ] tracert_ray = theUfSession.Modeling.TraceARay(1, list((body.Tag,)), point, vector, transf, 0)
Such behavior happens spontaneously. For example in one 3D model I can explore one point with 0.001 mm distance to nearest face and result might be wrong, but for another point with smaller distance 0.0001 mm the result might be correct. Sometimes it might be happend with a distance even 0.1 mm! On the same 3D model on the same session!
I decided to create intersection manually with user interface (Point intersection between line and face). It gives correct result everything.
I use Ctrl+Z after each time I use my script. I mean I launch my script first time, then press Ctrl+Z, then launch my script again... In several repeats I will start getting incorrect result. I think there is accumulated error.
My colleagues told me that the also faces such behavior (when user repeat the same operation with Ctrl+Z many times) with original feature from user interface.
Does anybody faced such behavior?
Could you explain such behavior and how to get a correct result?
The ray makes quite a small angle with the nearby edge, so there wil certainly be some ill-conditioning in the calculation.
Also, check the type of the edge. If its type is "tolerant edge" then the edge is "fuzzy" (it has some non-zero diameter) so you can expect strange results when you are near to it.
The moral of the story ... if your calculations are seriously affected by tolerances, round-off, and other floating point anomalies, it's best to find some other way to do the calculation.
I can't think of any reason why the Undo/repeat cycle would change the answers in any computations. Undo is essentially just a database roll-back that returns the model to a previously-saved state. It doesn't do any recalculation/reconstruction, as far as I know, so I can't see any opportunity for computational errors.
If you have reproducible examples of this behaviour, I think you should report them as PRs.