Friday, January 17th, 2003 Article by Jean-Eric Henault

Interview with Scott Kirvan

Last week, Splutterfish finally released Brazil 1.0, one of the most advanced rendering solutions out there. Brazil, formerly known as Ghost has created quiet a stir in the industry for a couple years now. We interview Scott Kirvan from Splutterfish reveals the secrets behind this impressive new rendering tool.

CGC: Brazil…, formerly codename Ghost… What brought on the name change to Brazil?
SK: We had a trademark conflict. There was an other product called Ghost, so we had to find a new name for ours.

CGC: And why Brazil?
SK: We went through a long list of names at first, but no one name ever seemed good enough for a variety or reasons. We’ve always liked place-named code-names like Chicago or Cairo for example. We looked at a map and saw Brazil. It’s a nice short word, it’s memorable, got a good shape and sound to it. The credit here actually goes to Steve’s step-sister on picking out the name. Once we heard it we just all felt it fit.

CGC: How long has it been in the making?
SK: Steve Blackmon (co-founder of SplutterFish) and I have decades of experience working on rendering code and it’s all contributed to where we’re at now, with Brazil. We started making Brazil into a commercial product about a year ago, in February. Prior to that, we were experimenting on Ghost for about a year. We were just having fun with it originally and it became quickly obvious that what we were doing was pretty cool and very useful. The technology had some obvious performance tradeoffs, but you could save so much time on the front-end in terms of animator time. It was so much easier and more natural to set-up. The new lighting tools and the breadth of shaders makes it feel more like you are working on film rather than being constrained within some alien 3D computer graphics environment. The lights work as expected, modeling details show up as they should, etc. The whole process just feels more natural and common sense.

CGC: When you hit render then will 3ds max use Brazil as the default renderer of choice?
SK: You can switch Brazil r/s and the scanline renderer in max. Max takes plug-in renderers, so we integrated Brazil as a plug-in renderer. The integration is really seamless, and with an exception of certain functionality in certain plugins, it supports all the 3rd party software and plug-ins out there for max. It uses all the max cameras and lights, but we also have our own camera, lights, materials and shaders. By using the Brazil specific lights, camera, and shaders, you get access to a lot of optimized and specialized functionality.
CGC: So, you just switch between the two environments?
SK: The interface just pops up in place of the Max renderer

CGC: How would Brazil work with such 3rd party plug-ins like Shag or Shave and a Haircut?
SK: Brazil works seamlessly with most 3rd party plugins – including Shag and Shave and a Haircut. Both of those are hair plug-ins, so when running in buffer mode or atmospheric mode, they use their own internal renders, which unfortunately don’t know anything about GI, but the hair still looks great. We are developing the max version of Joe Alter’s Shave and a Haircut and even when rendering with GI the hair looks just fine. Brazil works well with tons of plug-ins in max. We ourselves come from a production environment and compatibility with existing tools was very important to us. We knew that we would never tolerate anything less.

CGC: Do you still do production from time to time?
SK: We never have time! But I’d like to get back into VFX work — at least ocassionally.

CGC: Do you need to have Max open to render or is there a standalone or command line option?
SK: You can use Brazil in workstation mode or in network rendering mode. On the network, it will render on the nodes without the interface. But you still need max to read the files. 3ds max scenes are meta-files, so the scene doesn’t exist until it’s constructed by max, then it opens up a bi-directional pipe between max and Brazil where the data is manipulated back and forth between the two. We do have a command line option for use with R3, but we dont’ have the R4, R5 version yet.

CGC: Can you tell us what “Bucket Rendering” is?
SK: Bucket rendering is used to deal with tradeoffs between memory usage and performance. In Brazil r/s, there is a lot of extra data associated with each pixel at rendertime (essentially, a deep pixel). Without access to huge piles of memory, you can’t keep all that data around for a whole image. By breaking the image up into small sub-images (buckets) you get the advantages of all that deep pixel data without having to keep a whole image’s worth of data in memory at once. Buckets also allows you to load balance better when you’re doing distributed rendering, which has been part of our initial plans. We are working on the distributed network renderer at the moment. It enables you to break-up single images into smaller pieces and render them across numerous machines at once.

