Mitsuba Development Blog

Hello all,

I’ve uploaded binaries for the Mitsuba 0.4.4 release. This is mainly a bugfix release to address issues concerning the previous version. There is, however, one new feature:

Improved Python bindings for rendering animations

It’s a fairly common operation to render a turntable animation of an object to understand its shape a little better. So far, doing this in Mitsuba involved many separate invocations of the renderer (one for each frame). Not only is this a bit tedious, but it also wastes a considerable amount of CPU time by loading and preprocessing the same scene over and over again. Python to the rescue!

In Mitsuba 0.4.4, the Python bindings make this kind of thing straightforward: simply load the scene and render out frames in a for loop. The following piece of code does this, together with motion blur. The work can be spread over the local cores or those on networked machines. Some setup code is omitted for brevity (see the Python chapter in the documentation for all details).

# Render a turntable with 360 / 2 = 180 frames
stepSize = 2
for i in range(0,360 / stepSize):
    # Compute the rotation at the beginning and the end of the frame
    rotationCur  = Transform.rotate(Vector(0, 0, 1), i*stepSize);
    rotationNext = Transform.rotate(Vector(0, 0, 1), (i+1)*stepSize);

    # Compute matching camera-to-world transformations
    trafoCur  = Transform.lookAt(rotationCur  * Point(0,-6,10),
        Point(0), rotationCur  * Vector(0, 1, 0))
    trafoNext = Transform.lookAt(rotationNext * Point(0,-6,10),
        Point(0), rotationNext * Vector(0, 1, 0))

    # Create an interpolating animated transformation
    atrafo = AnimatedTransform()
    atrafo.appendTransform(0, trafoCur)
    atrafo.appendTransform(1, trafoNext)
    atrafo.sortAndSimplify()
    sensor.setWorldTransform(atrafo) # Assign to the sensor

    # Submit the frame to the scheduler and wait for it to finish
    scene.setDestinationFile('frame_%03i.png' % i)
    job = RenderJob('job_%i' % i, scene, queue)
    job.start()
    queue.waitLeft(0)
    queue.join()

This is basically a 1:1 mapping of the C++ API. At this point, a good amount of the interfaces have been exposed, making it fun to prototype stuff while subjected to the amazing weightlessness of Python. Here, you can see an example of a video created this way (a turntable of the material test ball with a bumpy metal BSDF):

Other changes

• Photon mapper: In previous releases, the standard photon mapper could miss certain specular paths compared to the path tracer. They are now correctly accounted for.

• thindielectric: The thindielectric plugin computed incorrect transmittance values in certain situations; this is now fixed.

• Robustness: Improved numerical robustness when dealing with specular+diffuse materials, such as “plastic”.

• twosided: Fixed cases where the twosided plugin did not make a material two-sided as expected.

• Instancing: The shading computed shading frame was incorrect for non-rigid transformations.

• Cube shape: This recently added shape is now centered at the origin by default, to be consistent with the way that other shapes in Mitsuba work. This will require an extra translation in scenes which are already using the cube shape.

• TLS cleanup logic: on some platforms, the mtssrv binary crashed with an exception after finishing a rendering job, due to some issues with cleaning up thread-local storage.

• Other minor fixes and improvements, which are listed in the HG history

Hello all,

I’ve just uploaded binaries for a new version of Mitsuba. This release and the next few ones will focus on catching up with a couple of more production-centric features. This time it’s motion blur — the main additions are:

Moving light sources

The first image below demonstrates a moving point light source in a partially metallic Cornell box moving along a Rose curve. Because it’s rendered with a bidirectional path tracer, it is possible to see the actual light source. Due to the defocus blur of the camera, the point light shows up as a ribbon instead of just a curve.

Painting with light using a moving point source

This can be fairly useful even when rendering static scenes, since it enables building things like linear light sources that Mitsuba doesn’t natively implement.
Animating a light source is as simple as replacing its toWorld transformation

<transform name="toWorld">
 ... emitter-to-world transformation ...
</transform>

with the following new syntax

<animation name="toWorld">
   <transform time="0">
     ... transformation at time 0 ...
   </transform>

   <transform time="1">
     ... transformation at time 1 ...
   </transform>
</animation>

Mitsuba uses linear interpolation for scaling and translation and spherical linear interpolation for rotation. Higher-order interpolation or more detailed animations can be approximated by simply providing multiple linear segments per frame.

Moving sensors

Moving sensors work exactly the same way; an example is shown below. All new animation features also provide interactive visualizations in the graphical user interface (medieval scene courtesy of Johnathan Good).

Objects undergoing linear motion

Objects can be animated with the same syntax, but this is currently restricted to linear motion. I wanted to include support for nonlinear deformations in this release, but since it took longer than expected, it will have to wait until the next version.

