Source-linked AI summary

BlenderProc

Maximilian Denninger, Martin Sundermeyer, Dominik Winkelbauer, Youssef Zidan, Dmitry Olefir, Mohamad Elbadrawy, Ahsan Lodhi, Harinandan Katam

arXiv:1911.01911v1cs.CVcs.GRcs.LGcs.RO

TL;DR

Training computer-vision models requires large amounts of labeled imagery, but manually producing masks and labels is expensive and time-consuming. BlenderProc addresses this with an open, modular Blender-based pipeline that generates realistic scenes and multiple ground-truth outputs; it favors extensibility and data quality over speed, limiting suitability for video or reinforcement-learning loops.

  • Problem

    Manually masking and labeling training images for computer-vision tasks is expensive and time-consuming.

  • Method

    BlenderProc uses an open, modular, configurable Blender-based pipeline with standard modules for scene loading, camera poses, rendering, and annotated output generation.

  • Results

    BlenderProc generates realistic-looking images with segmentation masks, depth, and normal outputs, supporting training data generation in challenging scenarios.

  • Takeaways & Limitations

    The pipeline provides a reusable starting point and complete solutions for generating computer-vision data across multiple datasets and tasks.

  • Takeaways & Limitations

    Rendering speed was not the main objective, making BlenderProc difficult to use for video or reinforcement-learning loops.

Abstract

from arXiv · show

BlenderProc is a modular procedural pipeline, which helps in generating real looking images for the training of convolutional neural networks. These can be used in a variety of use cases including segmentation, depth, normal and pose estimation and many others. A key feature of our extension of blender is the simple to use modular pipeline, which was designed to be easily extendable. By offering standard modules, which cover a variety of scenarios, we provide a starting point on which new modules can be created.

I. Introduction

BlenderProc addresses the costly, time-consuming creation of labeled training images with a modular procedural pipeline that generates realistic scenes and precise annotations. It prioritizes usability, extensibility, and clear configuration over rendering speed.

  • Motivation: Manual masking and labeling is expensive and time-consuming, motivating an automated alternative.The stated motivation concerns generating training images for tasks such as pose estimation and instance segmentation.
  • Pipeline purpose: BlenderProc generates realistic scene images with segmentation masks, depth, and normal outputs for computer-vision training.The pipeline is built on Blender's Python API and supports multiple annotated outputs.
  • Applications: The pipeline can provide training data for challenging scenarios and has been used with SUNCG, the BOB challenge objects, and Replica reconstruction.These uses include normals and depth reconstruction for Replica.
  • Community development: Open-source release supports continued development and contributions from others.The authors aim to increase replacement of standard OpenGL renderers across datasets.
  • Design goals: Its modular design aims to remain easy to use, simple to extend, and clear to read.Documentation covers module usage and configurable settings.
  • Trade-off: Rendering speed was not the main objective, making BlenderProc difficult for video or reinforcement-learning loops.The authors prioritize data generation for datasets that are changed less often than architectures.

II. Related work

Prior synthetic-image pipelines are often fast and easy to implement but can produce unrealistic scenes by omitting consistent shading, object interactions, and physical constraints. BlenderProc instead emphasizes an accessible, configurable pipeline that provides starting points and complete solutions for computer-vision datasets.

  • Prior approaches: Earlier OpenGL-based approaches support tasks including viewpoint, instance segmentation, optical flow, and 6D pose estimation.These methods commonly generate images from 3D models or randomized object placements.
  • Limitations of prior work: Prior rasterization pipelines are easy to implement but may produce unrealistic images with inconsistent shading and neglected object interactions.Their emphasis on speed can omit interactions between nearby objects.
  • Physically based rendering: Physically based rendering has also been used for intrinsic decomposition, semantic segmentation, normal estimation, boundary detection, and object instance detection.The cited systems use different rendering backends, including Mitsuba and non-open-source implementations.
  • Novelty: BlenderProc differs by targeting a pipeline usable across the computer-vision field rather than merely demonstrating physically based rendering.Its stated objective is distinct from prior PBR work.
  • Contribution: The pipeline offers a configurable starting point and complete solutions for many datasets.This positioning is presented as the main practical goal of the system.
  • Pipeline operation: Modules are configured through a file to alter scenes, sample camera positions, render outputs, and store results in HDF5.Camera key points generate corresponding images, while renderers can be executed sequentially.

IV. Config

BlenderProc uses YAML configuration files divided into setup, global, and module-specific settings. Module order determines execution order, and dynamically loaded modules receive their corresponding settings.

  • Configuration structure: Each configuration file contains setup, global, and module sections.The setup defines Blender installation and package-related configuration.
  • Setup: The setup specifies the Blender installation path, version, and additional packages for Blender's Python distribution.The pip list can include packages required by custom modules.
  • Runtime requirements: The run.py script executes with the user's Python distribution and checks its requirements on first execution.This is separate from packages installed in Blender's Python distribution.
  • Global settings: Global settings are available to all modules, while module settings are accessible only to their corresponding module.The output directory can receive a command-line value through a placeholder such as <args:0>.
  • Module execution: Module order in the configuration determines execution order, and each module name maps to a dynamically loaded class derived from the module base class.The corresponding settings are passed to that class during execution.
  • Example: The example initializes Blender before running ObjLoader, which loads a single OBJ file into the scene.The configuration represents modules by name and associated settings.
  • Module documentation: Each module documents the configuration parameters that can be set for its class.This documentation is placed at the top of the class definition.

