Release Notes for v0.6.0

Documentation

I provide documentation for the latest official release and intermediate (between releases) updates. The main difference is that one links to source code (for example to the FBmTexture struct), whereas the other does not, but is updated more frequently.

FBmTexture

The core and API of the renderer was hardly changed for this release, but there was at least one issue I dealt with, which created a couple of new entries in the online documentation:

• A new module pbrt::textures::fbm
• Containing a new struct called FBmTexture

In total three issues were closed:

1. CreateFBmFloatTexture
2. [panic] in Primitive::compute_scattering_functions()
3. [panic] in BVHAccel::recursive_build()

After fixing the issues and related panics the following scenes can be rendered now:

1. Bathroom
2. Buddha Fractal
3. Coffee Splash

The last scene renders, but the link goes to a still open issue, because the coffee material does not pick up the brownish color.

Blender

The biggest change for this release is that I started writing a parser for binary Blender files. There is a blog post, where I talk a bit about that, how to explore binary Blender files, and basically how to reconstruct useful information from their DNA.

Here is a new executable (beside the rs_pbrt, there is also a parse_ass_file):

$ ./target/release/examples/parse_blend_file --help
pbrt 0.6.0
Jan Walter <jan@janwalter.com>
Parse a Blender scene file and render it.

USAGE:
    parse_blend_file [OPTIONS] <path>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -i, --integrator <integrator>    ao, directlighting, path, bdpt, mlt
    -s, --samples <samples>          pixel samples [default: 1]

ARGS:
    <path>    The path to the file to read

The current version is very limited in it's usage, but it's a start. In theory a lot of different versions of Blender files should be handled, but in practice I will focus on two versions of Blender, v2.79b, the latest current release, and the soon to be released version v2.80. The following screenshot shows a scene, which can be found in the repository, under assets/blend, using Blender v2.79b:

The Blender header are the first 12 bytes and looks for those two supported versions like this:

$ hexdump -n 12 -C ~/tmp/rs_pbrt/blend-v279.blend
00000000  42 4c 45 4e 44 45 52 2d  76 32 37 39              |BLENDER-v279|
0000000c
$ hexdump -n 12 -C ~/tmp/rs_pbrt/blend-v280.blend
00000000  42 4c 45 4e 44 45 52 2d  76 32 38 30              |BLENDER-v280|
0000000c

The Blender source code (see readfile.c and decode_blender_header()) will tell you that after BLENDER there can be a underscore _ or dash -, meaning that the file contains pointers with either 4 or 8 bytes length. Just before the version number there can be a v or V, indicating little-endian or big-endian.

The current limitations are:

1. We assume that the Blender file contains pointers with 8 bytes. No correction is done to handle different platforms or non-matching files.
2. No big-endian support. We assume little-endian. The Intel x86 and also AMD64 / x86-64 series of processors use the little-endian format.
3. Only triangles and quads are expected for meshes and that's the only geometry which can be rendered right now. Quads are rendered as two triangles. There will be a warning for other polygons. In Blender you can convert those polygons via Ctrl-T.
4. No smooth meshes (yet). Vertex normals are read from the Blender files (and converted from short to float values), but they are not used for rendering (yet). This is most likely changed for the next release.
5. Materials are stored in a very complicated way (especially if nodes are used), so I decided to support only the emit value in Blender v2.79b (and earlier) because it's easier to access. Using a value greater than 0.0 turns those triangles into light emitters. All other material settings are ignored for now. Also several materials on the same mesh are not handled.
6. I do not deal with pointers (yet). That means that I assume that objects (defining a transformation matrix), their data (e.g. camera vs. mesh vs. lights), and their materials are all using the same names (internally they are stored using a prefix like CA, ME, LA, etc.). You can see that naming convention in the upper right part of the Blender screenshot above (showing the outliner).

The two settings you can currently change from the command line are:

• the integrator basically determines the rendering algorihm being used
• the pixel samples have influence on the quality of most rendering algorithms and are the easiest way to control the rendering times

The following command line renders the provided example scene with 16 pixel samples using Direct Lighting:

$ parse_blend_file -s 16 -i directlighting suzanne_integrator_test_2_79.blend 
parse_blend_file version 0.6.0 [Detected 4 cores]
BLENDER-v279
541264 bytes read
number of lights = 2
number of primitives = 980
integrator = "directlighting" [Direct Lighting]
Rendering with 4 thread(s) ...
1024 / 1024 [==============================================] 100.00 % 188.60/s
Writing image "pbrt.png" with bounds Bounds2 { p_min: Point2 { x: 0, y: 0 }, p_max: Point2 { x: 500, y: 500 } }

Whereas the next command line specifies to render the same Blender scene with 128 pixel samples using Bidirectional Path Tracing (BDPT):

$ parse_blend_file -s 128 -i bdpt suzanne_integrator_test_2_79.blend 
parse_blend_file version 0.6.0 [Detected 4 cores]
BLENDER-v279
541264 bytes read
number of lights = 2
number of primitives = 980
integrator = "bdpt" [Bidirectional Path Tracing (BDPT)]
Rendering with 4 thread(s) ...
1024 / 1024 [==============================================] 100.00 % 2.46/s
Writing image "pbrt.png" with bounds Bounds2 { p_min: Point2 { x: 0, y: 0 }, p_max: Point2 { x: 500, y: 500 } }

Here the results:

The End

I hope I didn't forget anything important. Have fun and enjoy the v0.6.0 release.