solid angle for each pixel/ray

[moving this to the dev-list]

Roland Schregle wrote:

Peter Apian-Bennewitz wrote:

> RenderMan (and probably others) use different textures/patterns
> depending on distance (more exactly on the solid angle the pixel
> covers). This angle is not supplied in the function files (at least it
> wasn't when I discussed that with Greg two years ago), so view dependent
> textures are a bit tricky to do. One reason for not making it available
> was that it is known in rvu/rpict, but not rtrace. If we agree (on
> radiance-dev) it would be useful, I'd be happy to see this variable.

Actually, a solid angle in the context of rtrace would be useful in
general.

Rview and rpict can determine this information from the (angular)
spacing of successive pixels. Rtrace doesn't have any concept of
pixels, let alone something like "the next pixel to the right
points x degrees away from this one".

To make this work with rtrace, there would have to be a way to
feed it this information seperately. I'm not sure if a global
parameter would be enough, because I think it can vary quite a
bit eg. for wide angle perspectives. On the other hand, allowing
a seventh value with each line of input might be a non-trivial
change.

In any case, I agree that this would be a very useful variable.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Georg Mischler wrote:

Rview and rpict can determine this information from the (angular)
spacing of successive pixels. Rtrace doesn't have any concept of
pixels, let alone something like "the next pixel to the right
points x degrees away from this one".

To make this work with rtrace, there would have to be a way to
feed it this information seperately. I'm not sure if a global
parameter would be enough, because I think it can vary quite a
bit eg. for wide angle perspectives. On the other hand, allowing
a seventh value with each line of input might be a non-trivial
change.

I'd also consider the solid angle an (optional?) datum appended for each measuring point. Where it comes from is the user's problem. :^)
Haven't looked at the code which parses the input lines, but I'm sure it could be modified to handle an optional 7th datum before the newline. Its absence would indicate an inifinitesimal solid angle, which is what rtrace assumes right now. That should cater to backward compatibility.

···

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)