Bella is a spectral render engine which models the complexities of optical physics in ways that are both as correct as possible, and which are yet made intuitive and accessible.
Simplicity is a key focus of Bella. The Bella solvers have no obscure non-physical parameters, such that there is very little to learn, and very little trial and error involved in rendering any particular scene.
Physical Sky & Sun
Thin & Thick Lens
Cooperative & Resume
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 to no good end, and generally 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 (or put it directly in a text file, if for instance, you wish to distribute it across a farm of machines), 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.
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.
Is only at the very end of the process that we transform the computed spectral energies (irradiance) to the chosen color space.
The Bella render architecture is based on having one or more Solvers render the scene. Our current beauty-pass solvers (which to make it clear, are all currently CPU-based) are:
An unbiased bidirectional path tracer, Atlas is the default solver for production beauty pass, as it is highly optimized for solving complex lighting scenarios.
Very similar to Atlas, Ares is a sophisticated unbiased (but non-bidirectional) path tracer, which may be used for production beauty pass, potentially rendering faster than Atlas in scenes which have less complex lighting.
Apollo is a quasi-unbiased solver using a proprietary new method. It is a production beauty pass solver capable of solving lighting scenarios which have traditionally been infeasible for a pure bidirectional path tracer like Atlas. It is our intention that eventually, Apollo will replace Atlas as the default solver, but as it is a completely new technology, we must carefully ensure that there do not exist cases in which it yields incorrect or undesirable results.
An unbiased path tracer, the IPR (Interactive Preview Render) solver has been created & tuned for giving quick initial feedback on changes in the scene. This solver is used to implement any realtime interactive rendering windows in the Bella's GUI and plugins.
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.
For such scenarios we recommend the use of Bella's Apollo solver. There is nothing special to set up or learn, in order to render these caustics -- just choose the Apollo solver and that's all.
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.
The decanter at left uses just a dielectric, the one in the middle uses just a layer (well in fact, a sheet,), and the one at right uses the combination of dielectric + layer.
The Sheet material is like a layer with virtual thickness (controlled by its transmittance), and no substrate. This is useful for simulating translucent thin surfaces, with scattering.
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 allow, by providing a priority number, to correctly render intersecting volumes, such as a glass filled with liquid, with ice, bubbles, and so forth.
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 material allows these to be used for rendering.
By default it works quite simply, as the Complex material 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 material.
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 provide several simpler material types, each of which embeds the logic for building its type, according to just two or three relevant parameters.
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:
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.
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.
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.
When a pixel in the sensor becomes saturated beyond its capacity, its excess energy bleeds over into adjacent pixels.
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:
COOPERATIVE & Resume Render
Due to the nature of the algorithms used in Bella, 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.
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.
These approaches would simply not be possible if each frame had to be rendered to completion -- about the best you could do would be to render the series at lower-resolution first, before starting all over again at production resolution, in which case the time and work-value represented in the preliminary run is lost.
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.
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 information, for results we have found to be beyond our expectations.
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.
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.
Bella provides procedural 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.
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.
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:
.children[*] = __persp__;
.children[*] = __sphere__;
.children[*] = __plane__;
.children[*] = __keyRight__;
.children[*] = __keyLeft__;
.steps.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.beautyPass = beautyPass;
settings.camera = __perspShape__;
settings.iprScale = 57f;
# Or, an existing node may be made current using the 'with' keyword:
.lens = lens;
.sensor = sensor;
# Or, we can combine both into the node creation step:
.children = __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.
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.
Next on our plugin roadmap are plugins for Rhinoceros, followed by 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.
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.
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.
- 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
- Resume rendering
- 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.