CGC: Now in the list of features it mentions that Brazil has a sophisticated Anti-Aliasing algorithm built in, how does that compare to the current options available in the default max renderer?
SK: The default max renderer is a scanline renderer that originally didn’t have much support for texture/material antialiasing. Scanline renderer’s are naturally good at antialiasing geometry edges, but not very good at textures. There has been some effort made to address this in max’s default renderer, and the problems can for the most part all be overcome, but anyone that’s tried to deal with animating overbright highlights or high frequency bump maps knows the problems that can crop up and the difficulties in eliminating them.

Brazil r/s is a raytracer and as a raytracer, the nature of the antialiasing problem is different. In a general sense, Brazil uses the same antialiaser for geometry edges and for textures/surfaces. What this means is that if your object edges are good, chances are, you texture aliasing will be too. The same algorithms that determine if the edge of an object is adequately antialiased are used to determine if highlights, bump maps, surface colors, etc. are antialiased. Steve and I have been working on this antialising problem for years and we’ve really got a good system in place now in terms of both performance and quality. It’s attractive to try and sacrifice antialiasing quality as a cheap speedup in a renderer, but aliasing problems have to eventually be addressed by the artists in production. When that happens, any of the early shortcuts will come back to haunt you and you’ll end up in worse shape performancewise.

CGC: Will you support subpixel Tessellation in Brazil?
SK: Version 1.0 of Brazil doesn’t do rendertime displacemetents or subdivision surfaces. This is definitely an area we’re going to be getting into in future work. Now that version 1 is out the door, we get to start playing with new things again.

CGC: So, you designed Brazil to be expandable for developers?
SK: Yes. Brazil is designed with a lot of pluggable subsystems – acceleration systems, lenses, shaders, etc. We don’t have a public API yet, but we’re currently developing against our internal API. Brazil is designed to be extensible and modular. Once the base systems are in place, throwing in new features is a breeze. For example, the current shaders were developed with the preliminary version of Orchid, a shading language based on RenderMan shader language. We can now whip out these new and really complex materials and shaders really quickly with just a few lines of code.

CGC: For those of us that are game developers, what do you offer in the light of Baking lights and GI into texture maps for use in real-time gaming?
SK: We don’t offer any form of built-in texture baking at this point. This is another one of those things we really want to get into, but we had to get the 1.0 version stable and out the door first.

CGC: Will there be support for a post DOF format like rla to fit in a pipeline with programs like combustion?
SK: Brazil supports rich-pixel formats like RLA and RPF. The current implementation doesn’t support all the render elements layers, as the way they are implemented in max destroys any real hope of shader language support, but we have added a special RenderPasses system that’s designed for the same purposes. The RenderPasses works more like standard rib hacking so its actually a lot faster than render elements in practice.

CGC: For my last question, what do you see in the future for Brazil? Will you work on support for other applications? Xsi…, Lightwave…, or Maya maybe?
SK: Definitely. We have to get all the resources together and everything, but I would like to see Brazil more broadly used. Most production houses don’t just use one package and it would be nice if regardless of the package being used, the artists had the option to use Brazil.

CGC: I guess you must first recover from releasing 1.0, but do you have any timeframe?
SK: We just released 1.0, so we’ve got to catch our breath a little. Once things settle a bit we’ll get going on the next phase of development with Brazil r/s. We don’t have any ETA or schedule yet. As soon as we do we’ll make some announcementes to get the word out.

CGC: What’s the next big thing for Brazil?
SK: Lots of things. We’re going to be working on getting in some really good and usable displacements, building a stand-alone version of the renderer, making it work with new applications, coming-up with a really good and very slick process distributor for distributed network rendering… We’ve got lots of cool ideas and plenty of work still ahead.

From the Editor: Big thanks go to Xen Wildman and Diego Rojas for making this possible.

Related Links: