Features

Bella is a spectral render engine which models the complexities of optical physics in ways that are as correct as possible, using analogies grounded in the real world, to produce a system that behaves in a predictable and intuitive way.

Simplicity is a key focus of Bella. The Bella solvers avoid obscure non-physical parameters, such that there is very little to learn, and very little trial and error involved in rendering any particular scene.

---

---

Customer-first Licensing

We believe that customers should not be made to pay the price for securing our product from unauthorized use.

We are against draconian licensing systems, which can be so difficult to configure and administer, and which so often fail at the worst possible moment -- and usually in favor of the vendor, rather than the customer, who is considered guilty until proven innocent. We've been bitten by these types of systems enough times, ourselves.

We also dislike subscriptions, which in addition to having those deficiencies already mentioned above, constantly occupy mental real estate, and require constant or periodic connection to validation servers, and so forth.

The fact is: most software vendors are not expert at designing licensing systems -- we certainly don't pretend to be. And when that is the case, they may either naively implement something from scratch, or they may pay to license a system from one of the big names in that sector.

In the former case, we say: good luck. But even in the latter, there is still much room for error, as the integration of a 3rd-party system can be quite error-prone, and as the system, itself being quite complex, will still be subject to various modes of failure, whether due to bugs, or just to the vagaries of dealing with networks on customer sites, and the like.

For these reasons, the Bella license is implemented as a simple text file. The text for the file is available to you at any time, without needing to contact support -- you can access it whenever you like simply by logging into your account and looking up your order. Copy the license text, paste it into a dialog in the Bella GUI and you are up and running.

A consequence of this is that every Bella license is floating, permanent, and requires no secondary registration or validation -- exactly the kind of license that we, ourselves, prefer.

---

SPECTRAL RENDERING

In order to more accurately simulate the equations governing the optical properties of materials, it is essential to render using many spectral energy bands instead of the usual three primary colors.

In Bella we perform all light transport computations in spectral space, from beginning to end, which allows to compute with greater precision a multitude of optical phenomena such as light dispersion, Fresnel reflectance, iridescence, BSDFs with wavelength dependence, atmospheric simulation, aperture diffraction, and so forth.

It is only at the very end of the process that we transform the computed spectral energies (irradiance) to the chosen color space.

---

SOLVERS

The Bella render architecture is based on having one or more Solvers render the scene. Our current beauty-pass solvers include:

Saturn

Saturn is a brand new solver design, proprietary and heavily vectorized for excellent rendering speed. It employs a novel method for automatically focusing processing power on portions of the image that need it, and is thus able stop rendering at a preset target noise level.

Atlas

An advanced unbiased path tracer, Atlas is recommended for use in scenes that involve complex lighting, especially including difficult refractive (e.g. swimming pool) caustics that have often been infeasible in some other physically-based renderers.

IPR

IPR (Interactive Preview Render) is implemented using Saturn, which is able to begin rendering in a mode suitable for the quick response needed for a comfortable viewport rendering experience, before then shifting to its standard production mode, thereby ensuring that what you see in your viewport is what you get in your production renders.

---

COMPLEX CAUSTICS

It has long been a well-known and difficult problem to render correctly, without tricks or artifacts, the caustic illumination that we perceive through reflection or specular refraction. And yet, this is a situation that arises frequently in life, and therefore in professional rendering work.

One of the most infamous cases is that of sunlight falling on a swimming pool and producing its characteristic caustic patterns on the bottom of the pool, which must then make their way back through the water surface to reach the camera.

Light sources are often contained within a glass envelope such that when modeled accurately, they will contribute only caustic illumination. This can make it quite difficult to render objects such as flashlights, auto headlight assemblies, and the like.

Bella is capable of rendering such difficult scenarios using its advanced Atlas solver, without any special knowledge or settings. It is possible to artificially limit bounces and computation of caustics, but this is fully optional, and up to the artist.

---

LAYERED materials

At its core, Bella makes use of two fundamental material types: conductors and dielectrics. Conductors are opaque surfaces and dielectrics are transparent surfaces. Both are referred to as substrates, and are allowed to have a layer stacked above them. A layer is a dielectric surface, with a medium where optional scattering may be defined. The layer interacts with the substrate below it, through multiple bounces, combining to produce a very realistic material.

