So the grazing plate mode BoT case that was reported is the very same case. ray is grazing a plate-mode bot and returning an LOS thickness way longer than physically possible, which results in an overlap with nearby objects that don't actually overlap.
Ah, lovely
Screen-Shot-2020-05-14-at-4.42.33-PM.png
Yep, sure enough.
rays come in from left to right -- they graze the faces on the left, which are nearly horizontal
you can see one of the resulting LOS thicknesses, the actual hit point is near the cluster on the left, but it extends all the way forward through the tubes.
and/or tubes are extending backwards
as they also have grazing hits
this is actually a really nicely isolated generic case for figuring out how to fix this
So we're back to either clamping a maximum length, implementing some sort of crazy robust (and slow) special calculation for those near-tangent cases, or...?
clamping will help avoid egregious cases like this, but will still be wrong
just not as long-wrong
there's a catchy motto in there somewhere... "BRL-CAD - not long-wrong!"
it's potentially wrong even for nearly orthogonal hits
So... fall back on something like https://bellard.org/libbf/ for near tangent inputs?
this is an algorithmic problem, not a numerics or precision problem. How would libbf help?
I was thinking if the trig calculations were breaking down numerically in the near tangent cases, we could fall back on more robust but slower solvers in that situation.
just a thought - I may not have fully understood the underlying math issues
they "break down" in the sense that it causes big numbers, but they're not wrong
it's literally the projection to where the ray intersects the plane of the plate-mode-extruded surface
I drew a diagram of it last week, if you recall it
we can calculate the face plane and trim the segment deterministically at the plate's extruded distance. that gives exact and correct in/out segments.
the problem is more one of coordination.
Ah, right.
Last updated: Jan 09 2025 at 00:46 UTC