Hi,
In rtrace documentation it says there are two kinds of ray length:
-l for “effective ray length”
and
-L for first intersection distance.
While the “-L” option is obvious, the definition for “effective ray length” is not clear. Even looking at the code, it’s not clear what is actually reported by this parameter. Can someone please elaborate on that?
Thanks
Effective distance is determined by what the ray hit. On surfaces (or parts of surfaces) where the diffuse reflection dominates, it is the same as the first intersection distance. On transparent surfaces, it will be the distance to whatever you see through the object if transmission dominates. For planar reflective (mirror-like) surfaces, the distance will include the distance to whatever is reflected. These rules are applied recursively, so a hall of mirrors could have some very large distances involved, for instance.
The effective distance is better for reprojecting pixels using pinterp and the like, so this is what we record in rpict with the -z option, also.
Thanks, that helps!
So, does this effective distance take into account the refractive index, and is actually an optical path length? My guess is no, but I’m not sure…
On the same topic, I have a problem where I actually need to know the coordinates of intersection of the ray with the object that I’m seeing through a curved glass slab. Unfortunately it seems that rtrace with -p will just return the intersection with the glass slab. In there a way to achieve this besides searching the tree ray?
Thanks in advance
The effective distance will use the optical path for a ray passing through a flat (polygon or ring, untextured) dielectric surface.
As for your intersection coordinates through a curved glass slab, I don’t know how to do it besides searching the ray tree with the -otp option to rtrace. You can’t use the ray origin plus direction times path length through a curved dielectric, since the ray will be bent, violating the above condition as well as the straight-line geometric ray assumption.
If you approximate your glass slab as infinitely thin using a single surface and the “glass” material, then the straight-line geometric ray assumption will hold and effective distance can be used, but I’m guessing this isn’t what you are after.
So, I guess searching the tree it is, I just have to figure out how to do that efficiently.
Coming back to this discussion after a while… 
I have an idea of how to obtain the intersection points through the dielectric slab without doing a full ray-tree search. What I do is create a “virtual wall” after the slab and trace the rays only up to the slab. At this stage the search is trivial since I know exactly where the rays should end up. Then I use the intersection/directions at the “virtual wall” as an input for another rtrace run, from the wall into the actual scene, but without generating a full ray tree which allows me to do multicore computation. This seems to work, I just wonder if there are any potential pitfalls or innacuracies I have to lookout for?
Very clever. Sounds like this should work. Are you using the virtual wall’s material to select which rays to trace in your second run, or do you have another selection criterion?
Yes, basically I’m using the virtual wall’s known modifier to filter out any ray that hits something else,
using the -ti option of rtrace.
Since the wall is huge, ultimately all rays will reach it (not interested in back-reflections in this context). Then I can use these rays as input to the second run. I don’t even have to save the results to a file, I could just pipe the output of the first rtrace call to the other.
I would like to take it a step further though, but probably will have to make some modifications to rtrace. My understanding is that since rtrace uses a queue, multiprocessing will only work if each ray pushes just one result into the queue. So I’m thinking that if I end up with just one result per ray, albeit not the first intersection result - perhaps I could still make it work with the -n option. Any thought or tips on that direction are very welcome! 
I guess I don’t understand your issue with multiprocessing. Are you talking about using a -n option with the first (feeder) rtrace process, the second one, or both? Either or both should work, though I don’t know how big the gains will be unless one of them is doing a lot of interreflection calculations. The pay-off for multiprocessing tends to diminish if it only takes a tiny amount of time for each primary ray. You spend most of the time on i/o and book-keeping at that point.
I’m asking about the first, since it’s the one that needs to generate the ray tree with -ot* option.
The documentation says -n won’t work with this option, and indeed it seems that with each run I get different results. My guess is that the order of the rays in the report changes?
Oh, right. In the current CVS head code, setting any of the -ot* options turns multi-processing off. In the current official release (and earlier), it simply messed up by intermingling results from the child processes. Not good…