Hi, Actually, I probably was not clear before: only the refracted ray will be a new ray on the queue: the reflected ray continues on its merry way until it decays. That is probably the same thing as what you are suggesting. The reason I was vague before is that I have two options: follow the reflected ray and spawn new refracted rays (as above) or follow the refracted ray ans spawn the reflected rays. I expect solution #1 is better in terms of locality but #2 might result in a smaller queue since internal reflection coefficients are small (i.e. you often wind up dropping the reflected ray since it no longer carries any significant power). Right now, the code is using #1 but I was considering switching to see what effects it might have...
It may be possible to do fairly well on locality by on a split, rather than putting both new rays into the queue and doing a new fetch from the queue, continuing on with the ray most similar to the incident ray, only adding the other ray(s?) to the queue, so the frame of reference only jumps when a ray dies. (Not unlike half-tailing quicksort.)
=========================== We actually almost always develop in Fortran except for the GUI parts. That comes from our company background in physics and the large amount of existing code we have ... But yes, the code is old and mostly written in fixed-form F77. I am at least trying to modernize some parts to use free-form F90/F95 syntax :) I actually have not taken a look recently at these papers since I always worked directly on the code. Hopefully, there is something of interest in there.
Thanks, I always ask people to post links to their work since it makes things more interesting and I'll look as soon as I can. I thought the code may be a bit old given the language
Regards, Michel Lestrade Crosslight Software