I have an application where my light source fires a number of rays into the scene and I want to log when a certain object in the scene was hit, where it was hit, and some information about the source. The material of this object responds to not only the primary ray but also secondary reflection rays. I’d like to use an rtBuffer to log this information and I was wondering what the standard approach was for managing the buffer access. Many of the examples in the SDK write to an rtBuffer using a launch_index associated with a ray generated at context launch, and this ensures that nothing is clobbered. However, I assume for the case of secondary rays the launch_index is the same as the parent primary ray? In my situation this would lead to clobbering of the buffer values if a primary ray and one of its children reflections both intersected with the object.
If I were to recursively generate secondary rays from a primary ray, would all that work be performed on the same OptiX thread? And if so, is it possible to maintain a “local” variable across the recursion that maintains state just within that thread? What I am essentially looking for is a way to index a 2D buffer containing my data, where perhaps the X dimension is indexed by thread via launch_index and the Y dimension is indexed by a thread-local pointer that is incremented every time the material is hit.