Beware the dragon (model courtesy of XYZRGB)

Render-time annotations

The ldrfilm and hdrfilm now support render-time annotations to facilitate record keeping. Annotations are used to embed useful information inside a rendered image so that this information is later available to anyone viewing the image. They can either be placed into the image metadata (i.e. without disturbing the rendered image) or “baked” into the image as a visible label. Various keywords can be used to collect all relevant information, e.g.:

 <string name="label[10, 10]" value="Integrator: $integrator['type'],
   $film['width']x$film['height'], $sampler['sampleCount'] spp,
   render time: $scene['renderTime'], memory: $scene['memUsage']"/>

Providing the above parameter to hdrfilm has the following result:

Hiding directly visible emitters

Several rendering algorithms in Mitsuba now have a feature to hide directly visible light sources (e.g. environment maps or area lights). While not particularly realistic, this feature is convenient for removing a background from a rendering so that it can be pasted into a differently-colored document. Together with an improved alpha channel computation for participating media, things like the following are now possible:

Improved instancing

While Mitsuba has supported instancing for a while, there were still a few lurking corner-cases that could potentially cause problems. In a recent paper on developing fractal surfaces in three dimensions, Geoffrey Irving and Henry Segerman used Mitsuba to render heavy scenes (100s of millions of triangles) by instancing repeated substructures— this was a good incentive to fix the problems once and for all. The revamped instancing plugin now also supports non-rigid transformations. The two renderings from the paper shown below illustrate a 2D Gospel curve developed up to level 5 along the third dimension:

Miscellaneous

• Threading on Windows: Edgar Velázquez-Armendáriz fixed the thread local storage (TLS) implementation and a related race condition that previously caused occasional deadlocks and crashes on Windows

• Caching: Edgar added a caching mechanism to the serialized plugin, which significantly accelerates the very common case where many shapes are loaded from the same file in sequence.

• File dialogs: Edgar upgraded most of the “File/Open”-style dialogs in Mitsuba so that they use the native file browser on Windows (the generic dialog provided by Qt is rather ugly)

• Python: The Python bindings are now much easier to load on OSX. Also, in the new release, further Mitsuba core functions are exposed.

• Blender interaction: Fixed a issue where GUI tabs containing scenes created in Blender could not be cloned

• Non-uniform scales: All triangle mesh-based shapes now permit non-uniform scales

• NaNs and friends: Increased resilience against various numerical corner cases

• Index-matched participating media: Fixed an unfortunate regression in volpath regarding index-matched media that was accidentally introduced in 0.4.2

• roughdiffuse: Fixed texturing support in the roughdiffuse plugin

• Photon mapping: Fixed some inaccuracies involving participating media when rendered by the photon mapper and the Beam Radiance Estimate

• Conductors: Switched Fresnel reflectance computations for conductors to the exact expressions predicted by geometric optics (an approximation was previously used)

• New cube shape: Added a cube shape plugin for convenience. This does exactly what one would expect.

• The rest: As usual, a large number of smaller bugfixes and improvements were below the threshold and are thus not listed individually—the repository log has more details.

Where to get it

The documentation was updated as well and has now grown to over 230 pages. Get it here.
The new release is available on the download page

The next bug-fix release of Mitsuba is available, which has the following improvements:

• Volumetric path tracers: improved sampling when dealing with index-matched medium transitions. This is essentially a re-implementation of an optimization that Mitsuba 0.3.1 already had, but which got lost in the bidirectional rewrite.

• Batch tonemapper: due to an unfortunate bug, the batch tonemapper in the last release produced invalid results for images containing an alpha channel. This is now fixed.

• Shapes: corrected some differential geometry issues in the “cylinder” and “rectangle” shapes.

• MLT: fixed 2-stage MLT, which was producing incorrect results.

• MEPT: fixed the handling of directional light sources.

• Robustness: got rid of various corner-cases that could produce NaNs.

• Filenames: to facilitate loading scenes created on Windows/OSX, the Linux version now resolves files case-insensitively if they could not be found after a case-sensitive search.

• Python: added Python bindings for shapes and triangle meshes. The Python plugin should now be easier to load (previously, this was unfortunately rather difficult on several platforms). The documentation was also given an overhaul.

• Particle tracing: I’ve decided to disable the adjoint BSDF for shading normals in the particle tracer, since it causes an unacceptable amount of variance in scenes containing poorly tesselated geometry. This affects the plugins ptracer, ppm, sppm and photonmapper. See the commit for further details.

• Subsurface scattering: fixed parallel network renderings involving the dipole model.

• Homogeneous medium & dipole: added many more material presets by Narasimhan et al.

• OBJ loader: further robustness improvements to the OBJ loader and the associated MTL material translator.

I’ve been hacking on a Mitsuba plugin for Rhino 5 and have some preliminary results to share.

