graphing radiance raytrace paths

radiance-general
1

Hi,

What I would love to do is to produce a graph depicting the rays a radiance
rendering actually consists of, moving from the camera back to the light
source.
What would be an appropriate way of doing so? Would a radiance holodeck file
do the trick, since from what I understood, its storing the actual traced
rays in a file format.
The other question would be how many rays such a graph should contain,
probably a 100k is more than sufficient for such a graph, while an actual
radiance render would consist of many more. Looking forward hearing your
suggestions!

Cheers,

Jelle.

2

Hi Jelle,

Check out the "xshowtrace" command. It uses rtrace on an image to superimpose ray paths you select. It doesn't show a side-view with the camera in the image, unfortunately. There's an exercise for the reader!

-Greg

From: "Jelle Feringa // EZCT / Paris" <[email protected]>
Date: January 25, 2005 1:34:07 PM PST

Hi,

What I would love to do is to produce a graph depicting the rays a radiance rendering actually consists of, moving from the camera back to the light source.

What would be an appropriate way of doing so? Would a radiance holodeck file do the trick, since from what I understood, its storing the actual traced rays in a file format.

The other question would be how many rays such a graph should contain, probably a 100k is more than sufficient for such a graph, while an actual radiance render would consist of many more. Looking forward hearing your suggestions!

Cheers,

Jelle.

3

Hi Greg,

Wow! Thanks for pointing that out to me, that seems quite close to what I
intend to do. I think 'graph' wasn't necessarily the appropriate term, since
often it implies 2d. In fact I'm looking for a way to capture the rays
traced in a rendering to a 3d (polygon) file, preferable colored according
to their illumination value. Maybe you've seen the Maya 6 feauture where
your able to visualize the global illumination cache in coloured points. (if
you haven't it might be interesting that I upload an image to my server)
I'd like to do something similar like that, but its important to trace the
whole path, right from the camera, all the way back to the light source it
emitted (sure, a lot of them will end up at the wall, but the more rays can
be traced to the source, the better)

As I understood from the man pages, piping ximage (t) to rtrace is close to
what xshowtrace does, except that its output is numbers instead of graphic
lines superimposed on the rendering (by the way, there's no way to control
the interval of xshowtrace -s is there? Awesome soft! Thanks so much!)

So here's what I tried using this approach:

ximage someRendering.pic rtrace -ab 5 -oodLpnsm -h -x 1 -i someOct.oct >
rays.txt

rays.txt:
4.524520e+00 5.080820e+00 3.480030e+00 -3.025107e-01 3.848206e-01
8.720094e-01 5.183396e+00 2.956487e+00 7.075498e+00 8.000000e+00
0.000000e+00 0.000000e+00 -1.000000e+00 boxSTri321 box321
4.524520e+00 5.080820e+00 3.480030e+00 -4.554681e-01
-3.514263e-01 -8.179538e-01 4.254556e+00 2.586706e+00 3.585657e+00
-3.348016e-16 0.000000e+00 0.000000e+00 1.000000e+00 box0.b box0

4.524520e+00 5.080820e+00 3.480030e+00 -9.447599e-02
-6.675847e-01 -7.385154e-01 4.712197e+00 4.079331e+00 1.935029e+00
-2.426444e-16 0.000000e+00 0.000000e+00 1.000000e+00 box0.b box0

Still that type of data comes near, but wont be sufficient for the graph
that I intend to make. The kind of script would allow for:

-setting the maximum number of rays traced
-outputting the coordinated of each ray in XYZ values where rays intersect,
all the way up to their source.
-these rays would purely be casted from the camera, not selected points in
space as in the xshowtrace approach
-what could be great is that rays will be coloured according to their
luminance value.
-the graph should be dense enough that the architecture from which the rays
were cast from becomes present in the graph.

In the end it'll be a very beautiful and powerful image, exposing radiance
inner mechanism!

Cheers, and thanks again for your feedback!

Jelle

4

Hi Jelle,

You can get much closer to what you want if you simply add a 't' in your rtrace's -o option, like so:

% ximage someRendering.pic | rtrace -ab 5 -otodLpnsm -h -x 1 -i someOct.oct > rays.txt

This is going to give you more rays than you can possibly want, so I'd also set -ad 32 or so to reduce the number of interreflected rays generated. Any other trimming, you'll have to do yourself.

Also, this will not show all the rays returning to the light sources, as this part of the calcuation never gets fully 'traced', the reason being that the direct calculation in Radiance attempts to minimize the actual number of rays followed to sources as an optimization. If you want to see the paths all the way back to the sources, you'll have to get into the rt/source.c file and start modifying the code directly.

Regarding the -s option in xshowtrace, you can go in and change it yourself. The sleep call is on line 260 in px/xshowtrace.c. Unfortunately, sleep only takes integer arguments, but you can replace it with a call to nanosleep() on most systems.

-Greg

···

From: "Jelle Feringa // EZCT / Paris" <[email protected]>
Date: January 26, 2005 4:32:11 AM PST

Hi Greg,

Wow! Thanks for pointing that out to me, that seems quite close to what I
intend to do. I think 'graph' wasn't necessarily the appropriate term, since
often it implies 2d. In fact I'm looking for a way to capture the rays
traced in a rendering to a 3d (polygon) file, preferable colored according
to their illumination value. Maybe you've seen the Maya 6 feauture where
your able to visualize the global illumination cache in coloured points. (if
you haven't it might be interesting that I upload an image to my server)
I'd like to do something similar like that, but its important to trace the
whole path, right from the camera, all the way back to the light source it
emitted (sure, a lot of them will end up at the wall, but the more rays can
be traced to the source, the better)

As I understood from the man pages, piping ximage (t) to rtrace is close to
what xshowtrace does, except that its output is numbers instead of graphic
lines superimposed on the rendering (by the way, there's no way to control
the interval of xshowtrace -s is there? Awesome soft! Thanks so much!)

So here's what I tried using this approach:

ximage someRendering.pic rtrace -ab 5 -oodLpnsm -h -x 1 -i someOct.oct >
rays.txt
...

5

% ximage someRendering.pic | rtrace -ab 5 -otodLpnsm -h -x 1 -i
someOct.oct > rays.txt

  Wow, that's getting very close to what I need, thanks very much,
indeed I had problems getting rays to bounce. I'm sorry I never got to
wrestle rtrace before, I was stuck too long with the DTPrad wintel
binaries, I'm glad to have radiance's full power on my disposal now
(thanks Fransesco!)

Also, this will not show all the rays returning to the light sources,
as this part of the calcuation never gets fully 'traced', the reason
being that the direct calculation in Radiance attempts to minimize the
actual number of rays followed to sources as an optimization. If you
want to see the paths all the way back to the sources, you'll have to
get into the rt/source.c file and start modifying the code directly.

  Now that would be computationally perverse to undo that! Hmmmmmmm...
  Since I'm only starting to program (god bless python) that might be
somewhat ambitious :wink:
  Also tracing the rays to the source would be for sake of the image,
there's no numerical ardour to get that done...

Regarding the -s option in xshowtrace, you can go in and change it
yourself. The sleep call is on line 260 in px/xshowtrace.c.
Unfortunately, sleep only takes integer arguments, but you can replace
it with a call to nanosleep() on most systems.

  Now that sounds like something I could pull off!
  Cheers, thanks a lot!

Jelle.