V. Loader

Loader modules populate Blender scenes with meshes, textures, categories, lamps, cameras, and camera poses. Specialized loaders support datasets such as SUNCG and provide the information needed by later rendering modules.

  • Scene loading: Loader modules import 3D meshes and other scene objects, including lamps and cameras.The basic loader can load one OBJ file.
  • Dataset support: The SUNCG loader imports OBJ files together with textures and categories used later by the segmentation renderer.It also loads the dataset's camera poses.
  • Camera loading: A generic camera loader accepts the structure of camera-position files and loads the associated poses.These poses support rendering images from specified viewpoints.

VI. Renderer

A renderer produces image-like outputs for a scene at camera key points, with configurable resolution, sampling, depth, and stereo options.

  • Renderers produce image-like outputs of a scene and are coupled to camera key points defined by loaders.
  • The standard color renderer generates an RGB image for each camera pose.
  • Resolution, render samples, depth output, and stereo rendering are configurable renderer options.More samples reduce rendering noise.
  • Figure 4 shows a rendered color image of a SUNCG scene.

A. Color renderer

The color renderer creates realistic-looking SUNCG images with configurable ray-bounce quality, while depth rendering relies on Blender’s internal estimation and has stated precision limitations.

  • The color renderer produces realistic-looking images from SUNCG scene data.Ceiling emission was used when room lamps did not provide sufficient realistic illumination.
  • Ray-bounce limits trade rendering speed against output quality, while glossy bounces control visible glossy effects.
  • Depth images use Blender’s internal depth estimation and may lack perfect precision because they rely on the Z-buffer.The precision was not evaluated, and depth rendering requires another renderer in combination.
  • Figure 5 depicts a depth image of a SUNCG scene.
  • Empty pixels are assigned infinity when objects do not cover the whole image.

C. Normal renderer

The supplied passages describe normal images as normalized XYZ values and explain how segmentation masks use object category identifiers or instance mappings.

  • Figure 6 shows a normal image, while Figure 7 shows a segmentation mask of a SUNCG scene.
  • C. Normal renderer: Normal images are normalized and represented as XYZ values.
  • D. Segmentation renderer: Segmentation requires each object to have a category_id identifying its dataset class.The SUNCG loader sets these identifiers, whereas custom loaders require manual assignment.
  • D. Segmentation renderer: Semantic segmentation stores class values from zero through the specified number of classes in a two-dimensional image.
  • D. Segmentation renderer: Instance segmentation additionally stores a dictionary mapping indices to classes and instance numbers in the HDF5 file.
  • D. Segmentation renderer: The map_by setting selects semantic segmentation with class or instance segmentation with instance.

VII. Sampler

BlenderProc provides configurable samplers for lights, cameras, and objects, including geometric sampling and proximity-based validity checks that can be logically combined.

  • Samplers can generate lights, cameras, and objects using settings-defined sampling strategies.Provided strategies include bounding boxes, spheres, sphere shells, and collision-free bounding-box sampling.
  • Uniform3dSampler samples within a box defined by minimum and maximum coordinates.
  • SphereSampler can sample on a sphere surface using a specified center and radius.
  • Samplers can perform proximity checks and combine conditions logically before accepting a sample.
  • The example accepts a camera pose only when it is at least one unit from visible objects and mean object distance is between one and four units.

VIII. Generation Time

BlenderProc generates data offline in batches, producing about 3,000 SUNCG images per hour on a single GPU. Generation time is currently constrained mainly by rebuilding the scene’s spatial tree for every frame.

  • 3,000 images per hour were generated for SUNCG files on a single GPU.The scenes were complex, and rendering is expected to be faster in many scenarios.
  • The pipeline combines rendered files for each camera pose into a compressed .hdf5 file.When camera poses are already sampled, only the specific renderers are called for each scene.
  • Generation time is mostly slowed by rebuilding the scene’s spatial tree for every frame.The authors identify avoiding this recalculation as a missing feature under discussion with the Blender Foundation.

IX. Examples

BlenderProc examples include sets of color, normal, depth, and segmentation images stored together in compressed containers. The project was still under heavy development, with several planned updates focused on physical variation, sampling, and rendering speed.

  • IX. Examples: Ten SUNCG scenes are shown with corresponding color, normal, depth, and segmentation images.Each image set is saved in one compressed .hdf5 container file.
  • IX. Examples: Planned updates include physics integration so objects can fall into containers under gravity.
  • IX. Examples: Other planned updates include category-based object swapping, more samplers, and faster rendering by avoiding scene recalculation.
Loading 1911.01911v1…