WideBVH shrinkingRadiusQuery Support

[tobyfrancis]

WideBVH is going to be more optimal for certain distance-to-mesh and FCP queries; it would be good to support WideBVH in shrinkingRadiusQuery. Currently, shrinkingRadiusQuery uses Admin:: and thus is not compatible.

[ingowald]

Agreed, will fix ASAP. I actually use WideBVH in my own apps as well, but they haven't been ported from their own traversal code to the cuBQL templates, yet, so this hasn't triggered on my side, yet.
Thx for letting me know, i'll fix asap.

[ingowald]

toby - quick update: i'm not all that sure any more that the widebvh will be faster than the binary bvh - i haven't adapted it to shrinking radius queries yet, but at least fixed it for fixedRangeQueries (for which i have test cases at hand in barney), and in that one the wideBVH was generally slower than binaryBVH. Sure, fixedBoxQUery behaves differently than shrinking radius, but still - don't expect too much is all i'm saying.
(still going to fix it, of course, it should't be "broken" no matter if faster or not)

[ingowald]

devel should now have a cuBQL::shrinkingRadiusQuery::forEachPrim() also for WideBVH; i also added a sample s01_findClosestPoint_WideBVH, which also gives same results as binary bvh and cpu traversal, so at least for that test seems correct.

[tobyfrancis]

Thanks Ingo! Testing it out, it's actually the fastest option for my use-case!