Bidirectional Ray Tracing

[DBS4261]

Hi folks, I have been working on some texture baking code and am considering the difference between mapping query points from the closest point on the input mesh to the nearest intersection of the normal of the output mesh with the input mesh. I was looking at the documentation for the embree::RTCRay structure, specifically the description of the tnear and tfar members. The documentation says: "The ray segment must be in the range [0, ∞], thus ranges that start behind the ray origin are not allowed, but ranges can reach to infinity". To me this implies that tnear and tfar represent the search range for intersections, and giving a range of [-∞, ∞] would give me the bidirectional search I am looking for. Is that a correct interpretation of the documentation, or would I be straying into the realms of undefined behavior?

[FlorianR_Intel]

Hi,

yes and no. The values [tnear, tfar] define a search range, but setting tnear to an negative value has no effect because internally intersections behind the origin of the ray will be ignored. 

If you want to have all intersections along a line (origin + t * direction, t -inf <= t <= inf) and not only the ray (origin + t * direction, 0 <= t <= inf) you can either shoot two rays pointing in opposite directions or you can set the ray origin to some point "sufficiently far away". You can query the scene bounds with rtcGetSceneBounds and set the ray origin to some point on the line outside the bounding box of the scene, for example.

Best,

Embree team

[DBS4261]

Thanks for your reply. Because I am running a previous ray tracing call to determine the origin of this ray, I presume I would need to launch this with the embree::rtcForwardIntersectN call, right? And as far as choosing which method, I would think that using a single ray from far away would not perform as well as using two rays because the rays starting from the origin can terminate on closest hit. Is that correct?

[FlorianR_Intel]

Hi,

you don't necessarily have to use rtcForwardIntersect. This is the "new GPU friendly way" of making recursive calls to rtcIntersect from within user-geometry intersect callbacks or intersection filter functions while Embree is still in a traversal loop. 

If you already have your new ray origin from an rtcIntersect call you can just call rtcIntersect again to trace secondary rays.

I think you are correct with your performance assessment that two rays in opposite directions will be faster then one ray with a far away origin if you want to have the closest point in any of the two directions starting from a given origin.

I hope this helps. If my answers are not helpful, I propose that you explain in some simple pseudo-code what your algorithm is supposed to do exactly.

Best,

Embree team