Disclaimer: This is an early experimental integration plugin—if you don’t like to edit Mitsuba XML files by hand, it probably won’t be useful to you. The plugin currently only exports geometry and does not support editing materials. I am still waiting for McNeel to provide the necessary API hooks to be able to implement full material support.

On the other hand, the geometry export works quite smoothly even for large geometry with instances and all sorts of crazy shape types. It exports directly to Mitsuba’s native .serialized format, hence the export+open in Mitsuba operation is reasonably fast.

To install it, download Mitsuba.rhp and move it into your Rhinoceros 5.0 Beta/Plug-ins folder. This file then needs to be registered in the Settings using the Install button on the Plug-ins panel (see the first screenshot below). Now, restart Rhino. After the restart, there will be a new Mitsuba panel in the settings (second screenshot below). Select this panel and configure the path to where Mitsuba is installed.

Once this is done, exporting the geometry and opening it in the renderer is as simple as entering Mitsuba on the command prompt. Below, you can see a simple clay realtime preview of an object with sun & sky illumination.

Many thanks go to Nathan Coatney, who provided some guidance in the form of an early version of his Python-based LuxRender exporter.

I have just released a new version of Mitsuba. This is mostly a bugfix release, though there is one new feature: full user interface support for unicode across Linux, Windows, and OSX.

Note: This version does not yet work with the Blender exporter maintained by Bartosz Styperek.

Development will likely remain in bug-fixing mode for a while, since the last release introduced so many changes. Here is a list of the issues that were addressed in this particular version:

• negative pixel values in textures and environment maps are handled more gracefully.

• minor robustness improvements to the OBJ and COLLADA importers. They now handle multiple cameras in a single scene.

• fixed the Ubuntu packages so that they don’t depend on a specific version of the libjpeg development headers.

• fixed a stack overflow issue in the bidirectional path tracer, as well as some other crash-causing bugs that were found via the Breakpad reports.

• fixed an issue where sun and sky interpreted the combination of a ‘toWorld’ transform and explicit ‘sunDirection’ differently, causing misalignment.

• fixed a photon mapper regression involving environment maps.

• Edgar rewrote a piece of initialization code that prevented Mitsuba from running on Windows XP.

• Sean Bell contributed an improved setpath.sh script, which adds ZSH autocompletion on Linux.

• fixed some issues in the bidirectional abstraction layer when dealing with alpha masks.

• fixed a bug where the rectangle shape produced incorrect results when used as an area light.

• on OSX, the python bindings could not be loaded due to invalid library import paths—this now works.

Downloads are available here.

Enjoy!

Some folks encountered a DLL-loading related issue, which curiously isn’t reproducible on my Windows 7 test machine. The most likely cause of the problem has been identified and fixed.

If you download Mitsuba again, it should hopefully work.

Update 2: turns out that the problem was a missing Intel runtime library. The current binary distribution now includes this.

I am excited to announce version 0.4.0 of Mitsuba! This release represents about two years of development that have been going on in various side-branches of the codebase and have finally been merged.

The change list is extensive: almost all parts of the renderer were modified in some way; the source code diff alone totals over 5MB of text (even after excluding tabular data etc). This will likely cause some porting headaches for those who have a codebase that builds on Mitsuba, and I apologize for that.

Now for the good part: it’s a major step in the development of this project. Most parts of the renderer were redesigned and feature cleaner interfaces, improved robustness and usability (and in many cases better performance). Feature-wise, the most significant change is that the renderer now ships with several state-of-the-art bidirectional rendering techniques. The documentation has achieved coverage of many previously undocumented parts of the renderer and can be considered close to complete. In particular, the plugins now have 100% coverage. Hooray!

Please read on for a detailed list of changes:

User interface

Here is a short video summary of the GUI-specific changes:

• Realtime preview: the VPL-based realtime preview was given a thorough overhaul. As a result, the new preview is faster and produces more accurate output. Together with the redesigned sensors, it is also able to simulate out-of-focus blur directly in the preview.

• Improved compatibility: The preview now even works on graphics cards with genuinely terrible OpenGL support.

• Crop/Zoom support: The graphical user interface contains an interactive crop tool that can be used to render only a part of an image and optionally magnify it.

• Multiple sensors: A scene may now also contain multiple sensors, and it is possible to dynamically switch between them from within the user interface.

Bidirectional rendering algorithms

Mitsuba 0.4.0 ships with a whole batch of bidirectional rendering methods:

