---
abstract: 'Astronomical data take on a multitude of forms – catalogs, data cubes, images, and simulations. The availability of software for rendering high-quality three-dimensional graphics lends itself to the paradigm of exploring the incredible parameter space afforded by the astronomical sciences. The software program Blender gives astronomers a useful tool for displaying data in a manner used by three-dimensional (3D) graphics specialists and animators. The interface to this popular software package is introduced with attention to features of interest in astronomy. An overview of the steps for generating models, textures, animations, camera work, and renders is outlined. An introduction is presented on the methodology for producing animations and graphics with a variety of astronomical data. Examples from sub-fields of astronomy with different kinds of data are shown with resources provided to members of the astronomical community. An example video showcasing the outlined principles and features is provided along with scripts and files for sample visualizations.'
author:
- 'Brian R. Kent'
title: Visualizing Astronomical Data with Blender
---

Introduction {#intro}
============

The combination of astronomy and computational sciences plays an important role in how members of the astronomical community visualize their data. Larger detectors in the optical/infrared (IR), increasing bandwidth in radio/millimeter interferometers, and large *N* astrophysical simulations drive the need for visualization solutions. These visualization purposes include exploring the dynamical phase space of data cubes, surface mapping, large catalogs, and volumetric rendering. The use of 3D computer graphics in the movie, television, and gaming industry has led the development of useful computer algorithms for optimizing the display of complex data structures while taking advantage of new hardware paradigms like utilizing graphic processing units (GPUs). Melding the exciting scientific results with state of the art computer graphics not only helps with scientific analysis and phase space discovery, but also with graphics for education and public outreach. Exploratory data visualization can offer a complementary tool next to traditional statistics [@2012AN....333..505G]. The work presented here is motivated by a dearth of clear instruction for astronomers in 3D graphics, animation, and accessible visualization packages. The visual impact of astronomy cannot be understated – for both the community of scientists and how to present our results to the public with higher accuracy.

We present a practical overview for astronomers to the capabilities of the software program Blender – an open-source 3D graphics and animation package. We take the approach of describing the features that will be of interest to various parties in astronomy – for both research visualization and presentation graphics. We aim to describe methods of data modeling, texturing, lighting, rendering, and compositing. Section \[vizdata\] discusses some of the relevant history of data visualization in the sciences. Section \[blender\] introduces the software, interface, and workflow. Section \[workflowsession\] describes the methodology of a sample workflow session using an astronomical position-position-frequency data cube at radio frequencies. Section \[examples\] describes examples from different fields within astronomy. Section \[summary\] summarizes the method overview and includes a demonstration video outlining the foundations and examples built upon in this paper.

Visualizing Data in the Sciences {#vizdata}
================================

Three-dimensional visualization allows for the exploration of multiple dimensions of data and seeing aspects of phase space that may not be apparent in traditional two-dimensional (2D) plotting typically used in analysis. Visualizing scientific data helps to complement the narrative of an observation or experiment. A number of studies have reviewed the progression and evolution of the field in software engineering and the sciences [@journals/ac/StaplesB99; @doi:10.1146/annurev.psych.52.1.305; @Diehl:2007:SVV:1209814; @Teyseyre:2009:OSV:1477065.1477374]. Beginning with the first graphs and charts of analog mapping data [@nla.cat-vn108090], data visualization has grown as technology now allows us to explore multiple dimensions of parameter spaces. @Friendly:06:hbook gives an overview of visual thinking and data presentation in mathematics, statistics, and the sciences. @Hansen2005 describe the computer graphics nomenclature, techniques of volume rendering, frameworks, and issues of perception in visualization.

The field of visualization in the physical sciences, including astronomy, faces challenges of scalability [@4015437]. Technology only brings us part of the way toward successfully understanding how to best visualize scientific data – understanding the theory of light, reflection, and color in graphics is needed to produce useful results [@Frenkel:1988:ASV:42372.42373]. In addition, using a workflow and framework that maximizes the use of layers and node composition can optimize the visualization of data [@Birn:2000:DLR:556898]. The goals of scientific visualization are twofold, as are the underlying challenges – we want to analyze quantitatively with high accuracy and precision our experiments, but at the same time produce stunning visuals that convey results beyond the scientific community [@Munzner2006].

Notable usage of scientific visualization, particularly with Blender, include the animation of maps from geographic information systems[GIS; @scianna2013], biology [@Autin:2012:UUC:2412364.2412538], and protein models [@2010arXiv1009.4801Z]. Algorithm development in medical imaging has paved the way in visualizing tomography and magnetic resonance [@Lorensen:1987:MCH:37402.37422]. @Drebin:1988:VR:378456.378484, @Elvins:1992:SAV:142413.142427, and @Yagel96classificationand list early reviews, developments, and taxonomy of algorithms for volume rendering and viewing, many of which started in the film and animation industry. While applications may be particular to specific science sub domains, the data and visualization goals are often similar and well aligned [@2007ASPC..376..621B]. @CGF:CGF3184 reviews the literature across the different physical sciences, breaking down visualization into the areas of 2D, 3D, and time-series data analyses.

With the advent of large sky surveys across the electromagnetic spectrum, short cadence temporal observations, and high-resolution simulations, astronomy now requires innovative use of software to analyze data [@2011ApJS..192....9T]. These data and methodologies can be catalogs [@Buddelmeijer; @931430; @2011AAS...21840822T], images , multidimensional datacubes [@2008ASPC..394..339D; @2011ASPC..442..625K], spectra and time-series [@2005ASPC..347..143L; @2006ASPC..359..285B; @2008CQGra..25r4025M], and simulations [@2001ASPC..238..499T]. New techniques are utilizing high-performance computing and access to distributed data [@Strehl02relationship-basedclustering; @2007PASP..119..898C]. Volume rendering, lighting, and shading play a key roll in how data are presented [@485155; @Direct_Interval_Volume_Visualization; @tvcg11_dvr]. Still, other experiments require new algorithms or innovative uses of existing hardware to push through challenging roadblocks that arise with new scientific paradigms [@nebulae-vis2012; @3c40fd5dd5]. @2011PASA...28..150H review different approaches in astronomy looking to the future of the field as data rates increase.

This work examines how astronomers can use the 3D graphics software Blender to visualize different types of astronomical data for purposes of both research and education and public outreach. We briefly compare Blender to other 3D packages in section \[comparisonsoftware\]. Using a 3D graphics package gives control over the 4th dimension of many datasets – namely time when animating videos. In addition, cinematic camera mechanisms and object manipulation used during rendering can give control other packages cannot [@Balakrishnan:1999:EBC:302979.302991]. While there is a wealth of specialized software libraries and algorithms available, we choose to introduce Blender to astronomers for its versatility and flexibility in handling different types of visualization scenarios in astronomy.

Blender
=======

Blender is a software package aimed at supporting high-resolution production quality 3D graphics, modeling, and animation. The open-source software is maintained by the Blender Foundation with a large user base and over 3.4 million downloads per year[^1]. The official release under the GNU GPL is available for Linux (source and pre-built binaries), Mac OS X, and Windows on 32-bit and 64-bit platforms. The graphical user interface (GUI) is designed and streamlined around an animator’s production workflow with a Python application program interface (API) for scripting. The API is advantageous in astronomy for loading data through PYFITS or CFITSIO as well as the growing collection of Python modules available for astronomy. The final composited output can be high-resolution still frames or video. While the package has numerous uses for game theory and design, video editing, and graphics animation, here we focus on the components most applicable to scientific visualization in astronomy. As an existing stand alone software package Blender provides a framework for both astronomical data exploration as well as education and public outreach. Motivations for usage in astronomy can be for exploratory data analysis by rendering volumetric data cubes, projecting and mapping onto mesh surfaces, 3D catalog exploration, and animating simulation results. Blender meets the requirements for both audiences – that of rigorous scientific accuracy in addition to the fluid cinema animations that bring the visual excitement of astronomy to the public.

Interface and Workflow
----------------------

The main Blender interface is shown in Figure \[maininterface\] and shows the object toolbar, main 3D viewport, transformation toolbar, data and model outliner, properties panel, and animation time line. A typical session workflow in 3D animation consists of the following steps:\
**Modeling.** The user generates models, called meshes, that conform to the type of data they wish to view (Figure \[meshexamples\]). Fundamental mesh primitives can act as data containers (for 3D data cubes), volumes (for gas flow simulations), 3D data points (for *N*-body simulations) or surfaces (for planetary surface maps). These shapes can morph and change their location, rotation, and scale during animation (Figure \[controls\]). Each mesh, no matter the size, consists of three basic components – vertices, edges, and faces. As the properties of these basic components are modified the data visualization begins to take shape.

**Texturing and Mapping.** Texturing is no longer limited to simple repetitive patterns of bit-mapped images on surfaces. Such surface texture mapping can be useful for planetary surfaces. 3D animation packages use a technique called UV-unwrapping (not to be confused with *u-v* coordinates used in interferometry). This technique projects surfaces of 3D models onto images (Figure \[uvmapping\])[^2]. Bump mapping is another useful utility allows the simulation of surface differences using perturbations of the surfaces’ normals during the render stage, where a full 3D model would have been needed otherwise [@Blinn:1978:SWS:965139.507101]. Blender does not possess the native ability to process astronomical coordinate headers specified in FITS file headers. Further processing through a Python script would be required in order to reorient surface models to the correct map projection; however, the capabilities exist for such endeavors, made easier by the Python API and supporting astronomical libraries[^3].

Astronomy data that is multidimensional has signal buried in noise and must use volumetric texturing. Human perception has the uncanny ability to act as an amazing signal extractor in one-dimensional spectra or two-dimensional images. However, seeing through a data cube requires us to allow signal emission to pass through a specified noise level. The computation of a ray as it passes in and out of one volumetric pixel (a voxel) to the next is given by a simple transfer function [@Levoy:1988:DSV:44650.44652]: $$C_{out, RGB}(u_i , v_j) = C_{in, RGB}(u_i , v_j)(1 - \alpha (x_i,y_j,z_k)) + c (x_i,y_j,z_k) \alpha (x_i,y_j,z_k)$$

where $C_{out, RGB}$ and $C_{in, RGB}$ are the red, green and blue (RGB) values of entry and exit at pixel $(u_i , v_j)$, and $\alpha$ is the opacity. $c (x_i,y_j,z_k)$ represents the color values at the point of interaction. Viewing this signal while “seeing through” the noise requires a combination of opacity channels (called alpha in the graphics industry) and ray tracing. The output pixel projected onto the camera plane is a composited red, green blue, and alpha (RGBA) rendered image [@Porter:1984:CDI:964965.808606]. In addition astrophysical visualization, this paradigm exists in other fields including medical imaging and examining large microscopy image stacks [@2011ApJS..197...18F; @568151; @Peng2010]. The paradigm is functionally the same as frequency channels in an astronomical data cube obtained with a radio telescope. Noncube voxel shapes present an interesting challenge for rendering algorithms, as some 3D models (or FITS data cube projections in astronomy) are not fundamentally a simple *x-y-z* orthogonal projection [@Reniers2008]. The current *VoxelData*[^4] base class in Blender allows for any mesh shape, including non-cubic, to be containers for voxel textures. This has potential for more complex map projections in astronomical surveys, large scale structure simulations, adaptive mesh refinement codes (AMR) or tessellation algorithms; it is typically used in animation for web/sponge-like constructs where coordinates can be mapped more easily onto non-cubic surfaces [@Crassin2009; @Strand2005].

**Lighting.** This step specifies how light will reflect, refract, and scatter off of physical surfaces. For astronomical data we will be concerned with how the data are presented on a graphics display that the user will see through the camera viewport. Various lighting algorithms are available depending on the presentation required [@Phong:1975:ICG].

**Animation.** Animation is accomplished by recording a change of state in the mesh models and their associated properties. This task uses “keyframing” to record location in 3D space, translation, rotation, and relative scaling between frames. Keyframe pivot points can rapidly increase in number - fortunately there is a built in feature, the “graph editor” that gives a schematic view of movement during animation. Figure \[grapheditor\]  shows the graphical view of a camera location as it tracks an object during an animation.

**Camera Control.** In addition to animating the meshes, models, and properties, camera movement and rotation, focal length, depth of field can be controlled and keyframed. This is one of the most useful features of Blender – giving the user complete control over how to view the generated animation. The camera can follow a path past a specified object while tracking a given feature. The camera can fly an orbit around a data cube, and then move in closer to chosen features. This utility is made easier in the GUI rather than the scripting mode because the user can see where the camera is moving relative to the models.

**Rendering.** Rendering can be handled by a number of internal rendering engines – the code that takes all the animation movements, textures, and lighting emission and absorption parameters, and generates the frames of animation, as viewed by the camera (or multiple cameras, for multiple rendering passes). Blender has two engines that are included by default – called Render and Cycles. Both serve useful purposes depending on the kind of data visualization being performed. We will discuss these and other third-party rendering engines in section \[renderingengines\].

**Compositing.** Complex data visualization usually benefits from having the aforementioned data models, animation, cameras, and render output separated for ease of manipulation. A single image in a raster graphics program such as Adobe Photoshop or GIMP is normally separated into multiple layers, channels, and paths to facilitate manipulating transparency, brightness, and saturation. In the same vein with 3D graphics and animation packages, multiple layers can be combined into the final animation via the “node compositing editor.” Using nodes gives the user a tree-based graph that links layers, models, and any final graphical corrections to the final view output into a map showing the progression on the final composite [@duff1985; @Brinkmann2008]. In a fashion similar to layers in astronomical browsing utility Aladin [@2011ASPC..442..683B], separate rendered frames from different source models can be combined. Final frames can be added together using the “video sequence editor” in a variety of standard graphics formats (PNG, GIF, JPEG, and TIF for single frames, and AVI, H.264, Quicktime, and MPEG for video among many others).

The GUI can change depending on the task at hand (modeling, animation, compositing, or sequencing), and can be fully customized by the user. Intricate details of using the GUI are beyond the scope of this introductory paper. The Blender documentation[^5] and workbooks contain numerous tutorials for learning how to navigate the interface [@Hess:2010:BFE:1893021]. Figure \[workflow\] shows an outline of the workflow process from modeling through the final render of a planetary surface map using data from the NASA *Viking* Orbiter[^6].

Blender Data Structures and Outliner {#blenderdatastructures}
------------------------------------

The Blender core is written in C, with C++ for windowing and Python for the API and scripting functionality. Native Blender files (\*.blend) contain headers with identifiers, pointer sizes, endianness, and versioning. These headers are followed by data blocks with sub headers containing identifier codes, data sizes, memory address pointers, and data structure indices. Each block contains data arrays for object names and types (mesh, light, camera, curve, etc.), data types, data lengths, and structures, which may contain sub arrays of the fields. The data block for an animated scene consists of structures detailing objects and their properties - locations of vertices, edges, faces, and textures, and how those might be affected by a given keyframe. A sample of how these data structures fit together in the workflow paradigm is shown in Figure  \[flowchart\]. Hovering over any element, button, or menu in the Blender interface gives a context sensitive reference to classes and methods in the API[^7]. These can be used to write procedural Python scripts for automating tasks within Blender.

Rendering Engines {#renderingengines}
-----------------

Blender can show real time previews of the animated scene in wireframe, solid, or textured mode, allowing the user to plan and anticipate when and where camera placements and movements need to take place. When the render and composite of all layers is required, the Blender data model is passed to a rendering engine, software that computes the emission, absorption, scattering, reflection, shading, and transport of simulated light onto the projected camera plane. The following rendering engines can be used with Blender; this list is not exhaustive, but gives the reader a number of open-source references to begin exploring different options.

**Render.** The first generation internal rendering engine is useful for most general purpose data visualizations that astronomers will encounter. It handles volumetric rendering well and supports GPU processing (*http://wiki.blender.org/index.php/Doc:2.6/Manual/Render*).

**Cycles.** This second generation rendering engine adds more realistic caustics to the rendering algorithm. In addition, the rendering path can be configured within the node-based compositor, allowing for rapid prototyping of a scene (*http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles*).

**LuxRender.** This open-source third party rendering engine that achieves fast raytracing with GPU processing and uses a progressive rendering algorithm (see references in @6183117; *http://www.luxrender.net/*).

**YafaRay.** This open-source third party raytracing and rendering engine that has the ability to save files to high dynamic range images formats [EXR; @Debevec:1998:RSO:280814.280864 *http://www.yafaray.org/*].

In addition, usage of the utility FFmpeg[^8] can be used to encode video to popular video formats, frame rates, from production quality high-definition (HD) video to sizes and data compressions more suitable to mobile devices.

Data Formats
------------

Combined with its Python API, Blender is able to import and export a number of data formats useful in astronomy. In addition to its native “blend” format described in Section \[blenderdatastructures\], the formats listed in Table \[blenderformats\] can be utilized for data input and output. ASCII tables with fields separated by delimiters can be imported via a number of native Python modules. FITS images and tables can be imported via PYFITS or CFITSIO onto surface or volumetric texture containers. JPEG, TIFF, PNG, and GIF images can be read natively by Blender and mapped onto surface textures. Mesh models can be imported or exported with industry standard Wavefront files, which consists of ASCII text defining vertex intersections [.OBJ; @0083492].

Single frames can be exported in a variety of image formats including JPEG, TIFF, PNG, GIF, and EXR, each with full control over binning and compression of the image output [@Wallace:1991:JSP:103085.103089]. Video output is dependent on the operating system; Windows, Linux, and Mac OS can all export MPEG and AVI video files. For Quicktime MOV and H.264/MPEG-4 (useful in mobile devices), the aforementioned FFmpeg utility can be used with Linux. Each format can also be imported into the video sequencer – a powerful feature of the software but beyond the scope of this paper.

High performance Computing
--------------------------

Visualizing and animating output for inspection or study can be run as parallel processes or a graphics processing unit [GPU; @2012PASA...29..340H]. Once keyframes have been inserted, frames generated from the render process become independent. These frames can be rendered through multiple threads on a GPU, multiple cores on a single processor, or on completely independent workstations. NVidia CUDA and OpenCL are both supported with appropriate hardware [@4626815; @5457293]. Completed animation sequences can be sent to “render farms” that will render and composite the final images or videos, taking advantage of cloud computing with this parallel intensive paradigm [@4839978]. Comparisons of high-performance computing paradigms clearly show the advantages in the improvement of computation times, not only in hardware but also with differing algorithms [@2010NewA...15..726B]. In the case of rendering with 3D graphics software like Blender, the choice of rendering tile size is important for optimizing the usage of threads on the GPU for parallel processing. Using tile sizes in powers of two is the most efficient choice for optimizing memory usage in a parallel processing scheme [@291528].

High performance computing in visualizing and animating data can be quantified with benchmarks trials comparing CPU and GPU rendering times. A single frame benchmark comparison was completed at a resolution of 960 $\times$ 540 pixels with rendering tile sizes of 8 $\times$ 8 pixels. The data were obtained from a variety of computer platforms and operating systems using the Cycles rendering engine (O. Amrein 2013, private communication). The benchmark test consisted of six camera views and 12 mesh objects totaling 86,391 polygons and 91,452 vertices. Figure \[gputrials\] plots the distribution of times for a) NVidia CUDA, b) OpenCL, and c) CPU processing all running the same benchmark Blender file. In these rendering trials using a GPU improves the mean rendering time by an average factor of $\sim$3.4 when compared to dual or quad-core CPU processing. The time trial benchmarks are shown in Table \[gputable\]. GPU enabled rendering is advantageous when considering the number of individual frames that might contribute to an animation.

Comparison with Other Software {#comparisonsoftware}
------------------------------

@Laramee:2008:CEC:1364835.1364838 compared a number of lower level graphics libraries, noting attributes suited to both research and industry. The benefit of Blender for astronomers is that it is freely available open-source software that runs on the Linux, Mac, and Windows and can be used with the GUI or through Python scripting. The GUI is not tied to any of the three operating systems and does not depend on the Microsoft Software Development Kit, Cocoa for Mac, or Gnome/KDE for Linux – it looks and functions the same on every system. Table \[softwarecompare\] compares Blender with other 3D graphics packages. Other packages exhibit similar capabilities in modeling and lighting, but are typically used with external rendering engines. Blender is unique in that it provides a self-contained environment for a end-to-end workflow without the need for extra software libraries or installations.

Required Resources
------------------

The workflow for modeling, texture mapping, and animation lends itself to relatively modest hardware, including laptops for preview renders and basic manipulation. However, because of the portability of the data structure, blend files can be easily copied to workstations or clusters for CPU/GPU intensive rendering output. Blender scripting uses Python 3.2, included with the binaries and source distribution. For the examples that are described in this paper we also make use of PYFITS and the Matplotlib libraries for data manipulation [@2000ASPC..216...67B; @4160265]. In addition, a three-button mouse is recommended for moving within the 3D view space.

Example Workflow Session {#workflowsession}
========================

We describe a workflow session applicable to visualizing a data cube in 3D. The motivation behind this example is to put into practice the concepts outlined in section \[blender\] and how they relate to actual astronomical data. The example position-position-frequency FITS data cube is from the M81 dwarf A galaxy observed with the The Nearby Galaxy Survey [THINGS; @2008AJ....136.2563W]. Studying the data cube in 3D allows for the understanding of its dynamical structure more clearly than with examination of 2D position-velocity diagrams. The naturally weighted cube is cropped to 130 pixels in Right Ascension by 130 pixels in Declination by 45 pixels in frequency space. A script for this example will be provided in the summary section. For research purposes, it is meant for visual inspection of a data cube and for seeing dynamic features of a galaxy that can be difficult to visualize in 2D. However, the general application of viewing a 3D data cube also has uses for public outreach – explaining what astronomical data cubes look like, or, in the case of a simulation data cube, moving the camera around during an animation. The same functionality in Blender applies in both cases. A number of key operational details are relevant for any session. Keyboard shortcuts rapidly increase productivity in Blender; we refer the reader to the Blender documentation for comprehensive listings. All commands listed work the same regardless of the operating system. We will refer to elements of the GUI as dialogs, enlarged and indicated for clarity in Figures \[objecttransform\]–\[camera\]. The guidelines and figures outlined here serve as a starting point for the reader; as with any visualization package practice and experience will be required for optimal output. We denote menu items in italics as *Menu, Submenu, Item* and button commands, dialogs, and widgets in **Bold**.

-   New mesh data objects are inserted into the viewspace (called a **Scene**) at the location of the 3D cursor. The cursor’s location is shown by the red and white dashed circle and black cross-hairs (see Figure \[controls\]). This can be moved with primary (for most users usually left) mouse button or reset to the origin in the right hand side **transformation toolbar**.

-   A useful workspace can be utilized by accessing the menu *View, Toggle Quad View*. This shows the top, front, and right side views as well as a preview of what the camera will see in the final animation.

-   For draft animations, we recommend using the HD 1280x720 pixel preset in the right hand side **Dimensions** dialog, with a NTSC standard frame rate of 29.97 frames per second[^9]. Once the reader is satisfied with the low resolution results higher resolutions can be rendered if desired.

-   Objects are selected with the right mouse button. Objects can be edited by pressing the TAB key or choosing the **Mode** from the lower left hand drop down menu.

-   Blender supports both orthographic and perspective projection. This can be selected with under the *View, View Persp/Ortho* option and also changed in the camera tab (Figure \[orthoperspec\]).

-   The scale setting in the **transformation toolbar** allows units to be scaled to the data being visualized in the scene, whether they are pixels, channels, astronomical units, or kiloparsecs.

Data Model and Volume Textures
------------------------------

Preparation of data cubes can be accomplished with PYFITS or CFITSIO[^10], and saving each image with Matplotlib. Any Hanning smoothing should be completed prior to graphics export. Files should be named sequentially, e.g., channel0001.jpg, channel0002.jpg, channel0003.jpg, etc., and placed in their own subdirectory. The dynamic range of the image will be clipped by this procedure. However, this does not affect the output since the Python script controlling the Blender file can modify the scaling before rendering.

Data cubes in 3D space can be represented by the simplest of mesh primitives – a cube. Cubes can be inserted by accessing the menu items *Add, Shape, Cube*. Different data objects can be selected with the **Data Outliner** (Figure \[dataoutliner\]). We can then modify the mesh material options by clicking the red globe icon for the **Materials** widget (Figure \[materialstextures\]). We choose a volumetric material, set the graphic density to 0.0, density scale to 2.0, scattering to 1.4, and reflection to 0.0.

We then choose the **Texture** widget where the data can be added as a set of image planes. A new texture can be set to import **Voxel Data** under the **Type** dropdown dialog. Working from the top of this dialog, the color map **Ramp** dialog should be checked under color choices to set the color scale. The color scheme choice is important in visualization [@Rhyne:2012:ACT:2343483.2343484], and Blender itself can be used to understand color spaces in 3D[^11]. It is best to choose contrasting colors to distinguish the signal from the noise [@2007AJ....133..598R]. The main **Voxel Data** drop-down menu should be changed to **Image Sequence** and the first image should be selected. Blender will automatically load the rest of the files in the directory sequentially. Below the **File** dialog, the start and stop frames (channels in this case) can be chosen.

The mapping of the cube needs to be set to **Generated**, with a projection of **Cube**. Under the **Influence** dialog, **Density**, **Emission**, and **Emission Color** should all be selected. The **Blend** method should be set to **Mix**.

Camera Setup
------------

The camera can be selected by right clicking the pyramid shaped object in the viewport, followed by choosing the **Camera** tab (Figure \[camera\]). At this stage the user can choose the lens configuration with perspective or orthographic and focal length. Different types of visualization will require different viewing perspectives or, perhaps, multiple ones for split screen shots [@Carlbom:1978:PGP:356744.356750]. The camera depth of field and sensor size can also be set with composition guides for alignment.

To the left of the **Camera** tab is small chain icon for adding constraints to the camera view during the animation. For example the **Track To** feature allows the center of the camera’s field of view to always point to a particular object mesh during the animation. The **Follow Path** option is also particularly useful, as the camera can be locked to follow a predetermined path.

It is also useful in any animation sequence to have multiple camera angles - the camera can be duplicated with the **Duplicate Objects** button on the far left hand side of the interface. This will copy the camera, its constraint parameters, and allow the user to freely move the new camera object to a different location. A schematic setup of these features and camera view is shown in Figure \[cameraduplicate\].

Animation and Keyframes
-----------------------

The animation tool and timeline is located at the bottom of the Blender interface (Figure \[maininterface\]). It contains a scrolling timeline, with a green vertical line indicating the current frame, controls for playing the animation, and fast forwarding and rewinding (similar to any media player). The animation timeline defaults to frame one. Once the mesh cube object (our data container) has been loaded with the volumetric texture, it can be positioned and animated. We can approach this by one of two methods – one animates the data cube itself, and the other keeps the data cube static while moving the camera on a fixed track. We create a 20 s animation at approximately 30 frames per s$^{-1}$, for a total of 600 frames. Therefore, the **End Frame** should be set to 600. Our data cube is aligned with right ascension along the *x*-axis (*red*), declination along the *y*-axis (*green*), and frequency along the *z*-axis (*blue*).

***Rotating the data cube.*** We can keyframe the initial state by pressing the **Insert Keyframe** button on the **Object Tools** panel (Figure \[objecttransform\]) and choosing the option **Rotation**, which locks the rotation of the mesh cube for that particular frame. The cube can be rotated about the *z*-axis (*blue*) by moving the green marker on the animation timeline to frame 300 (halfway through the planned animation) and changing the *z*-rotation (right hand **transformation toolbar**) to 180 degrees and again choosing **Insert Keyframe, Rotation**. This is repeated a third and final time for frame 600, with the *z*-rotation to 360 degrees. The play button can then be engaged on the bottom animation toolbar and a preview of the animation motion will be shown.

***Revolving the camera.*** In this example we keep the cube mesh object stationary and move the camera along a path. This can be accomplished by choosing the *Add, Curve, Circle* at the top of the main interface (see Figure \[maininterface\]) and scaling it (**s** key) to the size of the path needed to view the data cube. The path animation can be keyframed under the **Object Data** tab just like any other object in Blender, rotating the path 360 degrees (or more) during the course of our 600 frame, 20 s output. The camera can then be constrained with a **Follow Path** constraint with its local *y*-axis normal to the circle, and further constrained with a **Track To** control with the *z*-axis of the camera normal to the focal plane pointing to the data cube (Figure \[camera\]).

Rendering and Output
--------------------

Once the data cube, tracking paths, and camera have been keyframed, the output can be rendered. Under the render tab there are two options: **Render** and **Animation**. **Render** will allow the user to view the output of the current frame as viewed in the animation timeline. **Animation** will render out all the frames of the current scene. Most of the default parameters will work well for typical visualization scenarios. We recommend checking the **Stamp** box which will place metadata about the animation on each image, including parameters used in the animation settings. Output can be specified as still images for each frame or one of several video outputs. The setup and a rendered frame from the final output is depicted in Figure \[datacube\].

Example Visualizations {#examples}
======================

In addition to the data cube example highlighted in section \[workflowsession\], we outline a number of other astronomical visualizations that are likely of use to the community. Blender has found successful use in materials science, medicine, biology, fluid dynamics, and network theory [@Norman2012; @2013JPhCS.410a2169C; @Andrei2012; @2011PhFl...23i1109R; @2005PhRvE..72b6107V]. In the case of studying large scale structure, Blender provided an interface for examining redshift distortions and correlations between quasar absorption line systems and luminous red galaxies [@1367-2630-10-12-125015]. Results from these kinds of studies are extremely challenging to discern with two-dimensional plots. As larger catalogs with expanded parameter sets begin to become the norm rather than the exception, having a 3D graphics and rendering environment like Blender for astronomers will prove to be an invaluable tool. We provide the following examples to illustrate starting points for those interested in pursuing their own visualization scenarios for both exploratory research as well as outreach endeavors. The visualizations are designed to put into practice aspects of the interface described in section \[blender\]. Example data, files, and tutorials will be provided for download in section \[summary\].

Astronomical Catalog
--------------------

We can use a small sample of galaxy distances to illustrate the mapping and animating of a catalog fly-through. Figure \[catalog\] shows a Blender scene setup and a single frame render of data from the Extragalactic Distance Database [EDD[^12]; @2009AJ....138..323T] of galaxies in the nearby Universe ($cz_{\odot}<$ 3000 km s$^{-1}$).

This example can utilized in scientific data exploration because we can examine the overall structure of the catalog in real time with the 3D view space. Since each galaxy has a unique object identifier in the data structure, we can use the Blender search function (**Spacebar**) and period key (**.**) to immediately center and zoom to any galaxy. This is useful for research, but also for planning camera movements for rendering if so desired.

Importing and rendering an astronomical catalog makes use of the simplest type of mesh - a vertex point, Python scripting, texturing, animation, camera movement, and rendering. ASCII catalogs can be read into Python lists. A template object can be created with a single vertex textured with a halo in the **Materials** tab, size set to 0.020. Under the **Textures** tab, the **Type** should be set to “*Blend*.” The camera can then be keyframed for animation.

*N*-body Simulation
-------------------

This example of a galaxy simulation was generated with GADGET-2 [@2005MNRAS.364.1105S]. Each large spiral disk galaxy has 10000 disk particles and 20000 halo particles with Milky Way scale lengths and masses. The simulation is run for approximately 1100 timesteps for a total simulation runtime of 2 billion yr. We read in the particle *x*, *y*, *z* coordinates as single vertex with a small Gaussian halo as its materials texture. The snapshot file for each time step is keyframed as one frame in the animation. In addition, a B[é]{}zier curve can be added to the scene as an object path [@Farouki:2012:BPB:2221977.2222160]. The camera can then be flown along the curve as the galaxy interaction progresses (Figure \[nbody\]).

Blender has excellent utility for research purposes in rendering simulations. Many simple astronomical simulations are of the format *x-y-z* over time and are easily accommodated. The camera control in particular is useful for moving through 3D space as simulation timesteps play through an animated rendering. The procedure is very similar to opening a catalog in the previous example; for a simulation we can open different snapshots and keyframe to create a smooth animation. Snapshot files can be read into a Python list or dictionary. A template object can be created with a single vertex textured with a halo in the **Materials** tab, size set to 0.020. Under the **Textures** tab, the **Type** should be set to “*Blend*.” The positions of each particle can then be loaded with the Python API. The camera can be keyframed for animation and a final rendering can be generated.

Asteroid Models
---------------

We show a number of 3D asteroid models based on data available from the Database for Asteroid Models from Inversion Techniques . The database provides Wavefront object files of each asteroid model, which can easily be loaded into the 3D viewport. For this example, we want uniform lighting to be able to see the entire surface model as they are rotated. This can be accomplished by turning on Environment Lighting in the **World** tab (small globe icon, see Figure \[camera\]). Figure \[asteroids\] exhibits an example of an orthographic projection and shows a sample of six asteroids, enlarged to show the smoothing texture on the surfaces.

This example exhibits how 3D mesh models in OBJ files can be imported into Blender for animation and rendering. OBJ files from data such as our asteroid example can be used for research purposes, but also have merit in video renderings for public outreach. This can be accomplished in the upper left corner of the GUI and choosing *File, Import, Wavefront (\*.obj)*. The object can be scaled in the **Transform** dialog on the right side of the GUI, or by pressing the ’S’ key. The asteroid mesh object can be selected with the right mouse button, keyframed for animation with the “I” key, and rotated with the “R” key.

Summary
=======

The availability of hardware and software that allows the creation of high-quality 3D animations for astronomy brings a vivid new way for astronomers to visualize and present scientific results. Animations are an important part of the astronomical toolset that can show expanded phase spaces, the time domain, or multidimensional tables and catalogs beyond the limitations posed by two-dimensional plots and images.

An introduction has been presented showing the software program Blender as a 3D animation and rendering package for astronomical visualization. We have reviewed the importance of visualization in the scientific disciplines, with examples from astronomy. Features of the program include GPU processing, a variety of rendering engines, and an API for scripting. An overview of the principles in the animation workflow include modeling, volumetric and surface texturing, lighting, animation, camera work, rendering, and compositing. With these general steps in mind various astronomical datasets – images, data cubes, and catalogs can be imported and visualized.

An example workflow session with an astronomical data cube that shows the structure and dynamics of a small dwarf galaxy has been presented, giving settings and recommendations volumetric texturing of a cube model, animation, and animation output. A number of other example are shown from different areas of astronomy to give a broad scope of possibilities that might exist with astronomical data.

A demonstration video as well as Blender files, Python scripts, and basic tutorials of the principles and examples outline in this paper are available at:\
http://www.cv.nrao.edu/$\sim$bkent/computing/kentPASP.html

bib.tex

[lccc]{} Blend & native & .blend & Import/Export\
OBJ & ASCII & .obj & Import/Export\
CSV & ASCII & .csv & Import\
JPEG & image & .jpg, .jpeg & Import / Export\
TIF & image & .tif, .tiff & Import / Export\
PNG & image & .png & Import / Export\
GIF & image & .gif & Import / Export\
EXR & image & .exr & Import\
FITS & image/structured data & .fit, .fits & Import\
AVI & video & .avi & Export\
MPEG & video & .mpg, .mpeg & Export\
MOV & video & .mov & Export\
H.264 & video & .mov & Export\

[lcccc]{} NVidia CUDA & 100 & 2.82 & 1.49 & 0.31\
OpenCL & 31 & 2.17 & 1.99 & 0.22\
CPU & 154 & 8.30 & 6.48 & 0.47\

[lccccc]{} Blender & L,M,W & GPL & MM, A, T, iR, eR, L, S, VE, N & Yes & 1\
3D Studio Max & W & Proprietary & MM, A, T, iR, eR(some), L & No & 2\
Cinema 4D & L,M,W & Proprietary & MM, A, T, L, eR & No & 3\
EIAS3D & M,W & Proprietary & MM, A, T, L, iR & No & 4\
Houdini & L,M,W & Proprietary & MM, A, T, L, eR & No & 5\
Lightwave 3D & M,W & Proprietary & MM, A, T, L, iR & No & 6\
Maya & L,M,W & Proprietary & MM, A, T, L, iR, & No & 7\
Modo & M,W & Proprietary & MM, A, T, L & No & 8\
SAP V.E.S. & W & Propreitary & MM, A, iR & No & 9\
SoftImage & L,W & Propreitary & MM, A, S, N & No & 10\

[^1]: Available from http://www.blender.org/

[^2]: Images available at http://earthobservatory.nasa.gov

[^3]: http://stsdas.stsci.edu/astrolib/pywcs/

[^4]: 

[^5]: Manual available at http://wiki.blender.org/index.php/Doc:2.6/Manual

[^6]: Maps available at http://www.mars.asu.edu/data/mdim\_color/

[^7]: API documentation available at http://www.blender.org/education-help/

[^8]: Available at http://www.ffmpeg.org

[^9]: ITU Recommendation BT.709: http://www.itu.int/rec/R-REC-BT.709/en

[^10]: http://heasarc.gsfc.nasa.gov/fitsio/

[^11]: http://www.photo-mark.com/notes/2013/mar/13/color-theory-blender/

[^12]: Data available at http://edd.ifa.hawaii.edu/
