Document: BgMemUsage.pdf
Link: https://www.horo.ch/docs/mine/pdf/BgMemUsage.pdf


Backdrop Memory Usage

Bryce holds everything in memory. An HDRI backdrop or a background image rendered in Bryce and used in another scene can be very nice but the memory impact and resolution depending on document size and camera FoV setting should be considered.


Measuring Memory Usage for Hi-Res LDRI Backdrops and HDRI

Using an HDRI made with the AF-S Nikkor 10-24 mm 1:3.5-4.5 G ED DX rectilinear lens set to 10 mm focal length. Two rows with eight images each were taken, four expositions each from 1/2 to 1/125 second at f-8 and 200 ISO. One row was taken at pitch -25°, the other one at pitch +50°. Each row had the photographs 45° offset in Yaw. The 64 individual 14-bit per colour pictures were assembled to 16 HDRIs using Picturenaut 3.0 and assembled to an HDRI panorama with PTGUI Pro 3.1.3 to a spherical panorama of 11,816 x 5,908 pixels. (If the 10.5 mm fisheye lens is used, maximum size of the panorama is around 8400 x 4200 pixels.) Tone-mapping was done with my AutoTM tool.

  § The panorama consists of 69,808,928 pixels,

  § The BMP consists of 3 bytes per pixel, which adds up to 209,426,784 bytes plus 56 bytes for the BMP header.

  § The HDRI consists of 12 bytes per pixel, which adds up to 837,707,136 bytes. Since the radiance file format stores only 4 bytes per pixel (3 for the r/g/b mantissas and 1 byte for the common exponent, and the file is compressed using a modified run length encoding (RLE) algorithm, the file size is considerably smaller.

[Picture]

The file size has nothing to do with the final memory usage. Memory usage depends on the size of the picture in bytes. A compressed file will have to be uncompressed and this is done in memory. Loading a compressed picture will use more memory temporarily and takes longer to load.

<<<< Page 2 >>>>

[Table]

All values are in MB. Interestingly, the HDRI does not need more memory than the LDRIs. If the HDRI is tone-mapped, it also uses roughly as much memory as the LDRI picture plus the mask. However, tone-mapping uses up a lot of memory which will be freed when the process is finished. Bryce was made large address aware, otherwise it were not possible to perform these tests. Neither were tone-mapping possible to create the LDRI if the tone-mapper were not set to LAA.

[Table]

Pano2VR creates the six cube faces from a spherical panorama, assigning the cube face size automatically. It appears that they are made larger by around 20%. If the cube faces are converted to a spherical panorama, the original panorama size is returned.

To render the 6 cube faces for a panorama, adhering to the following rules may prove advantageous.

1.	Determine the size of the spherical panorama desired (8000 x 4000).
2.	Calculate the number of pixels in the panorama (8000 x 4000 = 32,000,000).
3.	Multiply by 1.2 (32,000,000 x 1.2 = 38,400,000).
4.	Divide by 6 (38,400,000 / 6 = 6,400,000).
5.	Get root of result ( 6,400,000 = 2530).
6.	Render the 6 cube faces in this size (2530 x 2530).
7.	Transform cube faces to spherical and set desired size (8400 x 4200).


Memory Considerations

Using pre-rendered parts as LDRI backdrops saves a lot of render time but this comes at a memory penalty. Like for an HDRI as backdrop, render size and camera FoV determine the size of the panorama - and hence the memory - needed. As an approximation, we can consider the panorama as wrapped around a cylinder. The panorama width covers 360°. We can divide 360° by the true AoV used (FoV and Scale). The result is the part of the panorama that is visible to the camera and thus rendered. That fraction of the panorama needs to have at least as many pixels horizontal as the horizontal document size is set. Better would be double as much.
If FoV is set to 90° at Scale 100%, the AoV is 72°, which is a fifth of the full circle. The 11,800 pixel wide panorama is good for a document width of 2360 pixels, the 8400 pixel wide panorama for 1680 pixels. Again, half or at least 2/3 of that size would be better.

Using 60° at 100% (default setting) results in an AoV of 48°, which is 1/7.5 of 360°. Maximal render width would be 1570 for the 11,800 panorama or 1120 pixels for the 8400 one.


26-FEB-2012/horo