I noticed that the “fastCheck” option on ray intersections sometimes has almost no effect. After investigating further I noticed that the initial bounding box check might not be working as expected. Basically if the mesh Im trying to check intersections is anywhere in the direction the ray is pointing, it will allways perform full precise measurements (even if there’s clearly no intersection with the bounding box of the mesh).
In the playground below, I would expect the green cluster of rays to finish much quicker than the red cluster, but the times of execution are very similar. On the other hand the blue cluster, which misses the mesh entirely, finishes in a much shorter time.
PG:
Is this the intended behavior?
Hi @MaticErznoznik
Thanks for reaching out with this question! I just took a look at the playground, and I believe the reason you’re seeing that behavior is that fastCheck isn’t the reason the blue rays very quickly get processed while the green rays don’t. You’ll see the blue rays get quickly processed even if fastCheck is false, because what’s making those checks fast is the fact that it can bail out early because the boundingSphere intersection test fails (which is done even when fastCheck is false). That check doesn’t account for ray length, so it doesn’t bail out early for the green rays. The fastCheck option is faster than not using it for the red and green rays because it returns the first intersection found, not necessarily the closest.
I’ll check to see if it would make sense to include the ray length in the bounding intersection tests as a further optimization.
Thanks, I hope that helps explain it!
Hi,
thanks for the explanation. I was able to make a “checking” function which tells me if there is a bounding box intersection before I use intersectsMesh.
I used ray.intersectsBoxMinMax() on the object BB with both the original ray and an inverted ray, facing in the other direction. Seems to be much faster and eliminates the problem with ignoring the ray length