For example, in the image at right, both statues use a conductor (gold), but the one on the right is augmented with a layer that makes use of scattering.

Like conductors, dielectrics may also make use of a layer, generating a result by way of the interaction of light between the dielectric substrate and the layer. This is not just a blending operation, is a true multi-bounce interaction depending on angle, transmittance, Fresnel, roughness, anisotropy, and so forth.

---

---

THIN FILM

Yet another type that may be used in the layered system is the Thin Film, which allows adding iridescence to a surface. Changing the film's thickness (by scalar value or by texture map) or index of refraction will produce corresponding interference patterns.

The thin film can be applied to the surface of any substrate, layer, or sheet.

---

---

NESTED DIELECTRICS

Nested Dielectrics allow, by providing a priority number, to correctly render intersecting volumes, such as a glass filled with liquid, with ice, bubbles, and so forth.

---

---

COMPLEX IOR

The refractive index of a material can be described by two components.

The first describes the ordinary refractive index, which determines the bending of a ray of light as it passes from one medium to another.

The second describes the attenuation of light as it propagates through the interior of the material. It is common to group both components in a single complex number, hence the name complex index of refraction.

Over time, various measured complex IOR datasets have become available, and the Bella Complex IOR node allows these to be used for rendering.

By default it works quite simply, as the Complex IOR node embeds data for several of the more common material types. However, if you wish to use a type that is not embedded, you can also specify by file path, or by directly pasting IOR data into an attribute of the Complex IOR node.

---

PBR & SMART MATERIALS

Since it is likely that a majority of the materials you will need for day-to-day use do not require the level of control offered by Bella's layered material system, we also support the use of commonly-available PBR texture sets, such as these examples from the excellent ambientCG.com, through our PBR and Uber materials.

The PBR material is a simple material that allows using a PBR texture set with a single click, to choose either one of the set's textures, or a .zip file containing the set. A single texform node can be used to control mapping of all the textures at once.

The Uber material extends this PBR interoperability, to expose direct control over where & how the PBR textures are assigned, and provides a full material interface in a similar style to the uber materials commonly found in various other rendering systems.

---

TEXTURES

All textures in Bella are implemented as nodes (whether file-based or procedural), the outputs of which may be used to drive the inputs of other textures, or of intermediate nodes, materials, and so forth.

By way of example, here is shown a Bella material being edited in Maya Hypershade:

---

---

INSTANCing

Bella provides extensive support for instancing. Indeed, everything that can be seen in a Bella image is either an instance of some type of geometry, or an instance of some other instance.

This is accomplished through a logical and consistent model, based on the use of the Bella xform node.

In the hierarchy at left, we see a procedural plane instanced twice under the planes xform, which itself is then instanced by the instance of planes xform. Using the boxes at the right, materials may be assigned, and instances made either visible or hidden (or, as by default, they can inherit the visibility of their parent).

At right, we see that each instance can not only be assigned its own material, but can even decide which of its geometry's UV sets to use. In the image we are seeing five instances of the same mesh plane, each using different materials and UV sets.

---

Physical Sky & SUn

Bella's Sky Dome and sun is based on the excellent Hošek & Wilkie model, slightly modified to allow render times after sunset. By default, the skyDome node works very simply, rendering a physical sky simulation with sun, based on date, time, and location values built into the node. UTC offset is computed automatically, so all that is required is to choose your desired location and time.

Here is an example showing different times of day for Barcelona, 23th Sept. (DST in effect) :

In addition to setting the sun's direction by date/time & location, it is also possible to link a Sun node to the environment, which when parented to an xform in the scene, will be used to determine the sun's direction.

---

PROCEDURAL LIGHTS

In addition to supporting mesh lights through the emitter material, Bella also provides procedural Point, Area, Directional, and Spot lights.

For the most part these exist for the purpose of accurately representing host-application lights in Bella scenes, and as such, they do not by default use real-world units.

Instead, these lights use a generic and unitless Intensity value, which is multiplied by a Multiplier value; the reason for this design is to allow Bella plugins to drive light intensity according to host-application light intensity, with the multiplier being used to scale Bella output to match that of the host (or other plugin) light.