• Bidirectional Path Tracing (BDPT) by Veach and Guibas is an algorithm that works particularly well on interior scenes and often produces noticeable improvements over plain (i.e. unidirectional) path tracing. BDPT renders images by simultaneously tracing partial lights path from the sensor and the emitter and attempting to establish connections between the two.

  The new Mitsuba implementation is a complete reproduction of the original method, which handles all sampling strategies described by Veach. The individual strategies are combined using Multiple Importance Sampling (MIS). A demonstration on a classic scene by Veach is shown below; in the images, s and t denote the number of sampling events from the light and eye direction, respectively. The number of pixel samples is set to 32 so that the difference in convergence is clearly visible.

  
  

  

  A classic test scene by Veach, rendered using plain path tracing.

  

  Listing of all individual sampling strategies used by BDPT. Many are too noisy to be used in this form…

  
  
  
  

  

  … but after re-weighting them using Multiple Importance Sampling, poor samples are discarded.

  

  The final image produced using BDPT

  
  
  
  

• Path Space Metropolis Light Transport (MLT) is a seminal rendering technique proposed by Veach and Guibas, which applies the Metropolis-Hastings algorithm to the path-space formulation of light transport.

  In contrast to simple methods like path tracing that render images by performing a naïve and memoryless random search for light paths, MLT actively searches for relevant light paths. Once such a path is found, the algorithm tries to explore neighboring paths to amortize the cost of the search. This is done with a clever set of path perturbations which can efficiently explore certain classes of paths. This method can often significantly improve the convergence rate of renderings that involve what one might call “difficult” input.

  To my knowledge, this is the first publicly available implementation of this algorithm that works correctly.

• Primary Sample Space Metropolis Light Transport (PSSMLT) by Kelemen et al. is a simplified version of the above algorithm.
  Like MLT, this method relies on Markov Chain Monte Carlo integration, and it systematically explores the space of light paths, searching with preference for those that carry a significant amount of energy from an emitter to the sensor. The main difference is that PSSMLT does this exploration by piggybacking on another rendering technique and “manipulating” the random number stream that drives it. The Mitsuba version can operate either on top a unidirectional path tracer or a fully-fledged bidirectional path tracer with multiple importance sampling. This is a nice method to use when a scene is a little bit too difficult for a bidirectional path tracer to handle, in which case the extra adaptiveness due PSSMLT can bring it back into the realm of things that can be rendered within a reasonable amount of time.

  This is the algorithm that’s widely implemented in commercial rendering packages that mention “Metropolis Light Transport” somewhere in their product description.

• Energy redistribution path tracing by Cline et al. combines aspects of Path Tracing with the exploration strategies of Veach and Guibas. This method generates a large number of paths using a standard path tracing method, which are then used to seed a MLT-style renderer. It works hand in and with the next method:

• Manifold Exploration by Jakob and Marschner is based on the idea that sets of paths contributing to the image naturally form manifolds in path space, which can be explored locally by a simple equation-solving iteration. This leads to a method that can render scenes involving complex specular and near-specular paths, which have traditionally been a source of difficulty in unbiased methods. The following renderings images (scene courtesy of Olesya Isaenko) were created with this method:
  
  

  

  A brass chandelier with 24 glass-enclosed bulbs

  

  Tableware with complex specular transport, lit by the chandelier

  

  Exterior-lit room; the glass egg contains an anisotropic medium

  
  
  
  
  

Developing these kinds of algorithms can be quite tricky because of the sheer number of corner cases that tend to occur in any actual implementation.  To limit these complexities and enable compact code, Mitsuba relies on a bidirectional abstraction library (libmitsuba-bidir.so) that exposes the entire renderer in terms of generalized vertex and edge objects. As a consequence, these new algorithms “just work” with every part of Mitsuba, including the shapes, sensors, and emitters, surface scattering models, and participating media. As a small caveat, there are a few remaining non-reciprocal BRDFs and Dipole-style subsurface integrators that don’t yet interoperate, but this will be addressed in a future release.

Bitmaps and Textures

The part of the renderer that deals with bitmaps and textures was redesigned from scratch, resulting in many improvements:

• Out-of-core textures: Mitsuba can now comfortably work with textures that exceed the available system memory.

• Blocked OpenEXR files: Mitsuba can write blocked images, which is useful when the image to be rendered is too large to fit into system memory.

• Filtering: The quality of filtered texture lookups has improved considerably and is now up to par with mature systems designed for this purpose (e.g. OpenImageIO).

• MIP map construction: now handles non-power-of-two images efficiently and performs a high-quality Lanczos resampling step to generate lower-resolution MIP levels, where a box filter was previously used. Due to optimizations of the resampling code, this is surprisingly faster than the old scheme!

• Conversion between internal image formats: costly operations like “convert this spectral double precision image to an sRGB 8 bit image” occur frequently during the input and output phases of rendering. These are now much faster due to some template magic that generates optimized code for any conceivable kind of conversion.

• Flexible bitmap I/O: the new bitmap I/O layer can read and write luminance, RGB, XYZ, and spectral images (each with or without an alpha channel), as well as images with an arbitrary number of channels. In the future, it will be possible to add custom rendering plugins that generate multiple kinds of  types of output data (i.e. things other than radiance) in a single pass.

Sample generation

• sobol: A fast random-access Sobol sequence generator using the direction numbers by Joe and Kuo.

• halton & hammersley: These implement the classic Halton and Hammersley sequences with various types of scrambling (including Faure permutations)

Apart from producing renderings with less noise, these can also used to make a rendering process completely deterministic. When used together with tiling-based rendering techniques (such as the path tracer), these plugins use an enumeration technique (Enumerating Quasi-Monte Carlo Point Sequences in Elementary Intervals by Grünschloß et al.) to find the points within each tile.

Sensors and emitters (a.k.a. cameras and light sources)

The part of Mitsuba that deals with cameras and light sources was rewritten from scratch, which was necessary for clean interoperability with the new integrators. To convey the magnitude of these modifications, cameras are now referred to sensors, and luminaires have become emitters. This terminology change also reflects the considerably wider range of plugins to perform general measurements, rendering an image being a special case. For example, the following sensors are available:

• Perspective pinhole and orthographic sensor: these are the same as always and create tack sharp images (demonstrated on the Cornell box and the material test object).
  
  

  

  

  
  
  
  

  

  

  
  
  
  

• Perspective thin lens and telecentric lens sensor: these can be thought of as “fuzzy” versions of the above. They focus on a planar surface and blur everything else.

  Lens nerd alert: the telecentric lens sensor is particularly fun/wacky! Although it provides an orthographic view, it can “see” the walls of the Cornell box due to defocus blur

  
  

  

  

  
  
  
  

  

  

  
  
  
  
• Spherical sensor: a point sensor, which creates a spherical image in latitude-longitude format.
  
  

  

  
  
  
  

• Irradiance sensor: this is the dual of an area light. It can be attached to any surface in the scene to record the arriving irradiance and “renders” a single number rather than an image.

• Fluence sensor: this is the dual of a point light source. It can be placed anywhere in the scene and measures the average radiance passing through that point.

• Radiance sensor: this is the dual of a collimated beam. It records the radiance passing through a certain point from a certain direction.

The emitters are mostly the same (though, built using the new interface). The main changes are:

• Environment emitter: the new version of this plugin implements slightly better importance sampling, and it supports filtered texture lookups.

• Skylight emitter: The old version of this plugin used to implement the Preetham model, which suffered from a range of numerical and accuracy-related problems. The new version is based on the recent TOG paper An Analytic Model for Full Spectral Sky-Dome Radiance by Lukáš Hošek and Alexander Wilkie. The sun model has also been updated for compatibility. Together, these two plugins can be used to render scenes under spectral daylight illumination, using proper physical units (i.e. radiance values have units of W/(m^2 ⋅ sr ⋅ nm)). The sky configuration is found from the viewing position on the earth and the desired date and time, and this computation is now considerably more accurate. This may be useful for architectural or computer vision applications that need to reproduce approximate lighting conditions on a certain time and date (the main caveat being that these plugins do not know anything about the weather).
  

  
  

  

  A coated copper object under skylight illumination.

  

  The same object lit by the sun only.

  

  The “sunsky” emitter combines these two.

  
  
  
  
  

When rendering with bidirectional rendering algorithms, sensors and emitters are now interpreted quite strictly to ensure correct output. For instance, cameras that have a non-infinitesimal aperture are represented as actual objects in the scene that collect illumination—in other words: a thin lens sensor facing a mirror will see itself as a small 100% absorbing disc. Point lights are what they really are (i.e. bright points floating in space.) I may work on making some of this behavior optional in future releases, as it can be counter-intuitive when used for artistic purposes.

Other notable extensions and bugfixes:

• obj: The Wavefront OBJ loader now supports complex meshes that reference many different materials. These are automatically imported from a mtl file if present and can individually be overwritten with more specialized Mitsuba-specific materials.

• thindielectric: a new BSDF that models refraction and reflection from a thin dielectric material (e.g. a Glass window). It should be used when two refraction events are modeled using a single sheet of geometry.

• blendbsdf: a new BSDF that interpolates between two nested BSDFs based on a texture.

• mfilm: now supports generating both MATLAB and Mathematica-compatible output.

• hdrfilm: replaces the exrfilm plugin. This new film plugin can write both OpenEXR, Ward-style RGBE, and PFM images.

• ldrfilm: replaces the pngfilm plugin. The new film writes PNG and JPEG images with adjustable output channels and compression. It applies Gamma correction and, optionally, the photographic tonemapping algorithm by Reinhard et al.

• dipole: the dipole subsurface scattering plugin was completely redesigned. It now features a much faster tree construction code, complete SSE acceleration, and it uses blue noise irradiance sample points.
  

  

  XYZRGB Dragon model rendered using the new dipole implementation

  

  The same scene rendered with a different material density

  
  

• Handedness, part 2: this is a somewhat embarrassing addendum to an almost-forgotten bug. Curiously, old versions of Mitsuba had two handedness issues that canceled each other out—after fixing one of them in 0.3.0, all cameras became  left-handed! This is now fixed for good, and nobody (myself, in particular) is allowed to touch this code from now on!

• Batch tonemapper: the command-line batch tonemapper (accessible via mtsutil) has been extended with additional operations (cropping, resampling, color balancing), and it can process multiple images in parallel.

• Animation readyness: one important aspect of the redesign was to make every part of the renderer animation-capable. While there is no public file format to load/describe the actual animations yet, it will be a straightforward addition in a future 0.4.x release.

• Build dependencies: Windows and Mac OS builds now ship with all dependencies except for SCons and Mercurial (in particular, Qt is included). The binaries were recompiled so that they rely on a consistent set of runtime support libraries. This will hopefully end build difficulties on these platforms once and forever.
  Note: The entire process for downloading the dependencies and compiling Mitsuba has changed a little. Please be sure to review the documentation.

• CMake build system: Edgar Velázquez-Armendáriz has kindly contributed a CMake-based build system for Mitsuba. It essentially does the same thing as the SCons build system except that it is generally quite a bit faster. For now, it is still considered experimental and provided as a convenience for experienced users who prefer to use CMake. Both build systems will be maintained side-by-side in the future.

• SSE CPU tonemapper: When running Mitsuba through a Virtual Desktop connection on Windows, the OpenGL support is simply too poor to support any kind of GPU preview. In the past, an extremely slow CPU-based fallback was used so that at least some kind of tonemapped image can be shown. Edgar replaced that with optimized SSE2 code from his HDRITools, hence this long-standing resource hog is gone.

• SSE-accelerated Mersenne Twister: Edgar has also contributed a patch that integrates the SSE-accelerated version of Mersenne Twister by Mutsuo Saito and Makoto Matsumoto, which is about twice as fast as the original code.

• Multi-python support: some platforms provide multiple incompatible versions of Python (e.g. 2.7 and 3.2). Mitsuba can now build a separate Python integration library for each one.

• Breakpad integration: Mitsuba will happily crash when given some sorts of invalid input (and occasionally, when given valid input). In the past, it has been frustratingly difficult to track down these crashes, since many users don’t have the right tools to extract backtraces. Starting with this release, official Mitsuba builds on Mac OS and Windows include Google Breakpad, which provides the option to electronically submit a small crash dump file after such a fault. A decent backtrace can then be obtained from this dump file, which will be a tremendous help to debug various crashes.

• boost::thread: Past versions of Mitsuba have relied on pthreads for multithreading. On Windows, a rather complicated emulation layer was needed to translate between this interface and the very limited native API. Over the years, this situation has improved considerably so that a simpler and cleaner abstraction, boost::thread, has now become a satisfactory replacement on all platforms. Edgar ported the all of the old threading code over to boost.

Compatibility:

There were some changes to plugin names and parameters, hence old scenes will not directly work with 0.4.0. Do not panic: as always, Mitsuba can automatically upgrade your old scenes so that they work with the current release. Occasionally, it just becomes necessary to break compatibility to improve the architecture or internal consistency. Rather than being tied down by old decisions, it is the policy of this project to make such changes while providing a migration path for existing scenes.

When upgrading scenes, please don’t try to do it by hand (e.g. by editing the “version” XML tag). The easiest way to do this automatically is by simply opening an old file using the GUI. It will then ask you if you want to upgrade the scene and do the hard work for you (a backup copy is created just in case). An alternative scriptable approach for those who have a big stash of old scenes is to run the XSLT transformations (in the data/schema directory) using a program like xsltproc.

Documentation

A lot of work has gone into completing the documentation and making it into something that’s fun to read. The images below show a couple of sample pages:

The high resolution reference manual is available for download here: documentation.pdf (a 36MB PDF file), and a low-resolution version is here: documentation_lowres.pdf (6MB). Please let me know if you have any suggestions, or you find a typo somewhere.

Downloads:

To download this release along with set of sample scenes that you can play with, visit the download page. Enjoy!

I’ve just uploaded a video capture of my talk on Manifold Exploration, for those who didn’t see it at SIGGRAPH:

This will all be available in the next version of Mitsuba, which is close to its release. The last remaining item that I’m now working on is an improved version of the real-time preview, which hopefully wont’t take more than 1-2 weeks.

Mitsuba was used to render the results and illustrations in several technical papers that have just received their final acceptance to SIGGRAPH 2012. The ones that I know of are listed below (if I missed yours, please let me know!)

