Welcome to the first alpha release of what will be the full production
version of the Brazil Rendering System. While Brazil has been under
focused development for nearly a year now, we are still a bit away from
considering the product beta, or version 1.0 feature complete. This
is an all new beast. While it does share a limited amount of code
with the early prototype version, most portions have been significantly
modified or rewritten entirely. An important thing to bear in mind
is that we know this software is not bug free. We have attempted
to eliminate most bugs that could seriously hinder any attempt to render
finished works with the product, but we know there are bugs.
While many people are probably expecting this release to be just an update to the old 0.1.x versions, it should be considered a new start. 0.1.x was just a prototype. That early version allowed us to experiment with different software design ideas, and their impacts on speed, flexibility, and other issues. Along the way, as the original system evolved, we began to realize what would be possible if we implemented all the base systems, as well as the whole concept of host integration vs independant control in a particular way. While Brazil does maintain great autonomy from the Max SDK, compatibility has not been sacrificed in the process. If a third party plugin is not working properly in this release (shag:hair has worked intermittently, but currently doesn't, for example), it will be dealt with once we lock down features.
This first pre-beta release is intended to test certain parts of the
new core system. It is not bug free, however, the bug list became
short enough, and stability and features strong enough that we feel comfortable
opening up this new version to wider public testing. There is a great
deal more to come very soon. True area lightsource objects (not just
shadows, but illumination too) and the first of the custom Brazil materials
will be in the next major (non-bugfix) release, along with post effect
and general g-buffer channel support.
-The current version is now accessed as a plugin renderer.
-Brazil now performs all scene enumeration and database collection.
This provides full control over when things happen and how things are stored
and updated.
-It supports efficient adaptive antialiasing and initial image undersampling
for fast preview renders.
-Proper system wide filtering is provided by native filters (not 3dsMax's
plugin image filters.)
-Ray tracing and shading pipelines have been completely retooled to
provide more flexibility and speed.
-The system now supports separate shading rates for different effects.
For example, in the current public alpha, the global illumination solution
can be sampled at a different adaptive rate than the direct illumination
and geometry. It adapts this sampling on the fly independantly, and will
force evaluate any interpolated samples that are likely or definately in
error (eg. hit the wrong object.)
-Brazil features a native frame buffer for storing the image, which
uses floating point color representation, using 32-bits per channel, or
128-bits per pixel. This will enable effective implementations of
2.5d post process (image) motion blur, interactive exposure adjustment,
and other features in upcoming releases. It will also allow for output
to floating point file formats, and connections to compositing software
that supports 128 bpp.
-Initial CSG style primitive support has been added, with the Infinite
Ground Plane being the first available option.
Return explorers familiar with the prototype Brazil will immediately
miss a few favorite features from the original. The principle missing
Brazil 0.1.x features are Exposure Control and the Glossy Test shader.
Exposure will likely run as a standard 3dsMax Post Effect, and will be
released once Post Effect support is complete. Glossy will not be
available until more dedicated native Brazil materials become available.
The Test Material was just a good base material to test api functionality,
but it is relatively old code, and certainly not designed to take full
advantage of Brazil itself. Maintaining functionality in the Test
Material was unnecessarily consuming extra development effort, so it was
decided that certain features, particularly one's like glossy that were
just 'hacked in' would best be removed from testing entirely. Essentially,
nothing gets into the current code base unless it is implemented properly.
This is not a prototype anymore.
We have been working steadily to provide proper support for all basic rendering related features within 3dsMax. Options like Render Selected, Render Blowup, the Visible to Camera object property (max 4), light exclusion lists, etc. While we have implemented many of these things, in this initial release there are likely quite a few of these little details that haven't been addressed yet. Render Region support is not hooked in yet, the Visible to Reflection / Refraction object property isn't hooked up yet, etc. We use these two cases (render mode and object properties) to illustrate the rather hit and miss nature as to what does and does not work. We are well aware of much of what is left to do, but I'm sure we'll have missed some things even up until beta.
Post Effects is not supported. Post effect support is slated for the next major update release, coming very soon (including the Image Motion Blur post effect.)
Non refractive transparency (opacity and opacity mapping in Standard Material) is not supported in this release. A future build will introduce this capability.
Depth of Field functionality is available, but it has only been updated
enough to get the old depth of field style sampling functional enough to
use. Depth of Field is such a popular effect, we really had a hard
time disabling it for any public release, so it is available. We
recommend STRONGLY not combining depth of field with global illumination
effects. If you do, reduce the global illumination sample rate to
a lower number (2-3). When you do so, the software is behaving much
more like the original Brazil, so expect slow render times. Unlike
previous releases, there shouldn't be any problems combining the adaptive
image sampling (antialiasing) and depth of field. This includes being
able to undersample the image while using depth of field. Independant
shade rates currently have no effect with depth of field enabled.
Plugin Renderer
Brazil is now accessed as a standard plugin renderer for 3dsMax.
There is no reliance on the default scanline renderer. The only dependency
is that standard max shadow maps are still rendered by the internal shadow
buffer renderer in Max, which is a subset of the scanline renderer.
Brazil has full control over the scene database rendered by the shadow
renderer, so many 'tricks' are still possible with regards to memory usage,
but standard Max shadow maps will render the same in Brazil as in the default
scanline renderer. Brazil will feature its own shadow mapping technology
in the future.
While the front end for Brazil r/s in 3dsMax is implemented as a standard renderer plugin, in many ways it does not act the same as a typical plugin renderer for Max. One very noticeable difference is the ability to operate most of the 3dsMax interface while rendering. Also, some changes to the scene will actually occur imediately as the render progresses. Viewport redraw has been disabled to prevent severe perfomance hits when windows are moved and viewports exposed, but if you accidentally click in the viewport, any change you unknowingly perform (say moving an object) will happen, but you won't see it until rendering is finished, so be careful.
The most useful (and safe) way to take advantage of this feature is that you can save your Max file after the render starts (in case you forgot), and you can also save the image while it renders. Just hit the file save button in the BrazilVFB toolbar and save the image as normal. You can make material changes in the material editor, but you will need to have medit open before rendering starts, or the sample spheres will not update until after rendering is complete. Material changes will take affect immediately.
Renderer settings (those in the actual render dialog) are not 'live'. Some of these settings will be latched in the future, allowing on the fly changes. For now, it's nice to be able to change settings as they are thought of, instead of remembering or writing things down (or cancelling the render). For the renderer settings, changes will occur between frames when rendering a sequence. For example, if you change bucket order when sequence rendering, the next frame will use the new bucket order.
You should avoid changing geometry in any way during a render (including position, rotation, etc.) as this may lead to a crash.
The Scene Database
Full scene enumeration and management is the most significant internal
change to Brazil. The comment has been made elsewhere that writing
a production level renderer is more about database programming than rendering
technology, and the new version of Brazil emphasizes this area. We
have done an extensive amount of planning and foundation work to enable
advanced, intelligent management of complex scenes and system resources.
This will include many different obvious optimizations such as only updating
data that changes from frame to frame in an animation, and only generating
meshes that are needed. This first release does not pull any tricks
to lazily evaluate anything. While it is certainly ready to handle
this sort of detail, no one has done this before with a plugin running
as an integrated renderer in Max, and we need a baseline stability release
to test against before rolling those features into the testing cycle.
Brazil internally supports renderable geometry via an abstracted system of Primitives and Render Primitives. Primitives are generally composed of 1 or more render primitives. An example render primitive is the standard polygon, or in 3dsMax, the faces that make up an object. The object itself would be the primitive in this case. Max meshes are stored as Poly Primitives, primitives composed of polygons. The current version also has a basic CSG (implicit surface) pipeline in place that integrates seamlessly into the general rendering and shading pipelines. The only feature available here is the Infinite Ground Plane. The white material on the ground is a standard Brazil r/s shader, and the entire shading pipeline is oblivious to the fact that a csg primitive is being rendered. There will be many more features available here in the very near future, once we make sure the overall kinks are worked out via this simpler test case.
Materials are stored internally as Brazil r/s shaders. Native Brazil shaders have access to a whole extra level of control and api functionality over standard Max materials, however any material that runs in 3dsMax should work in conjunction with Brazil, in particular it's advanced illumination features such as global illumination and the forthcoming area lights. There is no need to convert your materials to Brazil specific materials, unless you want the extended control. The first of the new materials will be made available in a subsequent release.
Recursive Image Sampler
Antialiasing and general image sampling are now handled by an efficient
recursive sampling engine that is capable of starting at less than 1 sample
per pixel (undersampling) up to very high sample densities (16x16 or higher
with small buckets). The engine is capable of refining different
shading effects at different rates, up to the maximum rate for the entire
image. The sample rate is generally defined as the number of samples
per pixel.
The ability to start undersampled is not only very useful for low quality preview renders, but it can be used independantly with the various shading effects in the system. For example, you can have the global illumination solution sampling begin at 1 sample for every block of 16 pixels, but the general geometry and material sampling start at 4 samples per pixel. The adaptive sampler will automatically detect errors in the undersampled effect and force new samples to be gathered if necessary as general geometry and material sampling progresses (see Independant Shading Rates below.)
Background image evaluation is separate from the general image sampling process. Backgrounds are always sampled from the center of the image pixel, 1 sample per pixel. The image filter is not applied to the background. Standard 2d map filtering is applied unless disabled in the 3dsMax map itself, or in the Brazil Filtering Controls.
There are still some remaining quirks in the sampler, as it is very complex. Currently, as the maximum image sample rate changes, the image will shift slightly. This is the image registration, and we will be fixing this shortly. You will also have the ability to offset the image any number of samples vertically or horizontally, as well as scale the image, to manually match output from other renderers if necessary.
The amount of information stored in a bucket is directly related to the maximum number of samples per pixel. If you are using high max sample rates, like 1/3 or 1/4 even, you will want to use smaller buckets. Bucket Size of 64 is currently recommended for a maximum sample rate of 8x8 in the rate calculator (min 1 / max 3 is an example setting that produces an 8x8 max sample rate.) At 16x16 you will definately need to use a bucket size of 32x32 or even 16x16.
This leads to the issue of bucket artifacts, which will be dealt with soon. Bucket artifacts are inconsistencies at the edges of rendered buckets that are caused by an absence of sample information beyond the edge of the bucket.
Independant Shading Rates
Directly connected to the recursive sampling system discussed above
is the sampling engines ability to sample different effects at different
rates relative to the full image. The feature to receive this treatment
first is the one that stands to benefit most, global illumination.
An important thing to note about the independant shade rates is that they
do not apply to depth of field renders currently. Again, working
with depth of field is a bit tricky in this release, as it hasn't been
updated to take advantage of the new capabilities in the core of Brazil.
The reason the effect is most beneficial for global illumination, is that it requires a great deal of computation time to accurately determine the amount of indirect illumination arriving at any given point on an object. In most cases, however, the global illumination 'solution' doesn't change very quickly, especially over smooth surfaces. Sampling global illumination at less than 1 sample per pixel may be adequate in many cases, provided each of these image samples is the correct solution. This has introduced a new way of working with the global illumination and can result in dramatic speed increases. It is now recommended to use high quasi monte carlo sample rates, and start with an undersampled GI solution. Set image sampling to whatever you prefer. If you combine extremely undersampled global illumination (shade rate -3/-3, qmc rate less than 5, and image rate -2/0, you can get very fast preview renders of the lighting in your scene. For finished renders, you will likely want to use a shade rate of -2/0 or higher, a qmc sample rate of 25-60+, and image sampling to whatever is desired for antialiasing purposes.
Native Filtering
Brazil now features its own plugin filters. These are currently
only accessible directly for general image filtering, but they can be used
by any 2d sample collection process that requires filtering. Available
filters are limited to Area and Mitchell-Netravali. Mit-Net is the
default and general looks better than Area. There will be quite a
few more filters added before version 1.0.
Improved Ray Tracing and Shading Pipelines
The general ray tracing and shading pipelines have both been extensively
reworked and enhanced to provide more flexibility in the internal api's,
and speed. From an api standpoint, the changes will allow a very
rapid prototype through delivery cycle for the development of new rendering
tools such as shaders (materials), lights, sampling systems, etc.
This is very important for a production level renderer, where reinventing
wheels over and over again generally isn't an option. The need to
pull from an existing library of tools, and easily add and extend this
library is critical to the fast turnaround required when developing tools
in a production environment. It will also allow us to quickly add
many long requested features to the system, many of which are nearly complete
already.
Along with extreme extensibility and a solid api, the new ray tracing and shading pipelines are capable of much more efficient caching and reuse of information, so that the same information is rarely (if ever) generated more than once. This has resulted in a significant increase in general rendering performance, with more to come in the near future.
Default Accelerator Changes
BUG ALERT: The Default Accelerator has a known bug, and it is most
severe when using Single Grid mode. You should basically always be
using Manual Hybrid, but you MUST make some effort to group your scene
properly (see explanation below)
We are all familiar with how easy it is to unbalance the single nested grid as an accelerator, based on our experience with every other version of this software. A really dense model will render much slower when placed on a ground object. Basically, the more spread out the scene became, the more empty grid space rays had to be traced through, slowing renders down. The time has come to deal with this issue, as the single nested UGrid will not get much faster.
The next step is a higher level of organization or partitioning, to allow the use of multiple acceleration structures efficiently. These multiple UGrids in this case can and should contain an arbitrary number of objects, but be organized so that each grid has as little empty space as possible. Quite a bit of research has been done on this subject, but no really ideal solution has been found. Before implementing all the heuristics to perform this automatically, it is important to do some testing on production scenes to determine the best course of action to take in some problem cases. One big object that contains the entire scene, a not uncommen affair, is actually a fairly vexing problem for automating things. The primary underlying algorithm, bounding box merging, falls apart in this case. If this object gets a separate partition, virtually all rays traced in the image will need to be traced through this grid, as well as tested against the rest of the scene. Anyway, we need to explore a bit. So, the goal this round was to make sure that the system would work correctly with multiple grids.
The way the system works at the moment, is that any object, group, or link hierarchy hanging off the root scene (not linked to anything) gets a grid to itself. If you have a complex robot or character model, make sure the character is linked to a master 'dummy' helper, or grouped, and all the objects in this group will be added to the same grid. It doesn't matter how deep the hierarchy is, how many nested groups there are, or if it is a 'mixed' hierarchy of renderable and non-renderable objects. All the renderable objects in the group/hierarchy will be added to the same grid. In the case of a space station next to a planet, the space station is one group, the planet is by itself. The space station itself could be broken up into 3 or 4 groups as well (1 around each solar panel setup, one around the main body of the station, 1 for the shuttle, etc.) While this kind of noodling is certainly unacceptable in a full production renderer (it needs to be automatic), it can be an interesting game trying to find the tightest combination of 'bounds' around the scene. Groups are useful for this, as an open group will draw the bounding box for the whole group in the viewport. This is effectively the shape of the grid. Your goal is to minimize empty space inside these bounding boxes, while keeping the number of groups as low as possible.
In order to enable the multi grid behaviour, you need to go to the Default Accelerator settings in the Ray Server, and switch the top drop-down list from Single Grid to Manual Hybrid. The reason it is set to the old single grid style system by default is to force people to think before hitting render. A scene with 2000 loose objects will generate 2000 separate grids and likely render pig slow. Try and keep the number of groups, etc. below 10, with the fewer the better for now.
Native Frame Buffer
Not much to go deeper into here. The frame buffer stores the
image with a full 32-bit floating point number for each color channel,
which is 128 bit per pixel. This allows post render color manipulation
with the potential to introduce banding. The rendered color are not
'quantized' in any way, that is, the number of potential colors is nearly
infinite.
The Future
While getting to this point has been a long journey with no public
releases, that doesn't mean we intend to go quiet again for several months.
This is just the tip of the iceberg when it comes to the tools already
developed. We expect to provide very frequent updates from this point
on, and we think you will be pleased with how rapidly bugs are fixed and
new features released.
Good Luck, and as always...
Have 'fun'.