BLOSPRAY - OSPRay as a Blender render engine
Blender scene, with proxy object for the volume | Final render by OSPRay through BLOSPRAY |
---|---|
![]() |
![]() |
BLOSPRAY aims to provide high-quality rendering of scientific
data in Blender 2.8, with a specific focus on volumetric data and use in
an HPC (High-Performance Computing) context. To accomplish this BLOSPRAY integrates
the OSPRay ray tracing engine from Intel in Blender
as an external renderer.
See here for some example renders.
Currently, this software is somewhere between alpha and beta quality,
as it can already be used to produce useful visualizations, but lots of
things are still incomplete and/or missing. Also, not all errors are robustly
and gracefully handled yet.
In case you give it a try and/or have remarks or questions, let us know
at visualization@surfsara.nl! Bugs and feature requests can be entered
in this github project.
NON-goals:
BLOSPRAY is still in its early stages of development, but the following
basic functionality and integration with Blender features is already available,
with certain limitations :)
Please check this list before reporting a bug for a known issue
OSPRay
sub-menu. Note that connectingtests/volren.blend
)Known to be missing and/or buggy:
OSPRay (more specifically 2.0.x alpha) also has some limitations:
OSPRay’s SciVis and Path Tracer renderer do not have the same set of features
and performance characteristics:
Volumes are limited in their size, due to the relevant ISPC-based
code being built in 32-bit mode. See this issue.
Unstructured volumes can only contain float values (i.e. not integers).
See here
Intersecting/overlapping volumes are not (always?) rendered correctly
Lights generated in a scene plugin (see below) can not be transformed
currently on the OSPRay side.
OSPRay meshes are either pure-triangle, pure-quad or subdivision meshes.
The latter can mix polygons of different numbers of vertices, but might suffer
from being less efficient (XXX although this needs more testing).
The OSPRay orthographic camera does not support depth-of-field
Blender supports multiple colors per vertex (basically one per vertex per face loop),
while OSPRay only supports a single value per vertex.
During export the vertex colors are reduced to a single color per vertex
OSPRay does not support motion blur through its API, although the underlying
Embree library does
All rendering is done on the CPU, because, well … it’s OSPRay ;-)
The overall idea is to use Blender to set up the scene to render in the usual way.
Regular Blender meshes are handled mostly correct, although Blender’s Cycles
and EEVEE materials are currently not exported. A subset of the materials
supported by OSPRay is available, though.
To make use of (BL)OSPRAY-specific features a “plugin” can be enabled on a
normal mesh object. This plugin generates OSPRay-specific scene elements
that are handled independently from Blender. Examples of such elements are
volumetric data or point sets.
There are currently 3 types of plugins in BLOSPRAY:
Geometry plugins: these generate a single OSPGeometry
, such as OSPRay’s “spheres”
“streamlines” or an “isosurface”.
Volume plugins: these load (or generate) volumetric data in the form of an OSPVolume
.
Note that OSPRay supports regular volumetric grids, but also ununstructured grids
and AMR meshes.
Scene plugins: these can generate any set of OSPInstance
elements, plus
zero or more lights.
Meshes that have a plugin attached can be transformed in the Blender scene
in the usual way. Meshes with a volume plugin have a few more options
specific to volumes:
Note: the two options below are currently broken in 0.1!
One or more isosurfaces can be rendered through the volume
Slicing through the volume data with a separate set of slicing meshes. These
meshes must be attached as children to the mesh data that has the volume plugin
attached
All types of plugins can provide a proxy mesh, such as a bounding box or
simplified mesh, to be used as proxy in the Blender scene.
See the Plugin section below for more details.
BLOSPRAY consists of two parts:
render_ospray
) that implements the Blender external render engine. It handles scene export to OSPRay, retrieving the rendered image from OSPRay and other things.bin/blserver
after building) that receives the scene from Blender, calls OSPRay routines to do the actual rendering and sends back the image result.The original reason for this two-part setup is that there currently is no
Python API for OSPRay, so direct integration in Blender is not straightforward.
Neither is there a command-line OSPRay utility that takes as input a scene
description in some format and outputs a rendered image.
Plus, the client-server setup also has some advantages:
The separate render server can be run on a remote system, for example an HPC system
that holds a large scientific dataset to be rendered. This offloads most of the
compute-intensive rendering workload and memory/storage requirements of the data to be rendered
away from the (desktop) system running Blender.
It makes it feasible to use OSPRay’s Parallel Rendering with MPI
mode, by providing a variant of the render server as an MPI program. Again,
this parallel version of the server can be run remotely on an HPC system.
Note that this mode is currently not implemented yet.
The network protocol is currently not strongly tied to Blender, so the render server can be used in other contexts as well.
BLOSPRAY development becomes slightly easier as both Blender and the render
server can be independently restarted in case of crashes or bugs.
Of course, this client-server setup does introduce some overhead, in terms of
network latency and data (de)serialization and transfer. But in practice this overhead is
small compared to actual render times. Caching of data on the server
between renders helps reducing the overhead even further. However, for scenes with
thousands of objects, or where objects are instanced in large numbers the
network overhead will become noticeable (and sometimes even prohibitive).
Note that the render server currently doesn’t support loading multiple different
Blender scenes or serving different users at the same time. There is also
a manual action required to start/stop the render server.
There is a rudimentary plugin system that can be used to set up
custom scene elements that are represented by a proxy object in Blender,
but whose full representation and rendering is stored on the server side
in OSPRay. The original use case for plugins (and even BLOSPRAY itself) was
to make it easy to use OSPRay’s high-quality volume rendering of scientific data in a
Blender scene. Blender’s own volume rendering support is geared towards the built-in
smoke and fire simulations and isn’t really a good fit for scientific datasets.
Plus it is very hard to get more advanced volume data (e.g. AMR meshes) into Blender.
Apart from volumes, plugins can be used for other types of scene content as well,
like polygonal geometry or OSPRay’s builtin geometry types like spheres and
streamlines. Basically any scene element that can be created with the OSPRay API
can potentially be used during rendering through plugins.
The plugin system is especially useful when working with large scientific datasets
for which it is infeasible or unattractive to load into Blender. Instead, one
can use a proxy object, such as a cube mesh to represent a rectangular volume,
in a Blender scene and attach a plugin to it. During rendering BLOSPRAY will call the
plugin on the server to load the actual scene data associated with the proxy.
In this way Blender scene creation, including camera animation and lighting, can be
done in the usual way as the proxy object shows the bounding box of the data
and can even be transformed and animated.
A nice benefit of writing a plugin in C++ is that it allows one to load a large
dataset directly into memory, without having to go through the
Blender Python API in order to accomplish the same. The latter is usually
less efficient.
Note that BLOSPRAY plugins are different from OSPRay’s own Extensions,
that are also loadable at run-time. The latter are meant for extending OSPRay itself
with, for example, a new geometry type. BLOSPRAY plugins serve to extend Blender
with new types of scene elements that are then rendered in OSPRay.
For building:
release-2.0.x
branch from https://github.com/ospray/ospray.The code uses the JSON for Modern C++ library,
which is included in the sources
For the plugins:
VTK_QC_BOUND
option is enabledFor running the BLOSPRAY addon in Blender:
import numpy
in a Python console area)Note: BLOSPRAY is only being developed on Linux at the moment, on other
platforms it might only work after some code tweaks.
BLOSPRAY uses CMake for building in the usual way. There’s currently
only a very small set of BLOSPRAY specific switches that can be tweaked.
The current way to build BLOSPRAY is to make a build directory within
the source directory and build there. A make install
will then place
all files (server, plugins, test files) in a bin
subdirectory of the sources:
$ cd blospray
$ mkdir build
$ cd build
$ cmake -GNinja ..
# Configure, Generate
$ ninja install
$ cd ../bin
$ ls
blender-ospray-engine$ ls bin
blserver geometry_triangles.so libfaker.so scene_rbc.so
geometry_assimp.so geometry_vtk_streamlines.so plugin.h t_json
geometry_hyg_stars.so libblospray.so scene_boxes.so volume_disney_cloud.so
geometry_plane.so libblospray.so.0.1 scene_cornellbox.so volume_hdf5.so
geometry_ply.so libblospray.so.1 scene_gravity_spheres_volume.so volume_raw.so
Part of BLOSPRAY consists of a Blender add-on, but this is not being
distributed separately currently, as the development focus is getting
to a releasable state in terms of features.
Currently, the way to install the add-on is to clone this repository and then
make a symlink to the render_ospray
directory in the Blender addon directory.
It depends on the installation path of Blender itself what is the best way to
add this symlink:
You have Blender installed in a system-wide directory that is not writeable
(or you prefer to not alter the system-wide installation)
In this case the user-specific directory can be used. On Linux this
is $HOME/.config/blender/2.81
(see here
for the location on other platforms).
$ cd $HOME/.config/blender/2.81
# Create addons directory, if needed
$ mkdir -p scripts/addons
$ cd scripts/addons
# Create symlink to blospray addon
$ ln -sf <blospray-repo>/render_ospray render_ospray
You have Blender installed in a user-writable location. In this case you
can create the symlink directly in the installation location:
$ cd <blender-2.81>/2.81/scripts/addons
$ ln -sf <blospray-repo>/render_ospray render_ospray
In most cases Blender needs an extra Python module for the protobuf
dependency. This is most easily done using PIP and Blender’s included
Python interpreter:
$ <blender-2.81>/2.81/python/bin/python3.7m -m ensurepip --user
$ <blender-2.81>/2.81/python/bin/python3.7m -m pip install -U protobuf --user
Finally, enable the Render: OSPRay
add-on in Blender (Edit -> Preferences -> Add-ons
).
You should now have a new OSPRay
entry in the Render Engine
dropdown on the Render
properties tab. If not, check for error messages
in the console window where Blender is running.
./bin/blserver
and keep it running)Render Engine
to OSPRay
BLOSPRAY is licensed under the Apache License, version 2.0 (the same
license as OSPRay). See LICENSE-2.0.txt for more information.
BLOSPRAY uses the JSON for Modern C++
header-only library, which is included in this source distribution
as core/json.hpp
. This file is not part of BLOSPRAY and has a different
license, see its contents.
Some files, mostly separate test files, are not part of BLOSPRAY
itself. These files have license information included in their text,
where appropriate.
The file tests/teapot.obj
is based on the Teapot model from
the McGuire Computer Graphics Archive.
The separate meshes in the file were combined into a single one.
The file tests/ss002.128_3.bin.vtk
is derived from the Cosmogrid 512^3
simulation by Ishiyama et al. available at https://repository.surfsara.nl/datasets/cosmogrid/648.
One shapshot of the original particle data was mapped to a density
volume (log10 of 1+#particles) at 128^3. The original data is covered
by an MIT license for which the following holds:
Copyright 2011 Tomoaki Ishiyama, Steven Rieder, Junichiro Makino,
Simon Portegies Zwart, Derek Groen, Keigo Nitadori, Cees de Laat,
Stephen McMillan, Kei Hiraki, Stefan HarfstPermission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the “Software”),
to deal in the Software without restriction, including without
limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons
to whom the Software is furnished to do so, subject to the following
conditions:The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.