last modified: March 8, 2001
This is an overview of the design documentation for Brazil r/s. The
full design doc is confidential, but this should give a better view of
the direction the product is headed. It will take a great deal of
time and work to do this right. Brazil will be done when it's done,
but we also like to live by the motto, release early, release often.
At every level of the system, process and storage are abstracted as
much as possible to allow easy extension and modification of the system.
Brazil is, at its core, just a rendering framework. It provides a
consistent environment for a broad range of plugin components that actually
perform the task of image generation for the system. Brazil
is composed of several different modules, each with its own purpose, and
usually, each has its own set of plugin types. Nothing is assumed
by the system. If desired, the system could even be modified to support
a REYES style rendering pipeline, similar to PRMan.
There are many different rendering options available today, but only a
few that are considered powerful and flexible enough to be used in heavy
production environments. Pixar's PRMan and mental images' mental
ray come to mind immediately. Unfortunately, even for these high
end packages, there are definite strengths and weaknesses in each.
While both systems are very open and extensible, this openness is limited
to the general rendering pipeline each system has integrated into itself.
For example, PRMan is based on the REYES (Render Everything You Ever Saw)
pipeline. This method of rendering is very powerful and flexible,
but integrating more modern CG techniques like global illumination into
the pipeline is somewhat problematic. Even basic ray tracing isn't
a part of PRMan, and a certain number of hoops have to be jumped through
to get PRMan to ray trace.
The fundamental limit to these systems is their tie to a specific pipeline,
with assumptions made about how materials, light, etc. should be represented,
and how the information generated should be stored. While a certain
framework is mandatory for any rendering system, the ability to replace
any component of a system, or extend any portion of the system would be
highly desireable. For instance, if a new, super efficient global
illumination system is developed, it would be nice to be able to replace
any existing system, piece by piece, without having to worry about any
of the other rendering processes. Ray tracing acceleration, or even
just ray-triangle intersection testing, or ray-sphere testing should be
replacable. Ideally, even basic color space representation should
In order to accomplish such goals, Brazil r/s is designed around replaceable
plugin based client / server systems that provide various rendering capabilities
to any host software. Brazil itself will be capable of tight integration
with any platform, as the various modules and plugin components can be
customized as necessary to accomodate specific capabilities or features
in the host application. Brazil will also feature a 'stand-alone'
version that is command-line driven with scenes described by a custom scripting
/ shading language called Orchid. Brazil will also be capable of
reading scenes in other formats, such as RenderMan rib files.
Of course, no production renderer is worth anything if it is too slow.
System design is focused on enabling easy extension to support the latest
in performance improving advances in technology. The list of technology
to integrate includes things like hardware visibility acceleration, hardware
bitmap and texture handling, dedicated particle and hair rendering, pluggable
ray tracing and ray marching acceleration.
Brazil r/s is broken up into several distinct 'modules'. Some
of these modules are client / server systems, and all are replaceable.
Along with being able to replace the individual modules of the system,
each module is built from several plugin types, allowing pieces of a module
to be replaced, or new options added. These modules are essentially
stand-alone. For example, the ray and luma servers can be used independant
of Tiki. Among the planned major modules of Brazil are the following:
Tiki - component bucket renderer
The component based bucket rendering backbone of the system, and the core
module responsible for orchestrating the processing of the scene and sampling
of the image. Tiki itself really just manages the renderer component
queue, which allows a bucket to be sampled by individual components of
the renderer in various passes within the bucket. Tiki will also
be controllable via Banshee, the network rendering system, or via command
line. The component rendering architecture allows both scene preprocessing
and sampling to be modified and extended easily via the Brazil SDK, and
eventually the Orchid scripting language.
Essentially, each part of the rendering process is performed by a plugin
component. Planned component types currently consist of geometry
translators, geometry modifiers, Flux components (preprocessors, samplers,
and utilities), volumetric samplers (atmospherics), image sampler components
(these render the actual image), visibility acceleration components (scanline
/ hardware acceleration), frequency analysis components (antialiasing and
sampling control), pre and post filtering 'lens effect' components, and
utility components (catchall). All of these will be extendable via
external plugins using the Brazil SDK.
Each component type has a specific general 'place' in the rendering
pipeline, and are sorted by type in the component list in the renderer
Echo - ray server
Ray tracing is generally a necessary evil when attemping to render truly
photorealistic images. For this reason, an advanced renderer should
be capable of fast integrated ray tracing. PRMan doesn't support ray tracing,
but is able to mimic much of what ray tracing provides, so it hasn't suffered
from this limitation too much. Plus, it is possible to extend PRMan
with a separate application called the ray server. A ray server is
an independant application or process that provides ray tracing services
for a renderer or renderer component. Echo, the ray server for Brazil
provides a broad range of ray tracing services, with the entire ray casting
pipeline exposed at every level via the Brazil SDK, and eventually, the
Orchid scripting language.
Ray tracing acceleration is a plugin type, and there will be lazy handling
of geometry processing, allowing support for cached micropoly displacement
mapping, and other advanced tesselation effects, with limited memory usage.
Supported geometry can be extended through special Entity plugins.
Echo already provides potent support for triangle and polygon mesh processing,
and will support direct rendering of implicit surfaces and CSG primitives
and operations in the near future. The ray casting and tracing pipelines
themselves will be continually updated and optimized as Brazil grows.
Flux - luma server
Flux is the internal name for the illumination preprocessing and sampling
server for the Brazil rendering environment. The physics term flux
refers to the flow of energy through a system, or environment, and this
is Flux's purpose. Flux will manage all the lightsources in the scene:
standard point lights, geometry based light sources, optimized area lightsourcing
for primitives (boxes, spheres, etc.), plus any scripted and plugin light
types. Flux is responsible for determining the amount of light energy
arriving at any point on a surface, and is tightly coupled to the shading
pipeline, which will itself be extendable via Orchid or various plugin
Generally Flux will work with Tiki to orchestrate the entire light gathering
process, both direct and indirect illumination, and allow for prepasses
to generate photon maps, perform traditional subdivision based radiosity,
etc. Flux will also manage the overall optimization of the illumination
process 'on the fly' by determining via preprocessing the gross illumination
level of the scene. This allows the system to selectively 'remove'
lights from evaluation at certain sample point if they contribute negligable
energy to the sample color. Flux, will also add accelerated shadow
processing capabilities, particularly for area light and area shadow generators.
Most important, global illumination preprocessing and sampling will
also coordinated by Flux. Global illumination support will be via
a hybrid of adaptive quasi-monte carlo sampling and photon mapping, and
provide full support for diffuse and specular indirect illumination, environment
(sky) light, accelerated area shadow rendering, and many other features.
Of course, these capabilities aren't inherent in Flux itself, they are
provided by plugins to Flux. For example, the photon mapper will
allow photon maps to be generated, storing any information desired (photon
structure can be changed easily, for gathering different types of information).
Photon maps can then be used by the various hemispherical patch samplers
and other components to accelerate their rendering efforts.
Orchid - scripting / shading language
All of Brazil will be driven by the scripting language Orchid. Orchid
will provide full RenderMan compliant shader support, plus extended Brazil
specific shading features. Orchid will also drive Tiki, Echo, Banshee
or any of the system components, so an entire new rendering system could
theoretically be scripted.
Banshee - distributed rendering
Using a dynamic load balancing system, Banshee will manage rendering in
a networked environment, via communication with Tiki, and the Banshee demons,
distributing interactive single frame and bulk multi-frame rendering to
the optimal number of machines. A log of performance characteristics
will be automatically maintained for the systems on the network, and the
number of machines assigned to each job will also be dynamically updated,
based on current network traffic, transmission overhead, etc.
When using the host application (such as 3dsMax) to render interactively,
Tiki will work with Banshee to provide fast refresh capability of a single
frame via distributed network rendering and bucket caching. For external
control of Banshee, the plan is to support full C++, Orchid, and PERL api's,
and possibly Python. This will allow network administrators to control
and extract information from the Banshee system using familiar languages.