• Manifold Exploration: A Markov Chain Monte Carlo technique for rendering scenes with difficult specular transport (by Wenzel Jakob and Steve Marschner)

  Abstract: It is a long-standing problem in unbiased Monte Carlo methods for rendering that certain difficult types of light transport paths, particularly those involving viewing and illumination along paths containing specular or glossy surfaces, cause unusably slow convergence. In this paper we introduce Manifold Exploration, a new way of handling specular paths in rendering. It is based on the idea that sets of paths contributing to the image naturally form manifolds in path space, which can be explored locally by a simple equation-solving iteration. This paper shows how to formulate and solve the required equations using only geometric information that is already generally available in ray tracing systems, and how to use this method in in two different Markov Chain Monte Carlo frameworks to accurately compute illumination from general families of paths. The resulting rendering algorithms handle specular, near-specular, glossy, and diffuse surface interactions as well as isotropic or highly anisotropic volume scattering interactions, all using the same fundamental algorithm. An implementation is demonstrated on a range of challenging scenes and evaluated against previous methods.

  Gallery: the following images are courtesy of Wenzel Jakob and Steve Marschner. The interior scene was designed by Olesya Isaenko.

  

  A brass chandelier with 24 glass-enclosed bulbs

  

  Tableware with complex specular transport, lit by the chandelier

  

  Exterior-lit room; the glass egg contains an anisotropic medium

  
  
  
• Structure-aware Synthesis for Predictive Woven Fabric Appearance (by Shuang Zhao, Wenzel Jakob, Steve Marschner, and Kavita Bala)

  Abstract: Abstract: Woven fabrics have a wide range of appearance determined by their small-scale 3D structure. Accurately modeling this structural detail can produce highly realistic renderings of fabrics and is critical for predictive rendering of fabric appearance. But building these yarn-level volumetric models is challenging. Procedural techniques are manually intensive, and fail to capture the naturally arising irregularities which contribute significantly to the overall appearance of cloth. Techniques that acquire the detailed 3D structure of real fabric samples are constrained only to model the scanned samples and cannot represent different fabric designs.

  This paper presents a new approach to creating volumetric models of woven cloth, which starts with user-specified fabric designs and produces models that correctly capture the yarn-level structural details of cloth. We create a small database of volumetric exemplars by scanning fabric samples with simple weave structures. To build an output model, our method synthesizes a new volume by copying data from the exemplars at each yarn crossing to match a weave pattern that specifies the desired output structure. Our results demonstrate that our approach generalizes well to complex designs and can produce highly realistic results at both large and small scales.

  Gallery: the following images are courtesy of Shuang Zhao, Wenzel Jakob, Steve Marschner, and Kavita Bala.
  

  

  A Jacquard brocade pillow made using satin and twill weaves

  

  Fabric made using a large (96×96) wavy twill weave pattern

  

  A range of fabrics with complex weave patterns, synthesized from a library of Micro-CT scans

  
  
  

  Video:

• Stitch Meshes for Modeling Knitted Clothing with Yarn-level Detail (by Cem Yuskel, Jonathan Kaldor, Doug L. James, and Steve Marschner)

  Abstract:Recent yarn-based simulation techniques permit realistic and efficient dynamic simulation of knitted clothing, but producing the required yarn-level models remains a challenge. The lack of practical modeling techniques significantly limits the diversity and complexity of knitted garments that can be simulated. We propose a new modeling technique that builds yarn-level models of complex knitted garments for virtual characters. We start with a polygonal model that represents the large-scale surface of the knitted cloth. Using this mesh as an input, our interactive modeling tool produces a finer mesh representing the layout of stitches in the garment, which we call the stitch mesh. By manipulating this mesh and assigning stitch types to its faces, the user can replicate a variety of complicated knitting patterns. The curve model representing the yarn is generated from the stitch mesh, then the final shape is computed by a yarn-level physical simulation that locally relaxes the yarn into realistic shape while preserving global shape of the garment and avoiding “yarn pull-through,” thereby producing valid yarn geometry suitable for dynamic simulation. Using our system, we can efficiently create yarn-level models of knitted clothing with a rich variety of patterns that would be completely impractical to model using traditional techniques. We show a variety of example knitting patterns and full-scale garments produced using our system.

  Gallery: the following images are courtesy of Cem Yuksel. Some of the models are by Christer Sveen, Rune Spaans, and Alexander Tomchuk.

  

  Knitted tea cozy with a Stockinette pattern formed by repeated knit stitches

  

  A knitted sweater dress for a sheep with Ridged Feather pattern

  

  Knitted poncho with a Ribbing pattern, simulated on a mannequin

  
  

  

  Knitted glove with a Ribbing pattern formed by alternating knit and purl stitches

  

  Knitted dress on a mannequin

  

  Alien wearing a sweater with the Braid Cables pattern

  
  
  

  Video:

  
  
  
