jkalias
commented
1 year ago Hi,
I think this is a good idea. My approach would be to find the best matching plane in terms of least-squares, as described here. The condition that we need at least 3 points will still hold of course. We would then need to determine if any point lies outside of this plane and if it does, we should discard it as invalid.
Let me know if you want to submit a PR or I should provide an implementation for further discussion.
Plane.FromPoints()will throw exceptions if the arguments don't actually form a plane. For instance, if you give it 3 points on the same line.I have some cases where I have a large set of points which are coplanar, but I don't know in advance which 3 points necessarily will fulfill the conditions of
FromPoints. So I have to iteratively try point triplets until one of them works. This is fine in itself, but it means that I either have to try/catch exceptions when callingFromPointsor I have to manually test the points before calling it.I have two concerns with manual testing - one is that I can't know for certain that the numeric precision won't cause a failure - e.g., my test might conclude the points are not colinear, but the then test in
FromPointscould conclude the opposite.The other is just inefficiency, that essentially the same test would be performed twice, once by me and once by
FromPoints.Based on all that I think it would be useful to have a
bool Plane.TryFromPoints()method in addition to the existing one. Probably the existingFromPointscould be refactored into that function and would itself remain just a wrapper to throw exceptions if the Try... version returned false.I see that, for example,
LineSegment2Dhas aTryIntersect()method which behaves in a similar way, so maybe this would be an OK pattern to use in this library.I could submit a pull request for this if it sounds like a good idea?