[P3D] pbrt, Version 4 (Early Release)

This is a custom version of the early release of pbrt-v4 for the PrISE-3D project, the rendering system that will be described in the forthcoming fourth edition of Physically Based Rendering: From Theory to Implementation. (The printed book will be available in mid-February 2023; a few chapters will be made available in late Fall of 2022; and the full contents of the book will be freely available six months after the book's release, like the third edition is already.)

We are making this code available for hardy adventurers; it's not yet extensively documented, but if you are familiar with previous versions of pbrt, you should be able to make your way around it. Our hope is that the system will be useful to some people in its current form and that any bugs in the current implementation might be found now, allowing us to correct them before the book is final.

Resources

• A number of scenes for pbrt-v4 are available in a git repository.
• The pbrt-v4 User's Guide.
• Documentation on the pbrt-v4 Scene Description Format.

Features

pbrt-v4 represents a substantial update to the previous version of pbrt-v3. Major changes include:

• Spectral rendering
  • Rendering computations are always performed using point-sampled spectra; the use of RGB color is limited to the scene description (e.g., image texture maps), and final image output.
• Modernized volumetric scattering
  • An all-new VolPathIntegrator based on the null-scattering path integral formulation of Miller et al. 2019 has been added.
  • Tighter majorants are used for null-scattering with the GridDensityMedium via a separate low-resolution grid of majorants.
  • Both emissive volumes and volumes with RGB-valued absorption and scattering coefficients are now supported.
• Support for rendering on GPUs is available on systems that have CUDA and OptiX.
  • The GPU path provides all of the functionality of the CPU-based VolPathIntegrator, including volumetric scattering, subsurface scattering, all of pbrt's cameras, samplers, shapes, lights, materials and BxDFs, etc.
  • Performance is substantially faster than rendering on the CPU.
• New BxDFs and Materials
  • The provided BxDFs and Materials have been redesigned to be more closely tied to physical scattering processes, along the lines of Mitsuba's materials. (Among other things, the kitchen-sink UberMaterial is now gone.)
  • Measured BRDFs are now represented using Dupuy and Jakob's approach.
  • Scattering from layered materials is accurately simulated using Monte Carlo random walks (after Guo et al. 2018.)
• A variety of light sampling improvements have been implemented.
  • "Many-light" sampling is available via light BVHs (Conty and Kulla 2018).
  • Solid angle sampling is used for triangle (Arvo1995) and quadrilateral (Ureña et al. 2013) light sources.
  • A single ray is now traced for both indirect lighting and BSDF-sampled direct-lighting.
  • Warp product sampling is used for approximate cosine-weighted solid angle sampling (Hart et al. 2019).
  • An implementation of Bitterli et al's environment light portal sampling technique is included.
• Rendering can now be performed in absolute physical units with modelling of real cameras as per Langlands & Fascione 2020.
• And also...
  • Various improvements have been made to the Sampler classes, including better randomization and a new sampler that implements Ahmed and Wonka's blue noise Sobol' sampler.
  • A new GBufferFilm that provides position, normal, albedo, etc., at each pixel is now available. (This is particularly useful for denoising and ML training.)
  • Path regularization (optionally).
  • A bilinear patch primitive has been added (Reshetov 2019).
  • Various improvements to ray--shape intersection precision.
  • Most of the low-level sampling code has been factored out into stand-alone functions for easier reuse. Also, functions that invert many sampling techniques are provided.
  • Unit test coverage has been substantially increased.

We have also made a refactoring pass throughout the entire system, cleaning up various APIs and data types to improve both readability and usability.

Finally, pbrt-v4 can work together with the tev image viewer to display the image as it's being rendered. As of recent versions, tev can display images provided to it via a network socket; by default, it listens to port 14158, though this can be changed via its --hostname command-line option. If you have an instance of tev running, you can run pbrt like:

$ pbrt --display-server localhost:14158 scene.pbrt

In that case, the image will be progressively displayed as it renders.

Custom version [Parameters]

Current version is an extension of pbrt-v4 with use of some specific needs required during thesis:

Extended command line parameter:

• --folder: {string} -- output folder of current rendered scene ;
• --nimages: {unsigned} -- number of independent images of spp samples to generate ;
• --independent: {bool} -- save or not in an independant way (default 1, hence true) ;
• --startindex: {unsigned} -- start output index of first generated image for new run ;
• --estimator: {string} -- Expected estimator as output ["mean", "mon", "pakmon", "mean_or_mon"] using src/pbrt/base/estimators.h Estimator factory.

Note: current version enable the use MoN (Median of meaNs) estimator as output:

• nbuffers: set the number of buffers (M-estimators) to use. It is a constant value in order to work on GPU. Value can be update and available at the top of the src/pbrt/estimators.h file (default 11). You need to compile again the pbrt version. A value of 1, is equivalent to classical mean estimator ;

Custom version [Features]

Stereoscopic, AutoStereoscopic, and OmniDirectionalStereoscopic (ODS) cameras

Stereocopic camera example into .pbrt file:

Camera "stereoscopic" "float fov" 50
        "string view" "right" 
#        "string view" "left" 
       "float eyeDistance" [0.065]  

Note: it is necessary to generate the right and left images separately.

AutoStereocopic camera example into .pbrt file:

Camera "autostereoscopic" "float fov" 50
       "integer view" [7]
       "integer nbView" [8]
       "float eyeDistance" [0.065]

ODS camera example into .pbrt file:

Camera "ODS" "float fov" 50
        "string view" "right" 
#        "string view" "left" 
       "float eyeDistance" [0.065]  

Note: it is necessary to generate the right and left images separately.

Note: only one view can be generated each time. The calculated view is based on the desired number of views but also on the distance fixed at eye level.

rgbcat2

rgbcat2 in an executable (available in build folder) in order to merge left and right images obtained from Stereoscopic camera.

Usage:

./rgbcat2 <image-left.png> <image-right.png> <output-image.png>

Renderder usage

While the converter tries to convert materials to pbrt's material model, some manual tweaking may be necessary after export. Furthermore, area light sources are not always successfully detected; manual intervention may be required for them as well. Use of pbrt's built-in support for converting meshes to use the binary PLY format is also recommended after conversion. (pbrt --toply scene.pbrt > newscene.pbrt).

Using pbrt on the GPU

To run on the GPU, pbrt requires:

• C++17 support on the GPU, including kernel launch with C++ lambdas.
• Unified memory so that the CPU can allocate and initialize data structures for code that runs on the GPU.
• An API for ray-object intersections on the GPU.

These requirements are effectively what makes it possible to bring pbrt to the GPU with limited changes to the core system. As a practical matter, these capabilities are only available via CUDA and OptiX on NVIDIA GPUs today, though we'd be happy to see pbrt running on any other GPUs that provide those capabilities.

pbrt's GPU path currently requires CUDA 11.0 or later and OptiX 7.1 or later. Both Linux and Windows are supported.

The build scripts automatically attempt to find a CUDA compiler, looking in the usual places; the cmake output will indicate whether it was successful. It is necessary to manually set the cmake PBRT_OPTIX7_PATH configuration option to point at an OptiX installation. By default, the GPU shader model that pbrt targets is set automatically based on the GPU in the system. Alternatively, the PBRT_GPU_SHADER_MODEL option can be set manually (e.g., -DPBRT_GPU_SHADER_MODEL=sm_80).

Even when compiled with GPU support, pbrt uses the CPU by default unless the --gpu command-line option is given. Note that when rendering with the GPU, the --spp command-line flag can be helpful to easily crank up the number of samples per pixel. Also, it's extra fun to use tev to watch rendering progress.

The imgtool program that is built as part of pbrt provides support for the OptiX denoiser in the GPU build. The denoiser is capable of operating on RGB-only images, but gives better results with "deep" images that include auxiliary channels like albedo and normal. Setting the scene's "Film" type to be "gbuffer" when rendering and using EXR for the image format causes pbrt to generate such a "deep" image. In either case, using the denoiser is straightforward:

imgtool denoise-optix noisy.exr --outfile denoised.exr