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
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.