[Radiance-general] Radiance Vs Radiosity

[Rob Guglielmetti]

On May 25, 2004, at 8:18 PM, Mark de la Fuente wrote:
> 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.

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