• Energy-based Self-Collision Culling for Arbitrary Mesh Deformations (by Changxi Zheng and Doug L. James)

  Abstract:
  In this paper, we accelerate self-collision detection (SCD) for a deforming triangle mesh by exploiting the idea that a mesh cannot self collide unless it deforms enough. Unlike prior work on subspace self-collision culling which is restricted to low-rank deformation subspaces, our energy-based approach supports arbitrary mesh deformations while still being fast. Given a bounding volume hierarchy (BVH) for a triangle mesh, we precompute Energy-based Self-Collision Culling (ESCC) certificates on bounding-volume-related sub-meshes which indicate the amount of deformation energy required for it to self collide. After updating energy values at runtime, many bounding-volume self-collision queries can be culled using the ESCC certificates. We propose an affine-frame Laplacian-based energy definition which sports a highly optimized certificate preprocess, and fast runtime energy evaluation. The latter is performed hierarchically to amortize Laplacian energy and affine-frame estimation computations. ESCC supports both discrete and continuous SCD, detailed and nonsmooth geometry. We demonstrate significant culling on various examples, with SCD speed-ups up to 26x.

  Gallery: the following images are courtesy of Chanxi Zheng and Doug L. James.

  

  

  

  
  
  

  Video:

  
  
  

• Precomputed Acceleration Noise for Improved Rigid-body Sound (by Jeff Chadwick, Changxi Zheng and Doug L. James)

  Abstract:
  We introduce an efficient method for synthesizing acceleration noise—sound produced when an object experiences abrupt rigid body acceleration due to collisions or other contact events. We approach this in two main steps. First, we estimate continuous contact force profiles from rigid-body impulses using a simple model based on Hertz contact theory. Next, we compute solutions to the acoustic wave equation due to short acceleration pulses in each rigid-body degree of freedom. We introduce an efficient representation for these solutions—Precomputed Acceleration Noise—which allows us to accurately estimate sound due to arbitrary rigid-body accelerations. We find that the addition of acceleration noise significantly complements the standard modal sound algorithm, especially for small objects

  Gallery: the following images are courtesy of Jeff Chadwick, Chanxi Zheng and Doug L. James.

  

  

  

  
  

  

  

  

  
  
  

• Reflectance models: The plastic, roughplastic, and roughcoating models have been completely overhauled. They are now reciprocal, and the rough variants support a texturable roughness.
  
• Intersection shapes: For convenience, I’ve added two new intersection primitives: rectangle and disk. These do exactly what the name implies .
• Documentation: The documentation has seen further improvements and clarifications. While of course still far from complete, it’s getting a bit larger every day.
• Wireframe texture: there is now a special texture that reveals the underlying mesh structure when attached to a triangle mesh.
• Linear blend material: it’s now possible to interpolate between two arbitrary BSDFs based on a texture.

Apart from working on SIGGRAPH paper submissions, I’ve been helping my advisor Steve Marschner teach Cornell’s graduate-level graphics course CS6630 this semester. My job was to create a compact rendering framework that students can use (and understand) in a sequence of increasingly difficult assignments.

PBRT and Mitsuba were not an option: they are both much too large for a one-semester course, and all fun components are already “done” (i.e. not available for assignments). So we decided to make a new framework called Nori.

It is always tempting to stop working on a piece of code as soon as it produces good-looking results (which might still be subtly incorrect). An important design goal of Nori was to really force students to end up with the right answer. Thus, each assignment comes with a battery of statistical hypothesis tests to ensure correctness.

Everything is licensed under the GPL and thus also available to instructors at other institutions. If you are interested, please get in touch.

In anticipation of the SIGGRAPH deadline on January 17, the public Mitsuba releases are now entering their annual “winter break”. This means that there probably won’t be any new releases in that time, plus  I may be slow in responding to email or bugtracker entries.

That is not to say that I’m taking a break . Some exciting changes will be coming to this project — stay tuned!

Due to popular demand, I’m releasing two scenes that demonstrate how to render heterogeneous participating media with Mitsuba. The first one is a (relatively low-res) plume of smoke generated by my fluid solver.

Plume of smoke

The second example is the blue scarf dataset from our SIGGRAPH 2010 project. It demonstrates how to render with the anisotropic volume scattering framework presented in that paper, and it uses the micro-flake scattering model implemented in Mitsuba.

SIGGRAPH 2010 Scarf scene

Enjoy! You can find the scene files on the download page.

Due to a server crash, this webpage was unavailable for the past two days.

For some reason, both the mainboard and hard disk broke down. There was a recent backup, hence nothing of serious importance was lost.