Radiance Vs Radiosity

Rob, Could not agree more. I think people put quite a bit of stock in a
well rendered image and the arguments can get blurred. Especially when
you are talking about something as subjective as lighting as a whole.
Are you after accurate results for research purposes, close enough
results, convincing pictures, etc? I know we have some very impressive
images here in our office that were developed with the latest
Lightscape/Viz that look (and were developed to look) identical to the
photos they were extrapolated from. And the associated false color
images actually gain a certain amount of credibility based simply on how
"real" the renderings look. Which as you pointed out has nothing to do
with the accuracy of the calculation result since the ray-traced part
does not affect the numerical results! :wink:

Mark

I think some confusion stems from the fact that Lightscape & Viz have a

ray-tracing capability that you can apply, as a post-process. When you

apply that to a Lightscape/Viz model, the specular reflections are
*rendered*, but not *calculated*. So you have a rendering that looks
somewhat accurate, but at that point that's all you have. You cannot
derive quantitative luminance/illuminance information from the image at

that point. That data always comes from the radiosity-calculated
model, and that's fundamentally flawed because of the lack of specular

reflections (and in Lightscape's case, no diffuse transmissions
either).

···

=================
    Rob Guglielmetti
www.rumblestrip.org

I read through the pab-opto comparisons (thanks Peter!). Looked pretty
good. Too bad Viz had not incorporated Lightscape at the time. Not
sure what AutoDesk's plans are, but I think Viz is already more powerful
than Lightscape in all but a couple of areas. Had a couple of questions
though that came up after reading the comparison... They are kind of
general radiance questions.
Are ambient files really independent of the viewfile? Somewhere in
Rendering with Radiance (where it talks about ambient files) I had the
impression different views required different ambient files, and thus I
stopped using ambient files the way other people seem to and started
using view dependent ambient files. Meaning I would use one ambient
file per view regardless of the fact that scene was the same. If this
is not right, and one file will work for any view, someone please let me
know. I noticed Rob Guglielmetti also "generates multiple fisheye views
for ambient cache, prior to running calcs". (Sounds like ambient files
are not view dependent).

Another question that came up was regarding ambient bounces. On pages
29-31, "Typical" ambient bounces are 3-7, and then various calculation
times are shown for ab=0 (.135 hours), ab=1 (.431 hours), ab=7 (24
hours). How in the world does one accomplish ab=7 in only 24 hours on a
~400MHz computer? Wow!.. I was blown away considering I've been
running some ab=2 simulations on a 2.66GHz computer and taking 24 hours
each. Were all the other values minimized (except for ad=16,000?).
Well it's got me thinking about being more careful about how parameters
are assigned.

Then, something I always thought was a hole missing from Radiance, and
perhaps is really just a limitation in my own radiance knowledge is
this. All other lighting programs that I am aware of allow you to place
calculation grids, run calcs, and then display the grid point results in
relation to the calculation model (though most can't do false color
images). Most programs will even export the results to DXF for
incorporation into CAD programs. It seems rshow can do some of this?

And last but not least, what is the trick on page 55? Replicating
image maps in a way that their pattern does not become repetitive. Are
we talking about making sure the edges match-up and that the image is
generally uniform?

Well thanks for responding to my original post.

Mark

Are ambient files really independent of the viewfile?

