Re: My path tracer back

(L) [2012/07/25] [ingenious] [Re: My path tracer] Wayback!

In OpenRL, can you shoot a ray not in a recursive way, but as a function to return properties of the surface that was hit, like point, normal, some custom parameters (e.g. diffuse color, specular color, specular exponent, even BSDF type)? Can you shoot rays from the light sources? I remember the Caustic Graphics times when such things were not possible - it was tracing from the camera and in a recursive shoot-n-forget style. While convenient for optimizations, with this scheme the range of global illumination algorithms you can implement effectively reduce to path tracing. Quite ironic, since it cannot produce good... caustic graphics  [SMILEY :D]

(L) [2012/07/25] [chriso] [Re: My path tracer] Wayback!

>> ingenious wrote:In OpenRL, can you shoot a ray not in a recursive way, but as a function to return properties of the surface that was hit, like point, normal, some custom parameters (e.g. diffuse color, specular color, specular exponent, even BSDF type)? Can you shoot rays from the light sources? I remember the Caustic Graphics times when such things were not possible - it was tracing from the camera and in a recursive shoot-n-forget style. While convenient for optimizations, with this scheme the range of global illumination algorithms you can implement effectively reduce to path tracing. Quite ironic, since it cannot produce good... caustic graphics  

It still uses the 'fire and forget' method. You can implement other algorithms using a multi-pass method. The frame shader shoots at least one ray per pixel in the output framebuffer - there isn't a requirement that this is necessarily from the PoV of a camera passing through that pixel on the screen, you can set up the ray origin and direction as you like, and as you can emit multiple rays within the shader you could shoot several from the camera (sampling a lens / MSAA) and several from a light. Admittedly, you can't interact between these rays on this pass, but if you wrote out the information you required to a texture, you could then write a second pass which samples from these textures to create the final output image you want (although I've not tried this so I'm not sure of the finer implementation details at the moment). There may be other ways of implementing other algorithms more efficiently in OpenRL which I am not currently aware of.
Note that this is only an issue when you are making decisions based upon when you are intersecting with other rays emitted in the same render. In the case where you need to make a decision based on the next object you hit, you just pass the calculated value (e.g. colour) as a ray attribute and the accumulate value is calculated when you know what it is going to hit.

(L) [2012/07/26] [sirpalee] [Re: My path tracer] Wayback!

Thanks chriso, this sounds good enough.
About shader networking, it is a bit different, what you wrote. It's basically a way to hide from the programmer, if the result of a variable is coming from an another shader, or from a constant variable.