SplutterFish
Brazil r/s
Support
News and Announcements
Gallery
Community
Downloads
Company
Tech
* indicates off site pages
Artist Spotlight

Uncharted Territory
other spotlights...

Brazil r/s

Design Overview

last modified: March 8, 2001

Introduction

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.
 

Motivation

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 be changeable.

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 interface.
 

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 shader types.

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.