No, not really :wink: They are, hmm... "populated" depending on the view, as the samples depend on the view. But if you change the view, the prior samples should still be valid (as long as you didn't change the scene). So the samples can be reused for different views.

As I understand the panoramic picture ambient file topic, the idea is to get the ambient file "full" before starting the actual rendering. This is just the same idea that is behind the "initial ambient file" trick, where people render the images in low resolution first, so that the ambient file collects ambient data during a fast rendering, and with that, the final rendering is started. You can get some problems if you start the final rendering with an empty ambient file, as the changes in the beginning can show up in the image.

However, there should never be a reason not to re-use the ambient file in an unchanged scene and with unchanged ambient parameters (right?)!

CU Lars.

Lars O. Grobe
[email protected]

Rob, Could not agree more. I think people put quite a bit of stock in a well rendered image and the arguments can get blurred. Especially when you are talking about something as subjective as lighting as a whole. Are you after accurate results for research purposes, close enough results, convincing pictures, etc?

The problem with convincing pictures is that a lot of clients don't have the eye to spot the con jobs. People are easily fooled by a slick image that looks nice, but the image can easily be telling a false story. You mention the subjectivity of lighting, and now I couldn't agree with you more; this is one of the things that fascinates me about Radiance, is that the Radiance image format is so much more than a picture -- it's a rich dataset. And the Radiance toolkit includes all these other great tools to extract that data and manipulate it, in ways that tell an honest story. pcond obviously comes to mind here.

I know we have some very impressive images here in our office that were developed with the latest Lightscape/Viz that look (and were developed to look) identical to the photos they were extrapolated from. And the associated false color images actually gain a certain amount of credibility based simply on how "real" the renderings look. Which as you pointed out has nothing to do with the accuracy of the calculation result since the ray-traced part does not affect the numerical results! :wink:

Right! It's funny, I've been doing this for quite a while now (first with Lumen Micro & AGI, then Lightscape, and now Radiance) and I have a pretty boring collection of images. But my images (and data) tell a richer story than the pretty pictures, to me and my colleagues. There are a few gifted people on this list who have mastered Radiance to the point that they can produce physically accurate AND pretty pictures, and I guess the rest of us settle for accuracy over slick glamour. All of us are using these tools to pursue the elusive goal of simulating reality, and to me that's just incredibly cool. I'm intrigued by the slick renderings coming out of the top visualization firms, and more impressed every day. But it's not what I want to do. I want to produce renderings that are tools. I wish the industry as a whole recognized the value of them more than they do.

···

On May 25, 2004, at 8:16 PM, Mark de la Fuente wrote:

=================
    Rob Guglielmetti
www.rumblestrip.org

Are ambient files really independent of the viewfile? Somewhere in Rendering with Radiance (where it talks about ambient files) I had the impression different views required different ambient files, and thus I stopped using ambient files the way other people seem to and started using view dependent ambient files. Meaning I would use one ambient file per view regardless of the fact that scene was the same. If this is not right, and one file will work for any view, someone please let me know. I noticed Rob Guglielmetti also "generates multiple fisheye views for ambient cache, prior to running calcs". (Sounds like ambient files are not view dependent).

Yes, ambient files are definitely independent of the view. As long as the scene does not change (materials, lights, sky conditions, TOD), you can use the same ambient file to assist thousands of image files. Animations are where the reuse of computational time that ambient files allow really benefit, I think.

Yeah, I was doing that multiple fisheye thing for one project, but Greg later straightened me out. That was not entirely necessary, because I was then using rtrace to calculate values at specific points, and that was the main goal, opposed to renderings. That overture calc business is more helpful for renderings, I think. But the fisheye views *were* still helpful for troubleshooting purposes.

.. I was blown away considering I've been running some ab=2 simulations on a 2.66GHz computer and taking 24 hours each. Were all the other values minimized (except for ad=16,000?). Well it's got me thinking about being more careful about how parameters are assigned.

Understatement of the year. Mastering Radiance is all about learning the nuances of parameterization, learning how to trade speed for accuracy. The good ones can gain accuracy without sacrificing speed. I'm not a good one. I still rely on brute force quite a bit. =8-)

Then, something I always thought was a hole missing from Radiance, and perhaps is really just a limitation in my own radiance knowledge is this. All other lighting programs that I am aware of allow you to place calculation grids, run calcs, and then display the grid point results in relation to the calculation model (though most can't do false color images). Most programs will even export the results to DXF for incorporation into CAD programs. It seems rshow can do some of this?

Agreed, it's a missing link. There are a few examples of using the cnt utility to create a grid, but it's not point and click. rshow is supposed to have this functionality but I have not been able to compile that on my machines yet. Certainly anyone with programming savvy could rwite something to place the calculated values (derived from rtrace and a supplied, cnt-generated grid of points) on a Radiance image, but it would have to be written. That PAB paper sums it up the best, something about Radiance's greatest strength is also its greatest hindrance. The open, unix toolbox approach to the suite allows for incredible flexibility, but you gotta roll up your sleeves and build the tools yourself.

And last but not least, what is the trick on page 55? Replicating image maps in a way that their pattern does not become repetitive. Are we talking about making sure the edges match-up and that the image is generally uniform?

Page 55 of the PAB paper? If I understand you correctly, I think you're referring to the comparison Peter makes between function files and image maps. His point is that image maps, tiled all over the place, will inevitably suffer from a detectable "edge-repeat" at some scale, whereas function files are mathematical representations of surface normal/color variations and are therefore less susceptible to this effect.

···

On May 25, 2004, at 8:18 PM, Mark de la Fuente wrote:

=================
    Rob Guglielmetti
www.rumblestrip.org

Rob Guglielmetti wrote:

...

Then, something I always thought was a hole missing from Radiance, and perhaps is really just a limitation in my own radiance knowledge is this. All other lighting programs that I am aware of allow you to place calculation grids, run calcs, and then display the grid point results in relation to the calculation model (though most can't do false color images). Most programs will even export the results to DXF for incorporation into CAD programs. It seems rshow can do some of this?

Agreed, it's a missing link. There are a few examples of using the cnt utility to create a grid, but it's not point and click. rshow is supposed to have this functionality but I have not been able to compile that on my machines yet. Certainly anyone with programming savvy could rwite something to place the calculated values (derived from rtrace and a supplied, cnt-generated grid of points) on a Radiance image, but it would have to be written. That PAB paper sums it up the best, something about Radiance's greatest strength is also its greatest hindrance. The open, unix toolbox approach to the suite allows for incredible flexibility, but you gotta roll up your sleeves and build the tools yourself.

rshow offered (offers, once I finally get the new version sorted out) a display of 2D grid values together with the 3D Radiance scenery. It also generates such a grid inside a planar surface which is defined by an offset from a Radiance polygon. There's no export to CAD format, as rshow is intended to be a visualization tool and tries hard to stay away from any CAD feature.
-Peter

···

--
pab-opto, Freiburg, Germany, http://www.pab-opto.de
[see web page to check digital email signature]