As such, once the multiplier has been suitably set, output energy in both host application and Bella may then be controlled using the host application intensity value.

Additionally, some of the Bella light types also accept direct assignment of a Bella emitter material (specifically, those which have a physical area), in case you prefer to work in real energy units.

NOTE: only the area type is currently supported in Saturn.

---

cameras

Cameras in Bella are represented using the Camera, Lens, and Sensor nodes, which are modeled to represent features commonly found in DSLR cameras, in order to allow you to leverage your existing knowledge of photography, in Bella.

The camera supports either fully manual exposure control, or automated exposure compensation, with either aperture or shutter priority. Aperture-priority mode is the default, as it can be very convenient for adjusting DOF (Depth of Field) while maintaining the current exposure.

---

THIN / THICK LENS

In addition to the typical thin lens, Bella also provides a thick lens, which is a model of a physical bi-convex lens. This provides increased realism, since real-world lenses are of varying quality, and are never perfect like the thin lens, so they (and Bella's thick lens) produce effects like chromatic noise, aberration and lens distortion.

---

Sensor BLOOM

When a pixel in the sensor becomes saturated beyond its capacity, its excess energy bleeds over into adjacent pixels. Note that this feature is currently supported only in the Atlas solver.

---

---

DIFFRACTION

When light passes through the camera aperture, due to its wave nature, it diffracts and does not produce a dot in the sensor pixel but rather spreads over an area. So, due to diffraction there is a limit to the sharpest image a camera can take, because all cameras are diffraction-limited.

One would expect that the higher the fstop number, the sharper the image will be, but the truth is that above a given f-number, the image will rather lose sharpness, because as the aperture gets smaller, the light waves spread out more and the image becomes blurred.

Diffraction in Bella is computed on a physically-correct basis -- it is not just an arbitrary artistic effect, but is rather based on a real wave optics simulation, taking into consideration aspects such as the aperture shape, the grating aperture filter, the sensor size and the focal length, such that in the end, Bella computes how waves of light spread across the sensor pixels, as occurs in real cameras.

For the next scenario we based on a real example on a photography website, What is diffraction in photography? Specifically in header 5, Diffraction and Depth of Field, where a similar example and deeper explanation can be found:

When diffraction is enabled, zooming in on the focused area around the head shows f5.6 to be practically identical to not enabling diffraction at all. However, at f22 we see that diffraction significantly reduces sharpness, which matches what we expect, given how a real camera operates.

Similar to sensor bloom, diffraction can also be useful for enhancing the perception of high energy pixels, or just for creating various artistic effects:

Note that this feature is currently supported only in the Atlas solver.

---

COOPERATIVE & Resume Render

Due to the nature of the algorithms used in the Atlas solver (support is planned for Saturn, but it is not yet implemented), it is inherently possible to render a given scene on multiple machines, and later combine the results. Likewise, it is also possible to resume a render after previously having stopped it (provided the 3D scene has not been altered).

These capabilities are obviously useful in general, for individual work, and for building something like a render farm, but there are other less obvious workflows that they enable, as well.

Progressive Rendering

Portions of a pipeline (e.g. compositors) may be able to get work done just fine with low-quality images, such that it can make sense to render a series of frames to a low level and distribute the images to those who can make use of them, before then continuing to render the series to a higher level.

Likewise, it may be that you are not 100% sure the frames are actually going to come out well, so you can use the progressive approach to render the entire series, as a whole, to successively-higher levels, stopping immediately, if you do indeed find that there are show-stopping issues which must be addressed.

Resume Rendering

Beyond providing the peace of mind that your work will not be lost should your machine crash or reboot, resume rendering also enables a more flexible workflow for the individual artist.

For example, when you are working on your main machine, it is clearly most convenient to be executing test renders locally. However, as you may prefer not to dedicate substantial CPU time on your workstation to rendering, resume-render can be used to transfer work to a secondary machine, without sacrificing the work already done on an image.

Likewise, you may prefer to work during the day, queuing renders that you will then let run overnight; in this case as well, you do not forfeit the CPU time you've dedicated thus far, since it is just a matter of re-opening your .bsx file and resuming the render, before you leave the office for the evening.

---

denoiser

Bella implements Intel's OpenImageDenoise library for both IPR and production rendering.

In IPR we use a quick denoising pass that requires little CPU or memory, but which tends to produce mediocre results. In the beauty pass we generate full albedo & normal data, for results we have found to be beyond our expectations.

---

Render passes

A special type of Solver, a Pass (sometimes referred to as a layer, channel, or AOV in other rendering software) is used to render a specific non-beauty output, such as an object or material ID pass, and so forth. Bella's currently-supported passes are these:

• Alpha Pass
• Material Pass
• Object Pass
• Shadow Pass
• Albedo Pass
• Normal Pass
• Tangent Pass
• Z Pass

We expect to add more pass types as we receive requests for them, and perhaps if it is desired, provide an API for people to write their own proprietary pass solvers.

---

geometry Import

Supporting OBJ, FBX, DAE, 3DS, and STL formats. This does not mean we intend to portray the GUI as a full-fledged 3D editing program, it remains primarily intended to support GUI-based rendering outside of a plugin.

---

PROCEDURAL GEOMETRIES

Bella provides procedural Box, Sphere, Plane, Cylinder, and Disk nodes, which render with perfect precision, and require virtually no memory.

These may optionally be substituted for mesh geometry in Maya by setting the Render Perfect option in the Bella parameters for a mesh's polySphere, polyPlane, polyCylinder, or polyDisc node.

NOTE: the cylinder and box types are not yet supported in the Saturn solver.

---

nodes and the scene hierarchy

Everything contained in a Bella scene is a node, and everything seen in a Bella render is an instance of a node, or an instance of a hierarchy of nodes, and so forth.

The scene consists of a collection of nodes, each with input and output attributes that may be connected to the inputs and outputs of other nodes. One of the primary node types is the transform (or xform in Bella), which is a node that associates a 3D transformation with a collection of child nodes, each of which may in turn be a geometry node, or another xform.

At the root of the visual scene hierarchy we find the world xform -- everything visible in the render is ultimately parented to the world xform, either directly or indirectly. And everything seen may be said to be an instance of some geometry node, or an instance of an xform, along with its child geometries and xforms, and so on.

For detailed help on all Bella node definitions, see here.

---

color management

With native support for the linear, sRGB, and Rec709 color spaces, Bella also optionally (i.e. depending on whether the OCIO environment variable is set) uses OpenColorIO for color management.

This applies to file input & output, to the Bella GUI for accurate input & display, and to the Maya plugin.

---

The Bella file formats

Bella provides both binary (.bsx) and plain-text (.bsa) file formats. Additionally, it provides native support for a zipped scene archive format (.bsz), which contains all referenced assets, to ease rendering a given scene on different machines (or sending to a render farm).

While the binary format is generally used for production, due to its reduced size and superior read/write performance, a plain-text format can be invaluable for debugging purposes, for sending fragments of Bella scenes over the network (the Bella Scene API is capable of accepting such fragments directly), or for hand-authoring scenes and/or for creating tools capable of working with Bella, without introducing a binary dependency on any Bella libraries.

As such, we have placed an emphasis on creating a plain-text format that is easy to read and write -- in fact, you may find it to look more like code, than a file format:

# Bella Scene - 2019-02-24T20:32:39-0600



# Arrays may be auto-indexed, and nodes may be referenced before creation:

xform world:

  .children[*]          = __persp__;

  .children[*]          = __sphere__;

  .children[*]          = __plane__;

  .children[*]          = __keyRight__;

  .children[*]          = __keyLeft__;

  .steps[0].xform       = mat4(-0.01 0 0 0 0 0.01 0 0 0 0 0.01 0 0 0 0 1);



# We can create a node and set its inputs by their full paths:

settings settings;

settings.beautyPass     = beautyPass;

settings.camera         = __perspShape__;

settings.iprScale       = 57f;



# Or, an existing node may be made current using the 'with' keyword:

camera __perspShape__;

with __perspShape__:

  .lens                 = lens;

  .sensor               = sensor;



# Or, we can combine both into the node creation step:

xform __persp__:

  .children[0]          = __perspShape__;



[...]

We will provide a full spec for the format (and perhaps in time, parsers for various languages), but as you can tell even without having seen a spec, it is very easy to create Bella scenes. Please note that for purposes of clarity, the above snippet is not really something you could render, mainly because it refers to many non-existent nodes.

And in fact, we have already used this internally to good effect, for instance, to create a quick & dirty SketchUp exporter (for development purposes -- nothing you would want to use for work), simply by opening an output file in Ruby, and writing out a .bsa file -- no complicated linking of Bella code libraries necessary.

---

plugins

The initial Bella plugin is Bella for Maya. As might be expected, it implements Bella nodes as Maya nodes, and provides seamless and interactive Maya-native material and scene editing and preview rendering.

To read more about the Maya plugin, please refer to the plugin documentation, here.

Our second plugin is Bella for Rhino. In its first iteration it is designed to be as easy to use as possible, adding virtually no new settings to Rhino -- native Rhino render settings, materials, environments, and so forth, are all translated automatically.

The plugin supports Rhino 6, 7, and 8 on both Windows and MacOS (Intel and Apple Silicon), and provides rendering directly in the viewport, as well as in the Rhino render buffer (or externally in the Bella GUI, which is preferable, as it ensures we have full control of our pixels, and frees up Rhino for you to keep working, instead of blocking it like the Render command inside Rhino).

To read more about Bella for Rhino, see this forum post.

Next on our plugin roadmap are plugins for SketchUp, Cinema 4D, 3ds Max, and others (not necessarily in that order), so please let us know if you have a preference, as we will naturally take demand into account, as we move forward.

---

Bella GUI

The Bella GUI is used for rendering, and light interactive editing of scenes, outside the host 3D application where they were authored.

While plugins, to whatever degree applicable, allow rendering directly inside the host application, it can also be desirable to have rendering occur outside, and independent of the host application, in order that you may continue working, while rendering is done in a separate process.

As such, Bella plugins include a Send to Bella command, for exporting the scene to a Bella file, and starting Bella GUI rendering it, while you keep working.

Though serving this purpose is the main scope of the Bella GUI, it does nevertheless provide a good deal of scene editing capability, and as it is generally not possible to provide so tight an integration in a host 3D application, can be a comfortable option for certain portions of the workflow.

As development progresses, we will be continuing to refine and augment this GUI, as seems sensible to us, and according to customer request. You may view the GUI documentation here.

---

Bella CLI

The Bella CLI is simply a command-line application that can be used to render a Bella file.

It is useful for creating a personal render farm, or integrating Bella into existing rendering pipelines. You may view the CLI documentation here.

---

Feature list

• Interactive Progressive Rendering ( IPR )
• Possibility to choose between different beauty solvers for production.
• Interactive material preview
• Spectral rendering
• Automatic solver for caustics, from easy to difficult ones ( those seen through specular materials ).
• Material model with a real layer simulation.
• Thin sub-surface
• Thin film interference
• Spectral complex iors
• Nested dielectrics
• Smart materials
• Thick and thin camera lenses
• Optional polygonal aperture diaphragm, produces bokeh effect.
• Bloom ( uniform and vertical smear )
• Aperture diffraction
• Grating filters for diffraction
• Cooperative rendering in Atlas
• Resume rendering in Atlas
• High quality denoiser
• Physical sun and atmospheric spectral model
• Memory efficient instances
• Procedural lights: area ( mesh, disk, sphere, cylinder ), point, spotlight, directional
• Different textures types: reflectance, normal mapping, bumping, roughness, anisotropy, rotation anisotropy, thickness, layer opacity, material opacity, transmittance, scattering
• Procedural geometry: disk, plane, sphere, cylinder
• Render passes: beauty, albedo, alpha, material, normal, object, shadow, tangent, z
• Region rendering
• Blow up rendering
• Shift lens
• Optional vignetting
• Node-based architecture
• Color management (via OpenColorIO).
• Bella CLI ( command line application )
• Import several 3d files to Bella scene ( fbx, obj, 3ds, dae, stl ).
• Plugins & GUI available for Windows and MacOS, with CLI support for linux.