Rtpict overture

1

Hi all,

In the newest update at RW2022 @Greg_Ward showed how the rtpict was updated for better parallel runs. I do have a few questions though.

  1. This is only relevant for files that have -aa != 0?
  2. This only works with -af parameter set to a file?
  3. Would I benefit from running a low res thumbnail for overture or is it automatically done? The slides show that it will if “other than a picture is requested” which im unsure what is.
  4. any tricks on the overture setup? just a 300x300 image will do and then same ambient parameters and cache file for a more highres?

image
image1046×758 134 KB

2

Hi Mathias,

The rtpict overture calculation is designed to avoid redundant calculations rather than the traditional use, which is to simply improve image smoothness. It takes place when all of the following are true:

(a) The -n option is > 1

(b) The -ab parameter is > 0

(c) The -af parameter is assigned

(d) The -o* option is used with multiple output files as described in the man page

Without (a), it’s a single process so no shared values. Without (b), no indirect cache, so no need. Without (c), no place for shared data, so an overture does not work. Without (d), rtpict can shuffle the entire list of samples and do a “perfect” job of decorrelating indirect calculations, though there is some added cost in the long call to sort(1) at the end.

Hope that helps!
-Greg

3

Hi Greg,

reviving this old post because this is only 1/4 of a topic.

When using the rad program with rtpict (rpict= rtpict) the rad program still makes a separate overture call. Since, as I understand it rtpict handles this internally, would it be better/easy to update rad so that if rtpict overture=0 (I guess at line 860 of rad.c)? I can’t figure out a way to bypass with the command line other than running rad -n and ignoring the > /dev/null lines.

thanks,

Stephen

4

Hi Stephen,

I could hack this, but why would you use rtpict instead of rpict with rad? Rad is designed to handle multi-processing calls on a single view using rpiece, which is even better than rtpict and doesn’t have the same issue with coincident indirect cache calculations.

If you want to use rad for everything preceding the rendering, you can run it with OPT= something and feed the options file to rtpict with @something.

Cheers,
-Greg

5

Hi Greg,

With very large and complex electric lighting runs there are two problems with rpiece:

  • First, the overture calculation takes forever and cannot be multi-threaded, the cost of coincident cache calculations is less than not being able to multiprocess at all.
  • Second, with electric lighting of large spaces, it is often the case that a large number of fixtures will be visible in a single rpiece tile. Many renderings will complete very quickly for all but one tile, and again the image needs to wait for a single process. rtrace avoids this by parallelizing per pixel.

Before rtpict, we used to get around this with something like the OPT= process (but they need to be stripped of -pX) you suggest and feed the options to vwrays | rtrace, but rtpict simplified that process substantially since it can accept all of the same options.

maybe adding an OVERTURE (0 or 1) to the rif rendering variables or a flag to rad to disable the overture would be less of a hack?

6

For a bit more on the motivation of using rad: it goes beyond just rendering settings and process management. The rif file can be easily templated so that consistent render calls can be made across a wide range of options (different lighting groups, geometry options, material options). The simple rad shell commands are much less susceptible to user errors and much easier to edit than pairing separate calls to oconv and rtpict, making sure to match naming conventions, etc.

7

Well, the overture calculation when rad runs rpiece is executed simultaneously with starting the first N-1 tiles, so it doesn’t actually have to wait for it to finish as it does using rpict in non-parallel mode. My logic was that the overture calculation will (mostly) run ahead of the rpiece tiles due to its lower resolution, then I can start a final copy of rpiece to fill out the -N processes once the overture completes. That addresses your first issue.

Regarding the excess time to complete a final tile, this does happen with rpiece, but is mitigated by running more processes, which causes rad to choose smaller tiles. If you have 8 real cores and 8 virtual cores, running with -N 16 will give you smaller tiles and the final tiles will be running on their own cores as everything finishes up.

In the end, if you still prefer to use rad with rtpict, you can hack this yourself by not setting the AMBFILE= variable and instead using:

rpict = rtpict -af mycache.amb -n 8

There will be no overture calculation without an AMBFILE setting, but you’ll end up sharing cache values because you specified it above. No other hacks needed. (Should have thought of this earlier – you must have already been specifying the rtpict -n option this way.)

Cheers,
-Greg

8

Thanks Greg,

I should have thought of that earlier as well!

9

Stephen,

what is your experience calling rad like described here over using the rtpict + rad/options file that I thought you guys settled on last year per Rad program for generating parameters ?