Blender to RenderMan

Pixar and Greenbutton reveal RenderMan On Demand

2012-01-29T18:15:00.000Z

In 2010 Pixar had demonstrated RenderMan running on MicroSoft's Azure platform, as reported here http://www.blendertorenderman.org/2010/11/pixar-and-microsoft-cloud-rendering.html, however back then it was only a demo. As of Jan 19, this has become a real working service thanks to GreenButton, Pixar's RenderMan On Demand is now live and ready for all your rendering glory, for a price of course. To be fair .70 cents a core hour is really cheap, of course this is based off of third party information, mileage may vary.

So it looks like cloud services are becoming more and more common for the 3D industry, while there has been renderfarms that existed before in the sense of a traditional farm, the difference is that GreenButton is a cloud based service. The advantage of using cloud service rather than an in house farm is that there is no initial huge investment in hardware, you only pay for the use of other's hardware. The obvious reason for an in house renderfarm is that it is tailored to the studio, you have complete priority over jobs and it looks pretty impressive to the outside world. Smaller studios lack huge pockets though, so cloud rendering is far more valuable and attractive than investing that same amount of money on a few servers.

There is another method for us to render out frames without tying up our computers for hours or days on end; distributed computing. Distributed computing is also a way for Blender artists to make use of a renderfarm without having to spend a serious amount of money, in fact with Renderfarm.fi this is possible for free. Much of the well known distributed computing projects like SETI@Home are based off the BOINC platform, this is a distributed server-client system that has connected millions of computers worldwide all for the name of science. Why not take advantage of the same system for rendering and that is exactly what Renderfarm.fi does, it enables Blender users access to a large number of rendering nodes for free while also providing your computer as a rendering node for someone else's project.

This is a service that is based off of BURP, the technological framework for using BOINC as a distributed renderfarm, written by Janus Bager Kristensen. BURP started several years ago and works closely with Renderfarm.fi yet the two are completely different entities.

The question I have is, why not start something like this for Aqsis, or Pixie? Renderfarm.fi has done a very good job of marketing themselves and in all reality they do not even handle the actual rendering, that is taken care of by us BOINC users. In theory this kind of service could be started for Aqsis as well. Can Aqsis and Pixie be added to Renderfarm.fi, or even have a new website devoted to this? Can open source Renderman be turned into a cloud rendering technology? I believe it can, however I am not the most talented programmer in the world, so personally I would be a horrible choice for a developer. I have been looking at the code, not to mention that there has been some talk over forums with the BURP and Renderfarm.fi guys about supporting other external rendering software, it looks very possible to get Aqsis at the very least. The wall is of course the development of supporting this, as Blender changes these guys have to make changes in their own software, keep up BURP and Renderfarm.fi support and then fix things when it breaks, so this does cut into time and energy into other render engines. Not to mention the server itself needs to be pretty beefy, funding for the static IP and cost of hosting this, unless someone out there is willing to donate this. Would there even be enough interest to work on such a project? This obviously needs to be a project outside of BURP and Renderfarm.fi but in communication with so that if this works and tests well, then maybe it can be added to the Renderfarm.fi service.

The reason for this post is primarily because I used to be one of the biggest nay sayers against community based distributed rendering, claiming that too many technical factors outweigh the benefits but in the past year I have come to realize that maybe 5 or 10 years ago this was true, now it appears that this no longer is the case. When I first heard of BURP many years ago I thought that it was a neat project but would probably not work out in the end and look at how wrong I was about that, not only has this evolved into one of the only community based distributed render farms on the planet but has allowed every single Blender artist access to it, for free. That is an amazing feat and probably one of the greatest additions to the Blender community period, hence the reason this website has their logo graphic on the sidebar, these guys are awesome!

Cinepaint Developments

2012-01-02T18:58:00.001Z

One of the most overlooked software packages in the Blender to Renderman arsenal has been given a new breath of air by the developers, Cinepaint 1.0 was released during the end of November (sorry guys). What makes Cinepaint so powerful and unique compared to it's parent GIMP is that it was designed for film work from the start, it is meant to handle 32-bit HDR images that are impossible to open in GIMP, which is why studios continue to use Photoshop among other things. After what seemed to be a very long stagnant period of lack of updates and uncertain future, Cinepaint has exploded into the scene again, even getting 3D World attention with an article, not bad for an open source software that was a fork of GIMP. At this time there is only a Linux source of Cinepaint and it has it's bugs, in fact version 1.1 is being delayed due to a nasty memory leak.

Aside from the issues here are some of the things that Cinepaint users might expect to see in the future as described by Robin Rowe

---

CinePaint Multi-bit Image Engine

CinePaint will continue to have a multi-bit engine. Some programs support deep paint by setting bittishness at compile time. You can have an 8-bit or a 16-bit core in ImageMagick, for example, but not both. It depends upon how ImageMagick was compiled. CinePaint has a true multi-bit engine where bittishness is chosen at runtime depending on the needs of an image. When you open a JPEG, CinePaint will allocate 8-bit channels for it because that’s what the image holds. When you open a 16-bit TIFF, it will allocate 16-bit channels.

At present, CinePaint supports unsigned 8-bit, binary fixed point 16-bit, half float 16-bit and float 32-bit. That’s a lot of flexibility in channel allocation, but not quite as much as we’d like. OpenEXR files may contain unsigned 32-bit channels and TIFF may have unsigned 64-bit channels. It would be nice to be able to open those in CinePaint without a loss of fidelity.

Comic Book, Anime and Fashion Illustration, Heads at Any Angle

Adding to ideas expressed in an earlier story, it would be nice to have an interface that supports pulling images from a library of art created by the artist, such as having a character’s head drawn at many different angles. This would enable an artist to quickly drag in previously drawn elements to quickly build an illustration. It would be nice to be able to mirror clone when half of a face is drawn in order to quickly draw the other half.

Architecture

There’s a lot that could be done to make architectural drawing easier. One would be a cross-hatch brush that would draw parrallel lines at a fixed separation locked to the background position so that drawing later with the same brush will line up perfectly. The angle of the cross-hatch would be a setting on the brush. Another important brush for architecture would be a perspective brush that draws straight lines according to the horizon specified by the artist for the picture. At zero degrees it would become a railings brush and have no crossing lines. There could also be brushes that draw boxes with proper geometry per the background horizon. There could be a clone brush that copies with perspective, whether it’s drawing bricks or a window that needs to be repeated across a building.

Roto and Tracking

Adobe After Effects has an excellent auto-roto feature that will separate foreground objects from their background. Surprisingly, Photoshop does not. It would be nice if CinePaint had auto-roto. It’s not surprising that Photoshop doesn’t have tracking and image stabilization like After Effects. It would be nice if CinePaint did.

Colorization

There’s a plug-in for painting colors from a similar photo onto a B&W image. Would be nice to have that type of thing as a standard clone brush feature.

Slides and Sequences

CinePaint’s flipbook can be used as a PowerPoint-style slide presenter. That could be further developed. While you can load a sequence of numbered images in CinePaint, there’s no way to save that sequence as a sequence. It would be nice if it would.

Brushes

In addition to the architecture brushes already described, it would be nice to have brushes that draw borders and to paint Apple-style liquid buttons. It would be nice to have a bucket brush that bucket fills but will not seek out through gaps smaller than the size of the brush. It would be nice to have a “sloppy” setting on the brush the can exaggerate or reduce the jitter with which a line is hand drawn, something like in Smart Sketch. There could be brushes that draw flowers or any randomly repeating “image tube” as in PaintShop Pro. As the brush paints it lays down the next image (or flower) in the tube. Another nice brush would be a human pores brush that adds pores to portraits that have been magnified.

Magnifier

It would be nice to have a magnifying glass like Apple Aperture.

Meta-data

It would be nice to support such things as keeping accounting data for the time spent working on an image.

Vector Graphics and Type

Artists seem to agree that moving between Adobe Illustrator and Photoshop is inconvenient, that we’d rather do to one app to paint. However, mixing vector graphics and rasters gets messy. A solution is to put vector objects, including type, in a separate layer.

Adjustment Layers and Nodes

It would be nice to have adjustment layers, that is, layers that dynamically enhance the image below instead of changing the layer with a filter. Layers and nodes can be thought of like waves and particles in physics. They’re two ways of looking at the same thing and yet seem quite different. It would be nice if CinePaint displayed nodes.

Scripting

CinePaint has supported many scripting languages, but it hasn’t been a satisfactory user experience. Preferably, CinePaint would record macros/scripts implicitly and at all times like Apple Shake. That would be a better solution than the Adobe Photoshop macro recorder that requires the user to decide when to record a macro first. Taking scripts a step further, it would be nice to have a text-based way to create image files. For example, to be able to quickly snap together a color bars image from a text description of the sizes and colors of the bars.

Sound

CinePaint has a flipbook movie player, but no sound. It would be nice to have JACK support so external JACK-compatible sound tools like Traverso would play in sync.

High Fidelity Color

CinePaint has a RGBA color space by default. Work’s been done to support advanced color management and other color spaces such as CMYK in CinePaint. It requires a domain expert in the printing industry to really get this right. Enhancements provided by a German open source developer have been difficult for CinePaint users to comprehend. To advance in this area we first need a color expert who speaks English, someone who can explain to me what we really need in the color interface and who can test that we got it implemented right.

---

Sorry for the lack of updates in recent months, my personal life has been quite filled with obligations.

Farewell Mr. Jobs

2011-10-06T17:51:00.000+01:00

Today I learned of the passing of Steve Jobs. While I have not recently been a fan of Apple, the patent lawsuits between Apple and other companies has irritated me to no end, I do not think less of the man that helped bring about the PC industry, as well as bringing Pixar to the world.

When I was 16 I bought my first computer, a PowerMac, one of the first generation series even. At a blazing speed of 66 MHz, loaded with 8 MB of RAM and a huge 360 GB hard drive, I began to learn the art of 3D using the LogoMotion app by Specular Int. At the time I had no concept of real world 3D practices, however I managed to exceed the tool makers expectations of the software by creating character animation using this logo animation tool. I eventually ended up beta testing the next version, which I got for free upon release plus a tshirt!

Later on I learned about the obscure RenderMan software, developed by Pixar, in 2002. Prior to this I had no clue what was used to render out all of Pixar's films, quickly I learned that Pixar was instrumental in bringing about the visual effects industry via ILM in the early 90's. This is when I found that Steve Jobs bought Pixar from George Lucas in the mid 80's for a paltry $10 Million, Lucas was broke and needed money, something Jobs could afford and saw early on that this small division of LucasFilm could become great. I think Pixar as a company exceeded even Job's expectations, growing from a small software development company into a massive animation powerhouse that redefined feature film animation.

Steve Jobs brought the world many new technologies and new ways of thinking. He was a pioneer and a rebel.

He will be missed.

Point Cloud Indirect Lighting in 3Delight from Blender

2011-10-05T18:43:00.000+01:00

Matt Ebb uploaded a video last month which shows off point based indirect lighting using Blender, his own RenderMan exporter and 3Delight. We all know 3Delight is a commercial renderer, we also all know that at everyone can get a single free license for non commercial work, which allows us to use a production grade renderer with Blender and take advantage of it's power. As such, this is why Matt Ebb has focused on creating the addon for 3Delight specifically, rather than a general RenderMan script.

In this post Ebb writes :

"After fixing some cross-platform issues that people were having with the last few versions, here’s a new release of 3Delight/Blender. As well as the fixes, I’ve included some new stuff that’s been on the backburner for a while – a new point cloud global illumination method. When enabled, the addon will automatically generate a point cloud, and then use it in the render for indirect lighting and environment lighting.

It’s just doing one bounce of indirect lighting, in the future it should be reasonably easy to add more bounces via photon mapping in the point cloud generation stage. Eventually I’d like to make this a bit more advanced, with a more modern design for the lighting/shading pipeline and more control over baking pre-passes, but for now (especially since I’m quite short on time ) I’d rather get it out and working in a simple, automatic way so people can use it.

I’ve tested this on my mac, and in both Linux and Windows XP VMs, but as always, if you have any problems on your system please let me know."

Download the new addon here: render_3delight_0.7.0.zip

Aqsis 1.8 Sneak Peek

2011-08-30T23:06:00.001+01:00

The Aqsis developers have been quite busy trying to get all the features and changes ready for the 1.8 release, some of which has helped secure the future of the open source renderer. Since it's inception, Aqsis has always been a "old-fashioned" REYES rendering application, that is it had the functionality that complied with the requirements of the RiSpec, as well as additional features however it lacked the more modern rendering methods such as point based rendering. That is soon changing as reported earlier this summer and it was uncertain if these changes would appear in the next release, or in the 2.0 release, so it has been confirmed that the new point render branch will be merged with the main branch for the next release.

On July 31 the Aqsis team officially announced "Phase 1" for the next release, during which time will be focused on completing the new features.

Other additions include support for OpenImageIO, which was written by Larry Gritz, as well as Partio by Walt Disney Animation.

The main feature changes for 1.8 are as follows.

1. Point Based Global Illumination

bake3d()
occlusion()
indirectdiffuse()
texture3d()

2. Rewritten RIB parser

Inline archives are supported, using ArchiveBegin/ArchiveEnd
Frame dropping is reimplemented to allow a single frame to be selected.
Archive interpolation in miqser executes ReadArchive calls in place.
RiContext() / RiGetContext() now supported for the core renderer.
RiBegin("something.rib") can be used to produces RIB via the core renderer lib.
Validation of array lengths and parameter ranges for all RI procedures, used in both the core and in miqser.

3. Port all GUI tools to Qt.

4. Begin relicensing under BSD style license.

As some of you might know, Aqsis does have a couple of GUI based tools, Piqsl and Eqsl, both of which allow users to use Aqsis without having to resort to a command line to render a file or view an image. Piqsl is more commonly used as it is the primary framebuffer tool to watch the renderer at work, as well as use the tool to view multiple images, or to help with development of a render or shader as you can flip through the images. Eqsl allows users to render a RIB file, convert textures to a MIP map, or compile a shader. Both tools were an addition several years ago and have been evolving since and now they both have been ported over to QT, the GUI framework from Nokia, previously they relied on FLTK. While FLTK did provide an easy way to build a GUI app, QT has been chosen to replace it as the framework is proving to be more popular and many 3D tools and applications are using it as well, both commercial and open source.

The most exciting features of course is the Point Based Global Illumination stuff and many people all over the world are happy to see that Aqsis is evolving. This is the one of the most important things done to Aqsis since the renderer debuted on SourceForge in 2001, simply because the addition of the new GI code has changed it. Now it can work with GI much the same way as 3Delight and Pixar's RenderMan can, aside from the fact that ray tracing is still not possible yet. That is something to come about later on. Below is a very recent render with the latest Git source, which as of this week includes the point render branch added to the trunk.

Point Based Global Illumination with Aqsis

Aqsis 1.8 has a few more months of work before it officially is released.

This also comes shortly after a CGSociety article about the very subject, which ultimately led to another debate as to whether or not Renderman was dead, given the success of proprietary renderer's such as Arnold and CGStudio++. Regardless of who is sided with whatever software, Renderman still holds the title of being the one that brought CG to an affordable means of visual effects in film, has been for over 20 years now and not many other rendering software can match up to that record. That said the article in question relates to Point Based Global Illumination in Pixar's RenderMan, which is interesting to note that the Aqsis team was busy getting this very method of GI stable for release at the same time.

Another reason for the sudden shift in the Aqsis team to get more modern rendering methods into this now 10 year old project (missed that little bit of info until just now, Aqsis was registered on March 14, 2001), the decline of development with Pixie, the one time champion of open source Renderman with ray tracing and GI, which in some ways still is, however the development seems to have slowed to a halt with no new updates in years. So while the last working version of Pixie still works for this kind of thing, the Aqsis guys are taking a more pro-active approach and taking on the role as the open source Renderman of choice. Others are taking their ties to the team to help implement Aqsis into professional studios, others are developing plugins to work with Aqsis and providing technical support.

During SIGGRAPH the Blender team had a lot of interest by studios interested in placing Blender into their pipelines, something we have been dreaming about for years so now that the link between Blender and Renderman is getting tighter it is only a matter of time before these tools will be added as well. In certain places this has already happened. Once Aqsis is released fully in 1.8, this gives it a step up into the realm of professional use and give the renderer a massive step up in the world of open source visual effects.

Aqsis Website

SIGGRAPH 2011 opens up new avenues for Blender

2011-08-22T19:25:00.002+01:00

This year's SIGGRAPH seems to be a solid turning point for Blender and it's developers. According to Ton, there was quite a bit of interest in Blender from the professional industry, which is amazing news to the entire Blender community since for years it has been bashed as a "hobby" app. Over the years Blender has been evolving and in such a fast rate that it is almost hard to keep up, however one of the most impressive changes is of course the interface, which on the surface level is pleasing to the eye and thus people are more inclined to explore more of Blender, from there they understand just how powerful this open source app really is. Shame it took them this long to figure this out, however Blender was a different beast even 5 years ago when the Blender to Renderman community was just a tiny speck compared to what it is now. Just in two years Blender evolved again into a very formidable piece of software. In turn other software that are commonly used in conjunction with Blender is evolving too, thus opening even more possibilities to the community at large. Then there is the community, of which had it not been for the large number of users that devote vast amount of time working with, or on, Blender, none of this would have happened in the first place. Blender truly is now making some serious headway into becoming a widely adopted tool for content creation and it all started as an internal tool for a game company. Amazing how events unfold over time.

From the Blender. org website.

Tradeshow booth

During three days, 9-11 August, Blender Foundation presented Blender + art showreel at 6x3m booth at the tradeshow floor.
Link to showreel download & youtube coming soon!
HP provided us 4 fast workstations and 30" displays.
100 Blender shirts and 1500 Blender DVDs were handed out (also thanks to sponsors Lumikuu &Renderfarm.fi)
Demo DVD made for FMX by Francesco Siddi & Sebastian Koenig & Thomas Dinges, thanks! ISO download is free to spread and use.
Booth attracted visitors from all over the world, all over the industry... including artists from Pixar getting personal demos.
Our OpenCL (Cycles render, compositing) projects attracted visitors from all main Graphic cards vendors (Intel, NVidia, AMD/ATI). They are seriously committed to help out with Blender testing and advising us on best usage of of OpenGL and OpenCL features.
Early demos of motion tracking did people's head turn too. It appears we're providing the first cross platform free/open tracking tool for film makers here.
Met with author of MeshFlow, a Blender based research paper accepted for Siggraph.
Had a good meeting with Khronos, discussing our COLLADA support and established tight connections to get further support.
Talked to many journalists; including 3D World, 3D artist, Renderosity.
Interest from new developers, among which Ari Shapiro of ILM/R&H fame
Several film/vfx/animation studios interested in integrating Blender in pipeline, but they need consultants to help them. (will be via Blender Network)
In general: so cool to see so many artists dropping by who already were using Blender professionally and with great results.

You will note that one of them involves integrating Blender into pipelines at studios, a HUGE step forward and something that has been dreamed about by many Blender users, developers and of course Ton himself. THIS is what we have been looking forward to and now it looks like the professional industry is finally coming together and looking at Blender as a viable tool, not as a hobby toy. In the past few years many studios have released open source projects for visual effects and animation, which some of these in turn ended up in Blender, so it makes sense to look at Blender to do certain tasks which is compatible with said projects. Hence the purpose of open source.

The other factor is cost, as we all know the world economy is not exactly great and this does have a strain on the entertainment industry, since they are paid from the money we spend on their products, people are not spending as much so thus the industry is not making as much as before. A studio used to be able to spend hundreds of thousands of dollars on software alone, during the early 90's this was no big deal since it was new and exciting, producers were willing to fork over millions to make the next blockbuster. Now visual effects are common in nearly every film made, so the luster is gone and the cost is rising each year to make even non visual effect heavy films, studios are looking to cut costs. One such measure was taken by replacing expensive SGI workstations with PC's, since hardware costs kept going down and computing power increased every couple months. 3D software in the early 90's were really a niche market and the internet was not as expansive or utilized then either, some software had to be purchased over the phone it was so specialized and expensive. The software that was affordable by the general public was not as powerful either. In the following decade studios have switched from expensive operating systems to Linux, an open source and cost free OS that functions exactly as the costly UNIX systems of the past. In general studios were forking over millions on hardware and software alone, something they can no longer afford to do. 3D software still costs a small fortune, even with recent price drops across the board so it only makes sense for these places to look at an open source and cost free software, one that can be modified at whim, one that can be installed on as many hard drives possible without licensing fees, one that is quickly becoming compatible with projects they developed, one that used by nearly every aspiring 3D artist world wide. THAT I think is the best cost solution, young talent cutting their teeth and all done without them having to spend anything on software, imagine the pool of talent in the upcoming years all trained on Blender.

Pixar artists looking at Blender is a certain glowing point for us on the Renderman area of Blender, as you can imagine, so even though it is no secret what we are doing in this corner of the internet, it feels good to know that certain people from Pixar have had a chance to see Blender itself and we just hope that this only adds to our cause.

Which comes down to our connection, the people involved with Blender and Renderman at least. In the Blender.org post, there is mention of the "Blender Network", which is a proposed network of Blender professionals that would be contracted to provide support, or something to that degree. Some people have already been doing this in their own way, including some of us. Morpho Animation Studios is beginning to incorporate Aqsis into their pipeline, as they already use Blender and Pixar's RenderMan with RIBMosaic, this should be fairly simple, though risky since Aqsis has not been used in commercial work. Regardless they are taking that gamble and have requested our help. This in turn almost requires the assistance of the various developers themselves so even though they may not directly have contact, due to people's network of connections, they are all interconnected, they also help each other out since the publicity generated works out in favor of all involved.

Funny about the image at the top, with Ton and Co. standing in front of the AutoDesk booth, the slogan "don't blend in stand out" behind them, almost nearly seems that the company is afraid and in some ways, they should be.

Morpho Animation Studio at Siggraph 2011

2011-08-13T08:17:00.000+01:00

My friend Christian Vargas sent me an email about Costa Rica being at this years SIGGRAPH. The booth monitors were showing clips of "Grampa's Robot" so viewers were watching what Blender and Renderman can do together, regardless if they know about the various projects involved or not. Just by sheer luck, the booth was right in front of the line that lead up to the Pixar gifts, so people like Renderman TD's, visual effect supervisors, software developers and CG enthusiasts alike where asking questions. Christian explained to them the various projects related to Blender to Renderman as well as what they were doing and a LOT of them responding with a "WOW". Not only are they impressed with what they saw at the booth, they are very interested to see what will come in the next year.

More Morpho News and Blender for Dummies

2011-07-13T17:26:00.000+01:00

Earlier in the week an email was sent to me from Christian Vargas, the Animation Director at Morpho Animation Studios. Included was a set of pictures that had been taken of the book "Blender for Dummies", which many of us Blenderheads know had been written by Jason van Gumster.

Jason had asked Morpho Animation Studios to render some images for him so that these could be included in the book, since the studio does use Blender of course, however the difference is that again the rendering was not done with Blender, instead Pixar's Renderman was used. While the book did in fact list Morpho as the creator of the images the caption did not reveal how the image was rendered, until now.

Another little known fact and example of how RIBMosaic and Renderman is creeping into media and professional content creation.

Earlier in the year I had the pleasure of viewing the images by Morpho and sadly I had not known about their inclusion into Jason's book, let alone the fact that Jason was in close contact with Morpho Animation Studio. Just goes to show us all that in the Blender community we are all linked together and you never know just who knows who, somehow little surprises like this pop up and make you smile. Good job guys!

Morpho Animation Studio

2011-07-06T00:22:00.003+01:00

If there was ever proof that Blender and Renderman can produce real world imagery this would be it.

One little known studio in Costa Rica is making cartoons using Blender, which in the entire spectrum of small animation houses is not a big deal considering they would not be the first to do so. However the first they do have is that they are not using the internal renderer, instead they have opted to use Pixar's Renderman and are using RIBMosaic to do this. It is not a new thing either, they have been using these tools for well over a year and I have been in contact with them for some time. My relationship with this studio started with Daniel Salazar, also known as ZanQdo to the Blender community. He knows one of their employees, Christian Vargas, and told me about them during the middle of 2010, so I emailed him with an expressed interest in what they are doing. Since then some of us associated with Blender to Renderman have helped them out whenever they needed it and thus I decided to shed some light on this studio and what they are up to.

One thing to note though is that this studio is not just some small studio that is trying to break into the industry. While people in the USA or elsewhere may not be familiar with them, their work in the Central America region has been seen by millions. They have done TV ads in addition to other services and one commercial in particular is for Cartoon Network, which features 3D versions of Dexter, the PowderPuff girls and other CN icons. Other clients include Sony, Microsoft, Kraft and Subway. Are they established? I would say so.

Their first work in TV series using these tools is titled "Grandpa's Robot" which was directed by Christian. Due to NDA's I am not at the liberty to disclose anything sent to me, however from what I have seen has blown my mind, including stills from their next series in development.

"We have been working a lot lately. Right now we are really busy working for a videogame company in LA. We have been hired to develop 3d animated assets for a facebook flash based game. It includes creatures, cities, military units. Pretty fun stuff.

On the other hand we keep working on our properties "Grandpa's Robot" and "Poison Squad" We have been working a lot on this TV series with some writers from NY to polish the stories. This year we presented Grandpa's Robots at Kidscreen and it received good reviews from the audience. This year Gustavo is going to MipTv in France to present the TV series. Hopefully we will find somebody interested." Christian says.

Morpho does have a Vimeo account and here everyone can look and see exactly what it is I am talking about, such as a preview of "Grandpa's Robot" as well as other demo videos they have done.

Grandpa's Robot. Intro from Morpho Animation Studio on Vimeo.

Aqsis update leak : Point based GI ???

2011-05-16T22:05:00.002+01:00

As some of you may know, Aqsis has been undergoing some serious work and has been overshadowed at times by news about Blender, RIBMosaic and other open source projects. In a recent IRC developer meeting it has been revealed that the developmental and experimental branch of Aqsis has point based microbuffer rendering, which allows for ambient occlusion, radiosity and subsurface scattering. It was incorrectly assumed this was ray tracing, until that was cleared up. The catch is that since it is a new code update, it is slow and not meant for public consumption and won't be for some time. Chris Foster is the one that has been rebuilding Aqsis and adding the new core, as well as other major overhauls and graced the IRC chat with an image of Aqsis rendering a Cornell Box with point based indirect illumination.

Pretty sweet eh? Again this is NOT ready for any type of release yet, this is all experimental code that is subject to change at a moments notice, not to mention if pairing with production assets might just make Aqsis explode and create a black hole in the universe, you get the idea. The capability is there though which is a huge moment as this is a feature that many people have been asking the Aqsis team to add, so exciting times are in store as more is revealed.

As a side note, it truly is a very special time to be involved with the Blender to Renderman movement and community. In 2005 all the recent software upgrades that have happened were a dream.

Literally we are at that moment in time that most of us only dreamed of achieving. With Blender and RIBMosaic at a more stable state, we can safely say that this is the start of that breath of air, the awakening, that moment in time where things that where only a dream a few years ago, are now in front of us. Now Aqsis has kicked it up a notch, revealing an image that inspires us to continue. There have been many times that a few of us really had no idea if this was going to catch on, the whole Blender and Renderman pairing. The whole concept of it is hard to grasp since the workflow alone is alien to most Blender users, and Renderman users were a bit frustrated with the lack of this or that, things that are nearly built into Maya and Houdini. Over the past 2 years much of that time was spent rebuilding code from the ground up, making advances in pipeline construction and flow, getting involved with the Blender community as well as the professional Renderman community so communication could be established, the thousands of hours testing scene after scene.

Now here we are. Blender is more powerful than ever, RIBMosaic has evolved and Aqsis is capable of modern illumination methods at an embryonic state. Welcome to the new way.

Pixar announces ProServer 16, Weta adds Deep Image Compositing to OpenEXR

2011-05-10T17:27:00.002+01:00

Pixar released a press item on Monday May 9th, 2011 that Pro Server 16.0 is now available. What makes this version so important is because of the competition Renderman has faced in recent years, primarily the Arnold renderer and the fact that ray tracing in films is actually quite affordable now, in fact in some cases needed in order to really achieve the photo real look. Ray tracing in film is not new, in fact Pixar and ILM were the first houses that were able to do so, however these shots were few and far between. One of the first uses of ray tracing by Pixar was during a couple of shots in "A Bug's Life", then full use of ray tracing and global illumination in "Cars".

The problem is that while it is possible, ray tracing and global illumination is horribly expensive, long render times, huge load on the CPU and memory, requires baking the illumination similar to traditional shadow maps and in general slow to work with. Pixar's flagship product and grandfather of the REYES family tree has been considered slow compared to other renderer's like Arnold, VRay and MentalRay when it comes to ray tracing. This coincidently helped these competing products establishing a foothold on the VFX and animation industry as viable production renderers because of that very fact.

From the press release :

"This latest release features a large number of innovative advancements in RenderMan's ray tracing technology, including a new ray tracing hider, a radiosity cache, and physically plausible shading. These milestones allow RenderMan to take full advantage of the ever-increasing processing power of multi-core architectures, while also delivering the tools to implement these new features with efficiency and elegance. Moreover, RenderMan's new progressive ray tracing provides interactive re-rendering for production shading and lighting."

While nobody can prove otherwise, it remains a bit suspicious that Pixar added a new interactive re-rendering method, possibly similar to the Aqsis interactive re-rendering that was announced last year, possibly it is just great timing. It is still cool none the less. Aqsis still holds the title of being the first REYES renderer that can re-render at near real time on the CPU.

"RenderMan Pro Server 16.0 fulfills every need on our feature request list. It lets us focus on the customizations we really care about for ray tracing physically-correct lighting in the cleanest way possible," said Dan Evans, Head of Shaders at Framestore, London. "The speed of the new radiosity cache makes ray-traced global illumination practical in a single render pass, and we can now refine our test frames live using the new progressive ray tracing. Multi-bounce glossy specular, importance sampling, area shadows, and direct lighting are now a breeze thanks to the renderer supporting them all directly. Better still, regular ray tracing is staggeringly faster at 8X on some of our more complex stereo renders.”

Of course the products are commercial with ProServer 16.0 at $2,000 a seat, so this is beyond the price range of most of the population. A full price list can be found here if you want to check them out. This is one reason for this website's existence, much of the population that would be interested in Renderman simply cannot afford the software that these houses use, at best we get to use free limited use versions, so the importance of open source Renderman is very valid. While Aqsis still is not up to the level of features that PRMan does, it is far beyond just a hobbyist tool and as seen over the past couple of years, capable of producing film quality imagery.

Pixar always seems to kick it up a notch when it matters.

Weta also made recent news when it announced that it will be adding deep image compositing to OpenEXR, while at FMX 2011. More can be explained here at Colin Doncaster's website. Colin was the original developer of the Liquid plugin, a Maya to Renderman exporter that first saw use at Weta (see a pattern??). The Lord of The Ring's trilogy's visual effects were primarily accomplished via this tool for instance.

Animal Logic first produced a paper that described what deep image compositing is and what it is for, it was supposed to be at SIGGRAPH 2010 but was rejected. Why, nobody knows, SIGGRAPH paper judges are not known for their generosity. Since then several applications have had this added, such as Side FX's Houdini. Now OpenEXR will get another very useful addition that will allow other applications to take advantage of deep image compositing, so one could expect to see this in Blender as well as Aqsis in time, when this happens is uncertain and certainly not planned officially anywhere.

"The concept of a deep image isn’t brand new; ultimately it’s just the technique of encoding more than just the RGBA value in a pixel. Many applications and systems already store multiple channels of data to enhance the compositing workflow as well as re-using calculations already performed by the rendering engine. Side FX software’s Houdini is an example of one of the more recent applications to utilize this workflow via it’s custom camera image format.", from Colin's site.

Exciting times in all areas of visual effects and animation!

100 K Hits on BlenderToRenderman!

2011-05-08T20:41:00.000+01:00

Well sometime this weekend this website has finally broke the 100,000 visitor mark, somewhat of a surprise considering this is a niche market of the Blender community. Seems that over time we have gathered quite a following, honestly there was no expectation that this site would get that many visits at all, let alone in 3 years. While the number pales in comparison to other websites like the official Blender site, it is a great achievement for this site.

The site began as an idea in 2005, the whole concept of developing some kind of "community" for Blender and Renderman users. At the time I was involved with an indie film that was to use Blender as the animation package of choice, however at that time the scope of the film required some sophisticated rendering that Blender was just not capable of at that time in history. So the idea to use Renderman was introduced, the project began there simply because the ONLY script available was the Blenderman script. Ultimately my involvement with the film stopped, I started to go to school and working 40 hours a week really limited my time for other things.

Then I started a forum that was intended to be a community for this idea, it was hosted on some free forum site and started the movement that exists today. Temujin, the co-founder of this site, had gone from user to moderator and we developed a friendship. Sadly that forum was shut down, with no explanation as to why, we STILL have no idea why the forum was removed despite several emails to the company. So Temujin started to build the beginnings of what you see here.

In Jan of 2007 the site went live, as a sub domain of Blogger, the first post was on Jan 31, by Temujin. Since then the site has evolved, has changed designs, added things, removed things and eventually on October of 2007 bought the domain name. While this site is still hosted on Google's Blogger, the domain has changed things, made the site more official sounding and easier to remember than a long URL. At times people have purchased renewals of the domain, so each year someone else is the "co-owner", currently my girlfriend is that person, previous co-owners included Eric Back (Whiterabbit, the original developer of RIBMosaic).

So here we are nearly 4 years later, with over 100K hits under our belt, an average of over 300 hits per day, from people and companies all over the world. Some of the biggest names in the vfx and animation industry have visited this site, including Pixar, ILM, LucasArts, Disney, Blizzard and more. Countless colleges and universities have made hits. Even some companies from areas where we never imagined interest have come by, such as GM, Ford, Lucent, AT&T and even government agencies, like NSA, FBI and CIA have peeked a look. We even had a couple Echelon hits.

So today, on Mothers Day, this post goes out to MY mother, who had she not given birth to me, would have never given rise to this website, nor Project Widow and in all honesty you would not be reading this post at all. So thank you Mom, for bringing me into this world and changing even a small section of it forever.

Disney releases expression editor SeExpr as open source

2011-05-05T03:13:00.003+01:00

The studios just keep surprising us with more and more goodies. Just a day after LAIKA released SLIM templates, Disney releases an expression editor called SeExpr, a tool that can have uses in many areas of production.

"Arithmetic expressions appear in almost every animation system ever created. Being able to embed an expression language in a piece of custom software allows an amazing degree of artistic freedom. At Disney artists have enjoyed using expressions because they allow just enough flexibility without being overwhelming to non-programmer users. Developers have enjoyed them too for quick prototyping and deployment of fixes to production needs. SeExpr started as a language for our procedural geometry instancing tool, XGen. Work was done to generalize it into something that could be used in other contexts. Later it was integrated into paint3d, our texture painting facility, which opened the door to procedural synthesis. More recently, we have integrated it as a way of defining procedural controls to physical dynamical simulations and render time particle instancing."

"Expressions can be seen as a way of allowing customization of inner loops. This is contrast to scripting which is mostly aimed at glueing large parts of code base together. So in this sense, C++ forms the center of your application, python could be used to put pieces of it together, and SeExpr is used to customize tight inner loop."

As stated on the website the in house GUI at Disney is not being released, maybe it involves code that needs to be evaluated to be released under an open source license, it could be proprietary. Or they could just enjoy watching us squirm with anticipation, it is doubtful that it will ever be seen outside Disney though, either way Disney is understanding the power and reasoning for releasing production code to the public, adoption into other packages only helps spread it, just look at how fast Ptex was added to software, not to mention the other projects like PartIO, Munki and Resprado have quickly begun to collect followers and watchers. Who knows how many studios have adopted these projects into their own pipelines? While some of these projects may not be directly related to 3D production, their use in a pipeline can be invaluable.

Source Code at github
Documentation

Google Groups Discussion

LAIKA releases SLIM templates to the public

2011-05-03T17:47:00.005+01:00

LAIKA, the Portland, Oregon based animation studio, has released production SLIM templates on the Pixar website in an effort to help boost the Renderman Studio community. For those of you who do not know what SLIM is for, it is an application that is developed by Pixar to develop shaders, similar to how RIBMosaic makes "shader fragments" for Blender based off of RSL shaders made in a shader editor such as Shrimp, SLer and Shaderman. However SLIM is far more advanced and has been a staple in any pipeline that uses Maya and Pixar's Renderman.

SLIM templates are readily available on the internet, mainly released for free by Renderman users, however visual effects and animation studios keep these hidden away, just like any other asset in a production, so for LAIKA to release them to the public is a big deal.

You can grab these templates and example files at the Pixar Support Forum (free registration is required)

http://renderman.pixar.com/confluence/display/~laika/Home

LAIKA, Inc. is an animation company specializing in feature films, commercials, music videos, broadcast series, interactive content, broadcast graphics and short films. Owned by Nike co-founder and Chairman Philip H. Knight, the company is located in Portland, Oregon.

LAIKA has a 30-year animation history presenting the artistry of award-winning filmmakers, designers and animators. In addition to numerous international honors, the company has won two Academy Awards, 11 Emmy Awards, 11 Clio Awards, three London International Advertising and Design Awards, five Mobius Advertising Awards and two Cannes Lion International Advertising Festival awards.

New Blender to Renderman Wiki and other site news

2011-05-01T20:18:00.001+01:00

Just a short update on the site. The new wiki is in place, though much work has to be done in order for it to be viewed as somewhat complete.
The previous wiki was hosted on Wikidot, which provided a decent working environment, it was just not visually pleasing as the new one, which is hosted by Google's Sites now. Why Wikidot was chosen first before the Google Sites is still a mystery, this is changed now.

Other sites related to Blender have also undergone some visual changes, such as Graphicall.org, a site started by Daniel Salazar, a friend of Blender to Renderman community actually.

BlenderStorm also has undergone the same visual design treatment, as well as being an OpenID provider.

BlendSwap also has undergone some updates!

The Blender community is getting connected! Now the next step is for this site is to follow suit, see what happens.

Blender 2.57 Released! Fourth Generation of BtoR is near!

2011-04-16T20:25:00.003+01:00

http://www.blender.org/development/release-logs/blender-257/

At long last the first official stable Blender has been released since the refactoring began over two years ago. Many changes have been done to get to where Blender is now and of course more is yet to come, however this marks a milestone in the development of the next generation Blender to Renderman tool set. RIBMosaic has been worked on some more, with Jeff Doyle picking up the project and so far doing some fantastic work in getting the code to work with the new API, since the last version released by Eric was built before the recent API modification. I have not tried it myself yet but I would assume that as of right now a functional modern pipeline with Blender, RIBMosaic and Aqsis has been laid down, now it's just working on beefing up the features and the long road of bug fixes. Do not quote me on that though.

So this means that Blender to Renderman has evolved. This is not the first such occurrence though, in fact it would be in it's fourth generation now, at least since the turn of the century when Aqsis and Pixie were first released to the open source world. The first such generation was the Blenderman script, which functioned at a basic level but was not so useful for animation and was bug prone, however it did find use in film visual effects over in Spain, which so far has been the only known such instance of professional work using these tools. The next generation was the Neqsus script, which I still have a copy of and was so unique in it's design that it deserves to be respected to this day. It is the only known Blender to Renderman plugin that allowed Renderman previews of shaders to be displayed inside Blender itself. Neqsus had it's own GUI system seperate of Blender, which is how this was able to be accomplished. As with the previous generation this tool did not allow for animated exports, only still frames and after Blender 2.44 came out the plugin failed to work anymore. Bobby Parker, who wrote the Neqsus script, stopped working on it and pursued ventures elsewhere but remains active in the BtoR community. Of course the third generation was the first version of RIBMosaic, a huge milestone in the history of BtoR as it offered the most complete solution to get Blender data to Renderman format. This tool changed the playing field of the community, now we had a valid production worthy tool that was everything we could want, well almost. To achieve the level of intergration of Houdini or Renderman Studio for Maya was not possible, due to the restrictive PythonAPI at the time. It did however do everything else we wanted it to, we owe our entire existance on the web to this tool. I think without this tool Blender to Renderman would have died out years ago.

So now this is the fourth generation, Blender and RIBMosaic as well as Aqsis. Aqsis has become the strongest ally in this community, they are a devoted bunch of developers that have been very supportive of the whole Blender to Renderman idea, in fact the whole reason Project Widow started was because of them. Pixie has kind become stagnant in the area, where Aqsis has taken the role of leading the pack. While the feature set of Aqsis is not as complete as Pixie, 3Delight or even Pixar's Renderman, the developers have been working hard at getting there. On the other hand Aqsis has things going for it that none other can touch, for instance the Interactive Viewer of the prototype Aqsis 2.0 core, something not seen by any other RiSpec renderer so far. GPU relighting tools exist yes but the video demos done last year show just how fast Aqsis will be running on the CPU, which of course is where rendering for film takes place. GPU relighting tools emulate RSL code with GLSL code, they also use GPU rendering methods which are not the same as CPU rendering methods. Things like this make GPU relighting tools very handy but the Aqsis demos were rendered on the CPU in near real time, something the original engineers at Pixar had imagined possible long ago but knew it would be decades before it happened. Strange twist of fate though when it was an open source program that achieved this first rather than the inventors of Renderman.

Project Widow opened the doors to other areas of Blender to Renderman that had not been in the original equation. Areas like compositing, project management, collaboration tools, software development and pipeline design. In the beginning of BtoR it was all about how to translate Blender data to Renderman data. Step by step this was figured out. Then it was how to animate it, that too was figured out in the third generation. Technical direction found the need to get AOV in OpenEXR, only multilayered so that it could be imported back into Blender for post processing in the same manner that it does with it's own rendered frames. This lead to the development of shader tools that would generate complex shaders that literally would plug into the pipeline without problem, which in turn would lead to the capability of AOV rendering and compositing. Project Widow really opened up the need to see the pipeline as a whole rather than a section of it, simply because a lot of it really depends on each other. These are the things the animation and visual effects studios don't tell you, the little details like that which make production easier to maintain, instead they just say "We have these set of tools that are custom built to make our jobs easier"... but they don't go into detail as to WHY, much less HOW. These are known as "trade secrets". Project Widow is not professional by any means but the production is an open one, in fact tools and tutorials on how to do everything else BUT export Blender to Renderman data has been written. As mentioned before that was figured out long ago.

So now in the fourth generation, everything has been rewritten from the ground up; Blender, RIBMosaic and soon Aqsis. This website will also undergo that process. As things change so do we and plans are in the works to change this site again. When this will happen is uncertain, though in some areas it already has begun. Facebook has replaced Myspace in the "social networking" area of www.blendertorenderman.org, Myspace seems to be lacking in areas such as point of existance but whatever Facebook certainly has proven to be worth the effort. The Project Widow Twitter account has been slightly useful, sending out impromptu screenshots or WIP renders for the sake of doing it with no regard to the fact if anyone would be interested, however it seems to be doing a decent job since it attracts more and more followers. There is no cohesion though between areas, such as the outdated and incomplete wiki, the groups... so on and so forth. Project Widow has taken up a considerable amount of time to complete which means in other areas, such as this site, things are not as complete as I want them. It happens. I just keep looking at the stats though, we are nearing the 100,000 visit and that is impressive for something that started as a small idea in 2005 after one ambitious young man had a movie idea and asked me to try to use Blender as the vfx tool of choice. Now several animation studios have made visits, motor companies, computer companies and countless universities worldwide. We have passed the point of crawling but we are only just beginning to stand. There is much more to do.

ILM open sources GPU based relighting tool

2011-04-01T16:03:00.003+01:00

An industry insider has reported to certain people that ILM is putting a GPU based re-lighting tool into the open source world, a tool that has been used on many films by ILM technical directors and has been kept a secret for the better half of the decade. However ILM has already built a new engine that is based on REYES and GPU re-lighting code that had been part open source and part science research, so this leads to wonder if they are borrowing existing open source code and heavily modifying it.

This old engine is based off of technology that existed around the turn of the century and while it still functions very well in modern pipelines, the code is old and ported from old SGI libraries. The new tools currently in development are built from modern libraries for Linux, thus removing the chains of legacy obsolete code. ILM is presenting this code to the world mainly for the hell of it, they no longer feel that there are any secrets worth keeping. While the code may be functional, the fact remains is that it is obsolete and much of the pipeline is lightyears ahead of what had been created even a decade ago.

More information as to the location of this tool will be revealed soon.

RIBMosaic Updates

2011-02-27T16:00:00.002Z

As mentioned in November last year, RIBMosaic has been placed into the Aqsis repository after Eric stopped his development on the addon. The intent was to allow anyone else to join the project and continue working on it. Several hands went up into the air on this one, including myself until I actually tried to dissect the code and realized that my programming skills do not match up. To complicate things the Blender API has been changing quite often which caused RIBMosaic to break and cease functioning after a certain revision, which of course has not been a recent one. At the same time the work done on Project Widow reverted back to Blender 2.49b until a time when it is possible to use the new software, we really wanted to stress test the newer code, however the stability of RIBMosaic prevented this from happening.

Recently there has been some work done to RIBMosaic, not by the Aqsis development team but by someone who has been a user of RIBMosaic since the early days, he simply wanted to see it live on. NFZ (Jeff Doyle) has provided some patches to the Aqsis git repository that will make RIBMosaic function in recent Blender 2.5x revisions.

http://community.aqsis.org/2011/02/ribmosaic-developement-blender-25.html

"So does the patched RibMosic work with the latest official Beta release of Blender 2.56a? No. A recent Build with svn rev 35000 or greater is needed. Blender svn trunk revision number is around 35100 as of 22 Feb 2011. The Blender python API is still going through a lot of changes so its easier to keep up with the changes rather than focus on a previous release. Not good for users since they would have to get an up to date build of Blender every few days but until the API stabilizes that is the way its going to be :). http://www.graphicall.org/builds/ has daily builds for most OS so for those that want to play that is a good route."

http://sourceforge.net/tracker/?func=detail&aid=3191328&group_id=25264&atid=383972

The link to the patch itself.

This certainly is good news to hear!

Matt Ebb improves Blender to 3Delight

2011-02-08T14:45:00.000Z

http://mke3.net/3delightblender/

Matt Ebb has continued to work on his 3Delight export script, which had been mentioned before last year as one of the newest Renderman addons that has popped into the Blender community.

Since RIBMosaic is in the process of being developed under a new team and is intended to be used for Aqsis, Matt's addon is geared more for 3Delight, a commercial Renderman compliant renderer that has been used in several big budget films and one of the most popular RiSpec renderers next to Pixar's commercial products.

From his site :

Supported Features

3D motion blur with sub-frame samples
3D depth of field blur
Integrated render result (appears in Blender compositor)
Polygon/subd mesh geometry, linked group instances, parametric primitives, particles as points or hair strand curves
Adjust shader parameters in Blender UI
Write and compile shaders in Blender text editor
Automatically converts texture maps to 3delight’s optimised tiled TIFF format
Simple global illumination light shaders built in
Automatically generated shadow maps, raytraced shadows

Download v0.5

Requires a Blender svn build > r34664

Installation

Unpack and move the render_3delight folder into your blender addons folder. You can then enable the addon in the Addons tab of blender user preferences.

08 Feb: Due to a change in recent versions of 3Delight installation, this only works if you start Blender from the command line. I’m investigating a fix now.

License

This software is free software and licensed under the MIT license – basically you can do what you want with it, though credit would be nice. If you’d like to show appreciation, please consider donating to a secular charity of your choice.
This exporter is not endorsed by or affiliated with DNA Research.

Merry Christmas! A gift from us... to you.

2010-12-26T02:44:00.004Z

Well it is that time of the year and this year I decided to release the Widow Pipeline as a present to the Blender and Renderman communities. Yes it is true you can get these all on the sites themselves, however some tools are not so well known. So now everyone can use the same tools we are using for the short film "The 10:15" (aka Project Widow).

Widow Pipeline I for Linux tar archive

(of course this was not without it's own technical problems.... torrents did not work, now just a single tar archive.... sigh)

This release is built for Linux, since much of the team uses that operating system, also some of the tools are built for Linux and would require some work to get them to build on Windows or Mac OS. Shrimp for instance is modified specifically for this short, WidowShade was a heavily modified version of ShaderLink, something that took close to several months to complete before Shrimp was brought into the pipeline.

This release is similar in fashion to the BRAT release in 2009, however the difference in the release is that where BRAT was meant for a more general installation on multiple operating systems, with a wide variety of tools and example files, this release is more specific and designed to fulfill a specific role : to be the basis of an open source production pipeline. This release is also using older tools rather than bleeding edge, simply because of stability and the fact that at the time of this writing there is still much to develop to get a stable pipeline using Blender 2.5x and RIBMosaic.This is the result of over a year of work developing a stable pipeline so that “Project Widow” could be completed and the hope is that people will be able to use this as a starting point for their own projects, or using this to learn Renderman with Blender.

Artist Tools

Aqsis
Blender 2.49b (both 32 and 64 bit)
RIBMosaic
DJV
Ramen
Cinepaint
Shrimp (Widow build)
WidowShade

Blender Scripts and files

Conspot
RIB_Lib Database (blend file with entire RSL LIB for linking)

Shaders

Entire shader collection used for “Project Widow” (as of Sep 2010)
Surface, Displacement, Imager, Volume, Light and Diagnostic shaders

Pipeline Tools

Shotgun API 3
WVTU (Widow Version Thumbnail Uploader)
WidVerTU 0.3 (dev version of GUI WVTU)
Postmosaic
BlenderAid
DrQueue

Libraries

RSL Lib 0.1
OpenColorIO 0.6.1 (Sony Imageworks color management library)

There is also something to find in this torrent. It's your present. It is a pretty complete collection of pre-production images, as well as R+D renders and test beauty shots. There are also some screw up images, some test blend files, as well as older images from the past to show just how much has changed in the past 5 years.

There is also the BlenderCon 2010 technical paper that I wrote, considering that this very pipeline is the one described in the paper.

Now to get back to the StarWars marathon on SpikeTV.

Merry Christmas!

RIBMosaic : Now part of Aqsis

2010-12-08T07:26:00.002Z

HUH!?!?!

I am sure some of you are thinking this. Yes, it is true. RIBMosaic is now a part of the Aqsis project and the current official "home" of the new add on.

The back story goes like this. Eric Back emailed a certain select few last month (around the time of the last post here) and told us that he would no longer be developing the recoded Blender plugin. He was "orphaning" the code as it was on Sourceforge and anyone could come and pick it up. Knowing that RIBMosaic was important for Aqsis it was decided that the developers would adopt the code as it last was and continue development with the intention to bring Aqsis closer to Blender.

From the developer mailing list :

Eric has given his agreement that this should be the 'home' of RIB Mosaic now, and understands that we will focus on the integration of Aqsis specifically into Blender, while endeavouring to ensure that nothing we do will intentionally preclude support for other compliant renderers. We as a team will probably not be able to focus any effort on supporting other compliant renderers, beyond possibly testing regularly to ensure that existing functionality still works. Of course, we will assist and encourage anyone who wants to work on support for other renderers should they wish to do so within its new project space.

Cheers

Paul

In a way this would be a "RIBMosaic for Aqsis", while other developers could make a RIBMosaic for say 3Delight, or AIR or even PRMan.

So now RIBMosaic is now a part of Aqsis and will be packaged with the renderer from now on. A lot still has to be completed and there has to be some serious testing done in order to accomplish this in a timely manner. In order for Project Widow to continue, the tools need to be upgraded as well, it was bound to happen and now is the time.

http://sourceforge.net/apps/mediawiki/ribmosaic

Thank you Eric for bringing this idea to full steam, without your efforts and help it's hard to imagine being this far by now.

Pixar and Microsoft - Cloud rendering with Azure

2010-11-07T17:30:00.001Z

http://blog.seattlepi.com/microsoft/archives/226427.asp

This is a little late news overshadowed by the Blender Conference this year but this is a bit of interesting news. Pixar and Micorsoft have paired up, with Renderman being shown as a proof of concept for Microsofts cloud computing service "Azure". This is the first time an RiSpec renderer has been used in such an environment, which is actually pretty tough to do since there are usually quite a bit of assets and files required to render any given frame as opposed to say Blender or Maya files which are usually a single file with all information needed to render.

For instance BURP and Renderfarm.fi are possible because Blender animation projects can be packed into a single file, these files can be distributed across the internet to multiple computer slaves, rendered and the images sent back to a single folder of multiple frames.

Renderman it is a bit different, shaders, image maps, RIB archives, even header files and any other on the fly processed imagery, brick maps or point clouds can be scattered across multiple file paths, even with relative file paths things can be lost if you are not carefull. The amount of exported files is quite large, often reqching into the thousands and the more data per frame that number just increases, shadow map passes alone can reach into the tens of thousands depending on the amount of frames and lights. This makes it very difficult to use distributed rendering across the internet using Renderman.

Another factor that makes distributed rendering unfavorable compared to a renderfarm is CPU architecture. The differences in the various types of processors will alter the output of procedural texturing because of the way the shader is compiled, the subtle changes in fractal pattern generation or noise, turbulence, anything that generates a procedural pattern. In other words an image rendered with Aqsis on an AMD64 Dual Core CPU will be slightly different than a render of the same file with Aqsis on a SPARC or MIPS processor. The difference will not really be noticable on still frames, even side by side the image can appear to be the same, however when the frames are going at 30 fps, these differences will be seen and the patterns will appear to flicker over time. This is why renderfarms are usually composed of identical hardware and at the very least the same type of CPU, this eliminates the worry of those artifacts.

However it is not impossible and if anyone can prove it, it's Pixar and they did.

Pixar took to the stage at the Professional Developers Conference 2010 to demonstrate this now potentially powerful ability to reduce the overhead cost of hardware and energy supply and instead using remote rendering. Cloud computing is considered the future of computing, whether it happens or not is anyones guess but in many instances where number crunching at a massive scale is needed, cloud computing could be one of the best options available to smaller studios that can't afford to spend the very large amount of money to build an effective renderfarm. Spending a fraction of that using cloud computing services is favorable in that sense, so it is a very welcome sight to see that it is possible with Renderman.

As you can see here, the payoff is incredible.

So this can open up new doors for some on what can be done with Renderman. In the past, I myself have argued that cloud computing is not really practical when using something like Aqsis to render, however with Blender, Maya 3DSMax and so on, it actually is favorable if the ability is there. I admit that I did not research fully into the subject, now I have and my opinion has changed.

Of course this is Pixar's work so there a large degree of engineering involved, this is not just a bunch of college kids doing this for a project or hopes of making it big. To do that yourself would require a bit of work, programming and patience, however this news of Renderman : Azure is really a nice breath of fresh air, gives us hope and inspiration to replicate it ourselves. While it may actually require investing money into the service, be it Azure, Google or Amazon, in the end it may end up be more cost effective than building your own renderfarm. On demand rendering services are on the rise.

It is funny though, since Pixar was owned by Steve Jobs, that Microsoft was used to demonstrate this. Also proving to the visual effects world that Microsoft is not as useless in the number crunching arena as it once was.

Aqsis new core prototype, interactive viewer!

2010-11-01T03:39:00.006Z

So here it is - words cannot describe what you are about to see, you have to watch this for yourselves.

From the Aqsis development blog :

"This blog has been pretty quiet for a while, but aqsis development has been coming along behind the scenes. During the aqsis-1.6 development last year I focussed a lot on making aqsis faster. After working on this for a while it became obvious that some major changes were needed for the code to be really fast. In particular, the aqsis sampler code is geared toward dealing with single micropolygons at a time, but it seems better for the unit of allocation and sampling to be the micropolygon grid as a whole. This was just one of several far-reaching code changes and cleanups which seemed like a good idea, so we decided that the time was right for a rewrite of the renderer core. Broadly speaking, the goals are the following:

* Speed. Simple operations should be fast, while complex operations should be possible. The presence of advanced features shouldn't cause undue slowdowns when they are disabled.
* Quality. Speed is good, but not at the cost of quality. Any speed/quality trade offs should be under user control, and default settings should avoid damaging quality in typical use cases.
* Simplicity. This is about the code - the old code has a lot of accumulated wisdom, but in many places it's complex and hard to follow. Hopefully hindsight will lead us toward a simpler implementation.

Fast forward to the better part of a year later - development has been steady and we've finally got something we think is worth showing. With Leon heading off to the Blender conference, I thought an interactive demo might even be doable and as a result I'm proud to present the following screencast.

There's several important features that I've yet to implement, including such basic things as transparency, but as the TODO file in the git repository indicates, I'm getting there. The next feature on the list is to fix depth of field and motion blur sampling which were temporarily disabled when implementing bucket rendering.

Edit: I realized I should have acknowledged Sascha Fricke for his blender-2.5 to RenderMan exporter script which was used by Paul Gregory in exporting the last example from blender. Thanks guys!"
Posted by Chris Foster

"Just to clarify, this is not a demonstration of an interactive viewer for RIB editing. This is the newly under development main core. So, what you’re seeing there is the actual renderer, rendering microplygons (Reyes) at 40 fps. We’re just displaying it in an interactive framebuffer, rather than bucket at a time, to show how fast it really is. It’s not using GPU, purely CPU, exactly what you’ll get when you render with Aqsis.
I should also point out that it’s not complete yet, this is the first demonstrable stage of the core re-engineer, there’s more still to go in before it’s even up to current Aqsis feature levels, but rest assured, when it’s finished, this is going to be fast."

~ Paul Gregory

BlenderCon2010 "We have such sights to show you..."

2010-10-27T07:28:00.000+01:00

All rights are reserved by Clive Barker and/or Bent Dress Productions.

The Aqsis team has been very hard at work giving the renderer a reboot of sorts, with the building of the new core and all, of which has not really been seen in the public eye.......until now. Well, almost.

Leon Atkinson (Renderguy) will be at BlenderCon this year and will be showing off some of the latest exciting developments. Yes, showing it off on screen for everyone to witness because there is no way to fully explain the details in words, the Aqsis team reports a demo for the conference is under development, it is being prepared specifically for BlenderCon to announce the new plans for Aqsis and to show how beneficial they could be to Blender users.

The very core of Aqsis is being re-engineered with a focus on speed, it is at the prototype stage now, but is functional enough to form the basis of the BCon demo. There also will be interface changes, the migration away from FLTK to QT4 for instance, which is actually pretty neat since a lot of the pipeline tools are already in QT4 as well, or in the process of switching. Other changes like multithreading for instance are a very recent addition to the new core.

They are preparing a more detailed press release for after the conference, so keep your eyes open for that. If anyone happens to be at BlenderCon and able to record a video if you could let us know so we can post it here.

This also coincides with a point release, Aqsis 1.6.1 which will mainly be a bug fix release

Some of the rumors going around the underworld is that Larry Gritz is trying to get Ptex implemented into OIIO (Open Image Input Output), which Chris Foster has expressed great interest in using for Aqsis, thus Aqsis would get Ptex for free. That won't be until later though, possibly in version 1.8 or the fabled Aqsis 2.0.

Piece by piece the developers are building up towards a very powerful rendering application.

On the other end of the conference spectrum is the paper "Blender to Renderman : Building a Pipeline for Production Use" written by myself. I had originally been planned for a speaker spot, however due to complications I had to back out and asked Ton if submitting a paper would be ok since the topic was pretty much the same (possibly even worded better on paper than with spoken word haha) so...... my first publication of sorts and it is appearing on this years BlenderCon page.

Strangely enough is that this year's Halloween is also during BlenderCon, so one can only imagine what will go on during the weekend, wouldn't it be cool to see the BlenderCon attendees dressed up as zombies and walk the streets of Amsterdam?

Sintel now available

2010-09-30T20:23:00.001+01:00

Congrats to the Blender Foundation! I have been awaiting this film for quite some time, even had the chance to chat every now and then with some of the guys. During the course of their production those of us working on "Project Widow" took note of some of the methods the BF had done, in particular Blender-Aid, so in a way Sintel has been a good source of reference and information, even in such cases as the modeling sprint, used some of the models for testing with Renderman. In such case aside from the texture format change was pretty solid export, even from 2.49. Nathan in particular has been a real joy to chat with, spending time in the Aqsis chat room and in one such case showed Paul Gregory and I a video preview of his basic exporter using a rigged Sintel model. Of course there has been a lot of behind the scenes talks between developers about the RenderAPI, something that we have been encouraging for some time now.

I guess it is kind of strange that a few of us have had a small connection to this film, strange but cool at the same time.

Grats guys! I enjoyed it greatly!

http://www.blendernation.com/2010/09/30/sintel-now-available-for-download/

RIBMosaic GUI update

2010-08-09T20:02:00.001+01:00

By popular demand, Eric Back (Whiterabbit) has posted a very detailed update about his development on the next generation of RIBMosaic.

What's done...
- all permanent panels in the UI are complete
- the pipeline manager and pipeline driven UI panels are working
- the pipeline link system is complete (these are like tokens in the old mosaic but can now connect almost anything and be used anywhere)
- the translating of slmeta shader files to pipeline panels is working (this converts K3D shader xml files to panels in Blender's interface)
- the core of the export manager is working and export of command scripts is just finished

A lot of this is pulled from the message that Eric posted....

Description from left to right:
- The first window is the render properties window showing the RenderMan Passes and Export Options panels. Of note is the partially visible link command in the Output property "Renders/@[EVA:.current_frame:####]@@[EVA:.pass_layer:]@.tif". These links pass information from the exporter directly into that string and can used in any text field. They can also pass values from buttons from the UI directly into code in pipelines allowing designers to build their own interfaces and pass the selections directly into RIB, RSL or embedded Python code.

- The second window is the render properties window showing the Pipeline Manager panel and a example user pipeline panel called "AQSIS - Layered Display". The Pipeline Manager panel is available in all properties windows and allows you to load and remove pipeline files as well as manage their content. Pipelines are XML files containing descriptions of UI panels with RIB, RSL, Python or shell script associated to them. The idea is a pipeline designer would build any panels they need along with the underlying RIB and shaders to provide a complete rendering pipeline for specific features (such as Aqsis's layered EXR display). The artists simply load the pipeline to add the functionality they want.
The example panel shown is a test using every control RIBMOSAIC supports and is completely designed and drawn from XML. All controls are connected to Blender properties so they can be animated. The buttons can trigger pipeline scripts and show message popups (letting you give the user feedback). There is also a file browser button to quickly putting file path in text fields.

- The third window is the scene properties window showing the Export Options panel. These panels are also available in almost all properties windows and show options relevant to where they are. In this case the scene export options have low level control over things like export path, search paths and global archive options. Also note the export path is also using links with Python eval expressions (to let the user do fancy things like make the export folder use the name of the blend or scene). Also worth noting is the pipeline manager is showing different categories and the panels loaded at the bottom are using different icons in the left corner. Pipelines can create three types of panels "Utility", "Shader" and "Command" each showing in a different category list in the pipeline manager and each with their own icon. Utility panels will be for adding RenderMan features to the UI and internally generate RIB code on the datablock they are on. Shader panels represent shaders and are created from slmeta files and also internally generate RIB code on the datablock they are on. Command panels represent shell scripts and contain code that's executed on the command line. This is an interesting feature as it puts complete control in the hands of the pipeline designer allowing them to do cool things like call renderfarm managers through MOSAIC.

- The fourth window is the material properties window and shows another Export Options and a shader panel. You'll notice several of Blender's standard material controls have been placed in the export options. The only controls that are kept from Blender's render pipeline are ones that are directly export, interact with Blender's 3D view or can be useful to passing to RenderMan in some way. The AQSIS - k3d_greenmarble panel was completely generated from a slmeta file (these will soon be created by MOSAIC but also by k3d and shrimp shader editor). Like everywhere else all controls can be animated. The little buttons with the chain icon can be used to "link" the Blender data path from another control to this shader parameter. In Blender you can right click on any control and copy its data path then paste that value as a link in MOSAIC. This lets you link the value from any control in the same window to that parameter, for instance linking Blender's lamp "Energy" to a light shader's intensity parameter. Data path links can also contain math or even eval expressions to manipulate the value under artist control (no need to code).

- The fifth window is the object properties window. The only thing to note here is the export options has CSG controls. RIBMOSAIC's new exporter will support parent/child archive structures so it will use this to handle CSG. For instance you may set a parent to "Union" and then all children will be joined together, then make some sub children "Intersection" and cut those children out of the union, ect. Also I've already setup motion blur to support sub-frames although this hasn't been added to the API yet, hopefully it will by the time I'm coding it.

- The sixth window is the objectdata properties window. In the export options notice a select for primitive type. This will let the user manually specify a primitive type depending on the underlying data type. For instance if on a mesh then a user can specify PointsPolygons, SubdivisionMesh, Curves or Points. If auto select then mosaic will attempt to guess (such as exporting a Subd if a Subd modifier is on the object or points if halos is enabled, ect). Also the user will have control over exported primitive variables and I plan to make pipeline for users to add even more. Lastly Levels of detail will allow users to specify different datablocks for levels based on distance.

This last shot is showing a "hard coded" test rib rendering (since it can't export scene's yet)...

In the top left background is the XML code for the loaded pipeline in Blender's text editor. The top right is showing the current console output. The bottom left is showing Aqsis's framebuffer output. The bottom right is showing Blender's render result automatically using the render from Aqsis.

This is exciting news and a lot of people have been patiently waiting for some news over the past 8 months. Plus with screenshots even so we can drool over our keyboards.

Well done Eric!

Ptex support added to Blender!

2010-08-05T18:05:00.002+01:00

This is a brand new commit to the Blender 2.5x code actually, something that has not been formally announced nor has it been fully worked out in functionality and there is probably bugs and needed optimizations ....

This is ptex, of course. The implementation isn't complete, but here's what working for now:

Per-face ptex resolution. Each face gets a U resolution and a V resolution based on its area (relative to other faces) and how stretched it is (i.e. a thin tall face should have a lower U resolution and a higher V resolution.)
Automatic generation of ptexes. This step is somewhat analogous to unwrapping your mesh, except instead of choosing UV coordinates, it's setting the default ptex resolution for each face. There's a UI control for texel density.
"Vertex" painting. That's a bit of a misnomer now, of course, but you can paint more or less normally. (Naturally I've broken some vpaint features like Blur in the process, but it'll all be restored.)

Note: ptex is designed mainly to work on quads. Triangles and other faces are split up into quads in the same manor as Catmull-Clark. I've coded it so that both quads and tris work (although there are some mapping issues with vpaint still), however quads are the "fast case"; for this reason I've applied one level of subsurf to Suzanne in this example.

A partial TODO list:

Add UI for setting individual faces' resolutions
Integrate the open source ptex library for loading and saving ptex files
Add upsampling/downsampling so that changes aren't lost when changing ptex resolution
Change default ptex to a flat color. The random noise is just for testing, of course :)

http://vimeo.com/13859283

Very very cool to hear! Congrats to the Blender devs for adding this, now all that is needed is more render engines to support Ptex as well, I would imagine within the year this will be a sweeping motion to impelment this across the spectrum of graphics programming.

ILM and Sony Imageworks release Alembic OSS

2010-07-28T17:09:00.001+01:00

"Alembic is an open computer graphics interchange framework. Alembic distills complex, animated, scenes into non-procedural, application-independent, baked geometric results. This distillation of scenes into baked geometry is exactly analogous to the distillation of lighting and rendering scenes into rendered image data.

Alembic is focused on efficiently storing the computed results of complex procedural geometric constructions. It is very specifically NOT concerned with storing the complex dependency graph of procedural tools used to create the computed results. For example, Alembic will efficiently store the animated vertex positions and animated transforms that result from an arbitrarily complex animation and simulation process,  one which could involve enveloping, corrective shapes, volume-preserving simulations, cloth and flesh simulations, and so on. Alembic will not attempt to store a representation of the network of computations (rigs, basically) which were required to produce the final, animated vertex positions and animated transforms. "   

http://code.google.com/p/alembic/

- quoted from the Google code project page

ILM and Imageworks truly are our best friends in the proffesional visual effects industry. From what is posted this is intended to bake this data into a format that can be read later on down the pipeline, such as cloth simulation into a single baked file rather than thousands of small files of cloth sim data, such as the case with Blender. Or bake an animated character that will be later used for cloth simulations. Then using the same format can take these scenes and bake it to be used later for lighting and rendering. There are limits though, it cannot store network representations, such as bone rigs and it is not meant to replace native scene files for applications. It is another bake format that is intended to smooth out pipeline issues, like file formats between applications, which has been an issue in the 3D industry for as long as it has been around. Trying to get Maya files into Blender is a pain and usually involves exporting an object into the .OBJ format, which cannot store animation data, so having the ability to bake animated scenes that can be read in another application is a HUGE leap! Imagine the ability to use Maya scenes in Blender, then rendering in 3Delight, or for instance, modeling something in Blender, animating it in Maya, use RealFlow to make a fluid simulation, then render it in Pixie.

While it is too early to say where this will go, who will adapt it and how long it will take, I can say that the idea is great and hope to see this evolve. Remember, in less than 5 years OpenEXR went from a small user base to be included by default on most Linux distros and 3D applications, both open source and commercial as well as proprietary in house tools.

Aqsis Licensing Changes to BSD

2010-07-25T01:48:00.001+01:00

Aqsis Licensing Changes

As of 25th July 2010, the Aqsis project intends to move towards re-licensing under the BSD license (http://www.opensource.org/licenses/bsd-license.php). All new code contributed by any authorised developer must, by agreement of the developer, be licensed under the BSD license. Existing code will remain under the current GPL/LGPL combination in the short term, while efforts are made to obtain agreement to re-license under the BSD license. Where agreement is not forthcoming, the code in question will be removed from the project, and be replaced with new implementation, written in isolation and licensed under the BSD license. The intention is to ultimately provide the whole of Aqsis under the BSD license.

As reproduced from the mailing list.

Blender 2.5x RenderMan Export News

2010-07-20T05:49:00.001+01:00

It has been some time since there was anything written, sorry for the lack of activity, my personal life has taken some unexpected twists and turns, for the better of course.

Now for the news!!

Blender 2.5x now has the ability to export to RIB! Actually Blender has been able to do this for some time, it just has not been mature enough to really say anything about it. However this is not Eric Beck's RIBMosaic, this seems to be a simpler script similar in tune to the old Blenderman script, just with a lot more functionality. I have not had a chance to test run anything on Blender 2.5x, simply because the Project Widow pipeline is for 2.49 so in order for us to continue to work on this we need to keep the old production stable version. Thus the only information I have is already seen on the Blenderartists site here : http://blenderartists.org/forum/showthread.php?t=187969&highlight=renderman

"Frigge" as he has been known as in the forums, made this as an exercise into deeper technical stuff, as mentioned in the forums, so this script is not to be considered something for large productions. It does seem to be the perfect tool for someone who does not know much about Renderman but is curious to know how it works. That's how I started, my first taste of Renderman came from a Lightwave plugin and 3Delight back in 2003. So if you are not a shader and rendering wizard you might find this useful, at the very least informative and IT WORKS.

Back in Feb I had been talking a lot with Nathan of the Durian team and at one point in time he had made a basic export script for Renderman as well. It is kind of funny that he has done this considering that about 7 years ago he ranted about how much he hated Renderman shaders, I did some digging and had found this post form that time : http://www.blender.org/forum/viewtopic.php?t=1497&start=30, I just hope he does not kill me when he reads this, heh. I did have the source for it at one point but it got lost so I am unable to provide anything in terms of how it functions or what it looks like, though at the time he did do a simple 60 frame animation of the main character model using this script to export and me when he Aqsis to render it out. Again that too is lost in the abyss of the hard drive recycle bin (I was being stupid and did not realize that files and folders I deleted months ago were there). Nathan then became very busy with Sintel shortly afterwards so I left him alone to complete the film. He did say that once Sintel is over he wants to become more involved in the Blender to Renderman project so we are excited to have his presence here.

Matt Ebb also has been experimenting with a Blender 2.5 Renderman export script.

This script is also a sort of personal pet project for him and no code seems to be available at the moment, however from the screenshot he posted it looks good enough for people to play around with and learn more of what Renderman is and how it works rather than a full on production capable plugin like RIBMosaic, which of course can be daunting to grasp at first for someone who has never used a RiSpec renderer.

http://mke3.net/weblog/3delight-renderman-in-blender/

Finally Eric has informed me that the GUI portion of the new RIBMosaic script is done, cannot wait to see some screenshots!!

The point of this is that Renderman usage with Blender is gathering steam, more people are interested in it and there is some good effort from all over the Blender community, from the smaller basic scripts to the complex. This is a good thing, even in this little niche of the Blender community we have options and that is the whole goal of this : OPTIONS. There was a recent thread on Blenderartists, one that asks "Should the Blender Internal Engine be retired?" and in my honest opinion it should NOT. Why? Well not only has Ton put a LOT of time and work into that renderer but why should it be retired at all? Every 3D animation package has some sort of rendering engine and while each may not be able to x or y rendering capability, you are still able to render out an animation sequence. Yes Maya's internal engine cannot hold a candle to MentalRay or PRMan but it is still functional and with enough effort can produce some good results. We started this site for a single purpose, to have the OPTION to use an RiSpec rendering engine, not to replace the internal engine. We know for a fact that not everyone is interested in rendering, they are called character animators, or modelers. While they may prefer this renderer over another for whatever reason, they have the desire to create the model or animate it. Why should they have to be forced to learn a new rendering system when they are comfortable with the one supplied? Of course not everyone is like this, I just used that as a single example however the point is to not take out the internal renderer of ANY application that is intended to be used for animation. That would be software suicide.

Ptex and the Open Source Community

2010-04-21T14:46:00.018+01:00

Figure 1: T. Rex with 2694 faces rendered with Ptex. (©Walt Disney Animation Studios)

I decided today to write an article on Ptex, the texture map library that Disney developed and recently released as open source. While this is not fresh news by any means, since it's official release early this year there have been some development in both the commercial and open source worlds.

One of the first applications that support Ptex is naturally Pixar's RenderMan 15.0. After the announcement by Disney in Jan. 3D-Coat was one of the first smaller 3D applications that implimented it within a week, which of course brings to mind that infamous set of images found in the forums.

One of the more interesting images was the texture map itself which looks unlike any map I have ever seen.

The original forum thread can be found here : http://www.3d-coat.com/forum/index.php?showtopic=4834&st=0

However in the open source world it has not caught on quite as fast as expected, in fact to date none of the software in the Blender to Renderman pipeline support Ptex. This is not because of the lack of interest, it is more or less due to development targets. Simply put both Blender and Aqsis are in the process of major rewrites so to implement Ptex into these at this time would divert attention from the important targets in these applications.

Aqsis 1.8.0

Blender 2.5

Does this mean that Ptex will never see the light of day in the open source world? No. In fact if you recall it took some time before OpenEXR was added to Blender, Aqsis and Pixie so while the technology is there currently, it may be some time before it is added across the board. This is not due to developer laziness or as mentioned before, lack of interest (because there is an interest in it from the Aqsis team), it is simply there are more important things to worry about in each application such as functionality, stability and speed.

But all is not lost and it seems that some people have been using workarounds to accomplish usage of Ptex with applications that do not support Ptex, such as Blender.

CG Society Article

Recently there have been some usefull code that has popped up that not only will benefit Aqsis but Blender as well. For instance OpenImageIO (OIIO), which if combined with Ptex and supported in Blender and Aqsis would be something that can be very usefull. OpenImageIO was developed by none other than Larry Gritz, possibly one of the most important figures in the CG industry, from BMRT and Entropy, to the work he did at Nvidia with Gelato. So not only is OpenImageIO a powerfull imaging library but it's also one of Larry's greatest contributions to the open source community.

The /*Jupiter Jazz*/ group has also provided a usefull file cache library called "JupiterFileCache", of which at render time could improve file access speeds, the files can be texture maps, point clouds or other large files to reduce network traffic and disk use. Combined with the OpenImageI/O and Ptex libraries could be a useful benefit for everyone.

The Blender to Renderman project is aware that these recent contributions could have a massive impact on the open source CG industry, so I have a proposal to ALL the developers in these areas : Let's get together and at least come to a common goal to impliment Ptex into these applications as soon as possible. Even if I have to personally spearhead the development and communication between all parties involved, this could very well be one of the most pivotal moments in development after the core rewrites to the applications themselves, in reference to Blender, Aqsis and Pixie of course.

In conclusion it is nice to see more and more large scale studios contributing to the open source community, while the tools or libraries they provide may be small and few, they are greatly welcomed by the community and we are encouraging more of it. One of the goals we are trying to promote is to "play nice", which means that open source software should be able to work well with commercial or proprietary software in terms of file formats, libraries and standards. One of those steps was the addition of OpenEXR (except the minor issue of Blender reading and writing EXR images upside down), hopefully more of the same follows and one of those steps can be the subject of this post : Ptex.

The actual details of Ptex can be found here : http://www.disneyanimation.com/library/ptex/

(© Pixar Animation Studios)
(© Walt Disney Animation Studios)

April Fools! Pixar aquires the source to Aqsis and Pixie in stunning lawsuit

2010-04-01T05:31:00.007+01:00

Update : Yes it was a joke ;)

It seems that history repeats itself, as we all remember the sad demise of BMRT and Entropy due to the lawsuit against Larry Gritz by Pixar over patent infringment, or something to that effect. Well recently it has come to our attention that certain projects are being hit with the same lawsuits over graphics technology patents and now Aqsis and Pixe are now no more in the open source domain.

What this means is that the developers have to license the RiSpec from Pixar despite the fact that the code was written from scratch, the patent technology described in papers are so close to the Pixar source code that lawyers are afraid of investment loss. "Aqsis and Pixe, while being open source has this code that infringes on the technolgy Pixar invented, clearly the need to take effort to protect the name and reputation, as well as financial investments, is required" says a source that wishes not to be named for legal reasons.

This seems to be a common trend in the software industry where one technology company sues another over patent infringement, it seems that the open source world is not immune of this legal battle either. This comes as a devestating blow to the community since this means that development on these projects comes to a halt and will require the developers to license the patent, sell the software in order to recoup the license cost and make profit to pay for the subsequent years thereafter.

Already the developers of 3Delight, AIR and RenderDotC have adjusted the pricing to cover the fees with the same legal action, though it is far easier for them since they are commercial products already with established footprints in the industry. The open source community of Renderman users and artists were just starting to establish the valid reason for such tools and on the brink of the dawn the rug was pulled from under us and now we either use the old versions that will remain as is or pay for the next gen versions of our beloved rendering apps.

It is a sad time in our chapter as a whole and we wish the developers of Aqsis and Pixie well as they adjust to the dealings of commercial development. We are only waiting to see if our site gets hit with the same lawsuit over the name RenderMan itself, something also spoken of around the net here and there, so time will only tell if this site exists in the future at all.

Video tutorial on Rendering Glass..

2010-03-07T10:49:00.003Z

Hi. I am mohan, from India. We are a small team of creative people making an animated series named KICHAVADI for a television channel here in our home land using Open source softwares.. Ted gave me the liberty to post here to give back my exploration with blender & renderman. Thanks for him. :)

I have done an audio-less video tutorial on rendering glass. Using fake method of achieving refraction and transparency with AQSIS. This is the same lamp and settings i am using it in production. Thanks to Erric (Mosaic developer) for detailed guide.

Erric talk on rendering glass material in aqsis - blender:
Setup the materials IOR and Fresnel for the materials RayTransp tab (also RayMir and its Fresnel if you want reflections), be sure to DISABLE both "Ray Mirror" and "Ray Tranp" toggles or MOSAIC will think its supposed to export raytracing. One thing to keep in mind when doing this is the environment map only sees what "outside" the glass so you will not be able to see what's "inside" in the refraction (like the flame and lamp base). You can get around this by turning down Alpha on the material however this will also "fade out" the reflections and refractions.If you want the reflections to be solid and the fresnel to be "see through" you can do a trick by enabling "TraShadow" on the material and MOSAIC's shaders will use the fresnel to adjust the output alpha.

This is my link to video tutorial

-Mohan
rangakahale.creations@gmail.com

Walkthrough of the Widow Pipeline Part 1

2010-02-26T01:08:00.003Z

I decided to make an example walk through of the workflow through the Project Widow pipeline, for those who seem interested in what we are doing. I contemplated a video entry but alas the lack of hardware in the interface-video-to-PC area prevented that from happening so I went about and began to write this entry in text.

The walk through is using objects and data from Widow, in the screenshot form so you will get to see the latest work we have done. Just remember that it has taken quite a long time to get to this point and it was not easy. Much of the work involved trying to get the 'Widow' pipeline functioning was done by trial and error, in fact much of our work so far has been pushing the limits, learning what can work and what does not, figuring out the best way to do something as well as ensuring that it can work more than once. We started out the project at full speed with models and textures completed by the end of the first month, the time since then has been a lot of R+D and setup for animation. In contrast to what people think, setting up a flexible, custom pipeline even for a short film is quite the task. Making sure that a single articulated model has the right texture, shader, movement from concept to finish is hard work to keep track of. Some of our models still do not have a final shader look for them, at least one model is still needed to complete the modeling phase, layout for the various sets is only just begun, animation has yet to get into gear and we are only half done. We still need to get the renderfarm situation solid. However despite all the work that has yet to be completed, the work we have done so far has been astounding! The work to develop the multilayer openexr display driver had been a huge deal for this project. In fact everything is rendered in EXR format in addition to TIFF and the framebuffer. The amount of work done to Mosaic by Eric Back was astounding and as of right now any development is being done for Blender 2.50.

Despite all the frustration that has slowed down production we are still diligent in finishing this.

Base Tools

Our base tools consists of Python, Blender, Aqsis, Mosaic and OpenEXR. Python itself is much of the pipeline as much of our tools use it for one reason or another. The shader editors we use run on Python for the most part, or use Python. Blender and Mosaic run on Python and there are even some tools written for Aqsis that use Python. Later on when we put all the video and audio together in Cinlerra, that too uses Python. Even the SVN has a Python tool attached to it to email members when files are changed. So Python stretches our pipeline from one end to the next, and with good reason too , it is a very powerful scripting language and can be used anywhere for anything. There is no compiling of the code, it just runs and if you are adept enough you can modify it and run again without effort.

Python 2.5.4 - http://www.python.org/download/releases/2.5.4/

Blender 2.49b - http://www.blender.org/download/get-blender/

Mosaic 0.4.9 - http://ribmosaic.cvs.sourceforge.net/viewvc/ribmosaic/mosaic/

Aqsis 1.7.0 - http://download.aqsis.org/builds/testing/

OpenEXR 1.6.1 - http://www.openexr.com/downloads.html

These tools are the ones that everyone in the team has to have installed in order for everyone to correctly open, edit and render in our pipeline. Below is a list of tools that we have used or continue to use.

Cinepaint 0.22-1- http://www.cinepaint.org./

Gimp 2.4.7- http://www.gimp.org/

Shaderman 0.7- http://www.dream.com.ua/theoldtool.html

Shaderman.NEXT - http://www.dream.com.ua/thetool.html

SLer - https://sourceforge.net/projects/ribkit/

Shrimp - https://sourceforge.net/projects/shrimp/

DrQueue - http://www.drqueue.org/cwebsite/

postmosaic - http://projectwidow.wikidot.com/forum/t-166757/functional-blender-mosaic-drqueue-renderfarm

In addition to the listed software we also have a whole ton of development environments to compile code, libraries of all types, misc utilities (code editors for instance), server daemons and other little pieces of code to support these as well. Of course some of these have been custom compiles as some tools do not have binaries available for download, or in the case of the shader editors both Shaderman.NEXT and SLer run off of Python. PostMosaic is a shell script written for BASH so is not usable on Windows, not to mention it was designed for the lastest stable version of Dr.Queue so it is not known if the same issue would persist on a Windows based renderfarm (of course one would wonder why anyone would do such a thing but regardless that possibility cannot be ruled out, as ridiculous and expensive it may be). The version of Cinepaint we use is only available for Linux as there is no working version for Windows, since we do need to use Cinepaint to load and save OpenEXR files. GIMP is pretty much standard on whatever platform you are on. Shaderman 0.7 is a Windows only build while Shaderman.NEXT runs off of Python and thus crossplatform. All kinds of tools for various functions and all available for Linux at the very least.

Asset Management.

First and foremost is an asset control, be it a file server via ftp, a NFS, or a distributed peer to peer, something that everyone can use has to be used otherwise there is no consistent structure to what gets worked on. In our final version of the Widow pipeline we are using SVN and this is hosted privately but all members who worked on the project can have access to the data. Previously we had relied heavily on Dropbox for our asset control however because of the limit of space we would need we started to work on developing something better. Arachnid was a series of scripts written for Unison by Paul Gregory, however it seemed to be a bit too buggy for our needs even though it did work. When we started to use SVN there had been some concern over corruption of binary files (.blend files are binary files for instance).

SVN gui (Rapidsvn) with remote file list

The initial idea was sparked during the viewing of the Hand Turkey Studios webcast during the 48hr Film Contest. They were using an SVN for there very busy 48 hour pipeline. I had also participated in aiding a last minute re-render of 6 frames for the Animux "Prince Charming" preview animation, this used SVN as well. It seemed stable enough and something we could work with, we eventually ended up hosting it ourselves courtesy of NOYX Studios, which is my friends small home based recording and editing studio. This also freed up the usage of Animux's network strictly for the renderfarm later on down the road.

Had everyone been in a single location instead of everyone spread out over the world a lot of our assets would have been easier to manage. As it is i would say the amount of data that we will have transfered over the course of the production can easily reach 2 TB.

The asset tools are always going to be upgraded to make communication and detailed information regarding certain data. The content and rendering tools work very well on this pipeline but the one thing we lacked in the beginning is starting to shape up with SVN storage and recently some talks with a company that specializes in the asset management sector.

More can be read here :
http://projectwidow.wikidot.com/pipeline:network

Modeling.

The Widow assets are actually small in numbers compared to some short films, much of the modeling had been completed for many months. In our purposes we are going to use the main subject, the spider model. This model was the first thing made from model, rig and texturing completely.

Closeup of spider with wireframe over shaded, complete with hairs!

You will notice how it was made using Quad polygons rather than triangles, this was a design choice rather than looks, the REYES pipeline is far more efficient dicing quad polygons into micropolygons so building in quads will actually decrease render times with SubD and displacement shaders applied. What happens is that the quad polygon with a SubD modifier creates a patch with a control mesh around it. When this patch goes through the REYES pipeline these patches get cut up into sub patches and then cut up again, then diced into micropolygons at the pixel level, then displaced, then shaded and then lit.

For those who want to read up on REYES :

http://graphics.pixar.com/library/Reyes/paper.pdf

Model of the spider

Since this is an 8 legged creature, a custom rig was needed to be made. The rig was built by Cedric Palle, and has controls that can either move the entire rig across 3 space or parts of the body, or one part of the rig moves the body while the legs stay in place. A very nice, workable rig. One of the issues we had was scale, the spider model compared to the environment is huge, so for much of the scenes a smaller version of the spider had to be used. What was ultimately done was to use a scaled down version of the spider without the hairs added they did not work so well at the scale of 0.01 so removale of them was a terrible price to pay, though we still have the model with the hairs on them for some extreme close up shots.

Rig of the spider

One of the things that was stressed in the beginning was to use Aqsis as the preview renderer when modeling because there were many instances where we either found certain bugs in Aqsis itself or there were some methods of modeling in Blender that looks fine when using the internal renderer but in Aqsis looks different. There are some things that Blenders Internal renderer can overlook or get away with because the renderer is designed for Blender, however when it gets translated into another language somethings sometimes don't come out right and in this case there were instances where the two rendered very different results, so using Aqsis as the preview renderer was needed. In most cases though there was little difference in the two.

More of this can be read here :
http://projectwidow.wikidot.com/pipeline:modeling

Texturing and Imaging.

This part of the pipeline was not used as much as originally intended but did find use here and there when needed. Much of the surfacing is done with Renderman shaders but there has been several uses for textures such as ground planes and the spider design. When we made textures they were first worked on with GIMP and then later with Cinepaint. All of our textures are in TIFF format simply because this is the only format that Aqsis can process into a MIP map.

Textures above in Blender

Textures in Cinepaint

There are 4 texture maps on this spider model. Color, Specularity and 2 different levels of displacement maps. One for long to mid shots and another for close up details. These were first created in GIMP and later cleaned up in Cinepaint.

http://projectwidow.wikidot.com/pipeline:texturing

http://projectwidow.wikidot.com/spider

Layout.

This portion of the pipeline was one of the most difficult to tackle because we were unsure exactly how to setup multiple scenes with animated objects without making each shot 100+ MB in size. Linking provides us that ability to make multiple sets in a small amount of time, add in the objects that need to be animated and one of the most important reasons is consistent shader and lighting settings from set to set. Our main environment is built off of 3 main sets, one of them is the complete set, the next version is most of the set and the third is a set with much of the objects removed. Set design in this project is tricky, depending on the camera view it is far more efficient to only include objects that are going to be seen, if we made one set for the entire thing then much of the objects would never be seen at all and thus reducing export time as well as disk space.

In this example I am using one of the production scene files (scene 002 to be exact) since from this point in the pipeline these scene files will be what every other process will be based off of. Because we are linking in objects we have more consistant shader visual continuity, there wont be really obvious repeating patterns and the varying amounts of turbulence, noise and fractal patterns wont change from shot to shot. If we did not link in objects each shot would have to be manually edited and doing this over and over is just not practical, so linking solves at least much of the grunt work.

Scene 002 set which is entirely linked from the main scene file
We can link or in some cases append anything into the layout files, however to keep the work flow consistent, having a custom file per scene prior to the work will allow anyone who starts to animate to do so without the fear of their work being altered by others. We also changed the various screens of the interface to accommodate that factor, having them labeled something like 'BLENDER_LAYOUT', 'BLENDER_ANIM01', 'RMAN_SHADER' so that different people can work on the same file without altering the settings that others have done, depending on the circumstance of course.

At this point there are two pipelines going and one is the modeling, layout and animation pipeline and for the most part that is contained in Blender with some Renderman data associated with it but nothing really shader heavy. In the beginning of the modeling phase Daniel had made a ton of models for the environment, which I had later shaded with the custom shaders. At some point in time later these shaders and Mosaic shader fragments will be appended in to the scene file that the rest of the scene files are linked to. This will reduce the copying and editing needed to a maximum of 3 main blender sets. This will also be necessary to do with lighting.

In retrospect it could have been done a lot better, the planning of this was not fully worked out but considering a lot of time had passed we decided to just go with what we had and keep patching this together. Linking and appending offer us that way of making time critical adjustments or in some cases rebuild. Later in the future this will be fully planned beforehand but for 'Widow' anything done from this point on would have to work.

Nathan Vegdahl also helped me out with this during a conversation on IRC one night, for all the things we knew how to do with Blender, something like actually bringing a linked object in scene was unknown to us, which of course is laughable now but at the time it was a moment similar to when the light of Marcellus Wallas briefcase renders one speechless in wonder.

More information can be seen here : http://projectwidow.wikidot.com/pipeline:layout
and here : http://projectwidow.wordpress.com/2010/02/04/library-linking-svn-and-a-new-tool/

Animation.

Since we are just now touching on this part of the pipeline there is very little to tell but as we build each scene and shot file up we are linking in the subject models in as well. At first we were not clear on how to add in external files and edit them (such as animation) without appending the data in itself. It just so happens that during that time the Durian team had released a short video that deals with this very subject so within minutes of watching it the whole animation portion of the pipeline had been figured out in my head, and within 30 minutes on paper and being implemented in the project folder.

Since my primary task on this project is shading, lighting and effects TD (I just happen to do other tasks as well) I am not too skilled at the modeling or animation end so our models and rigs have been made by others, so when building a layout scene I generally just place the object in scene and then place in the approximate area they are to be in. Depending on who animates them will have ultimate control over that file until it is considered final, upon which the scene is copied and renamed for shading and lighting usually with a version number and shading added to the name.

During this entire time effects animation is being done as well to accompany the primary animation. This can include anything from spider web movement, cloth simulation to particle work and ambient animation of environment objects. One such instance is these series of cables that have a Lattice deformer added to it which can be animated either by hand or with dynamic animation scripts during scenes where the train is going through and creating some vibrations, really only adding atmosphere to the scene instead of static models everywhere, bringing life to the shot.

Effects

A lot of R+D has gone into this area to see if there some of the things we wanted to do were possible. Spider webs for instance are very rigid structures when in complete form but when broken is a very flexible strand of an extremely lightweight material. One of the problems we had from the start is how to accurately replicate spider webs without a high poly count cost. One of the ideas was to use the Curves in Blender, which are exportable and renderable, however the problem comes in animating the control points - THAT part of the Pthon API is not accessable to Mosaic and this is good example of just some of the limits of the Blender 2.4x series. So more research went into varying types of methods for webs; polygons with hooks in some key vertice points, polygon web with cloth modifier, curves for non animated webbing.... all these methods could work. Even texture maps on a plane would work, however it all depends on what is going on in the scene, how close it is to the camera, if it is static or moving and so on. In all there is up to 12 different ways we can do spider web strands and it will most likely take all of them at one point or another.

Another research project was cloth itself. There might be a chance that we use cloth objects for blowing paper, lots and lots of little itty bitty pieces of paper. This demanded some testing and despite the fact the "paper" did not really act like paper, it did prove to work fine regarding the technical possibility to do such a task. When this does get added to scenes it is pretty certain that the exported data will be quite numerous and large. The one thing that one should remember is that in Mosaic it is possible to export only one RIB of an object and then no matter where it is, as long as the vertices do not move then only that one RIB is called on in the frame RIB file. However with something like cloth, each frame exports a cloth RIB file as well since the file itself is a large collection of where the geometry data is located in 3D space, so if there are a 100 tiny cloth objects all blowing around for 30 seconds, that is 90,000 individual RIB files for that sequence just for the cloth objects alone. So trying to work out the effects for these kinds of shot will require some effort but is possible.

An early web test done last summer

In all there won't be a whole lot of effects that anyone would consider "effects", it is more like supportive environment elements since the whole short is an effect in itself...... anywho, the effects are one of the last things to modify during the shading and lighting phase. The reason as such is that for the most part some of the effects can be cheated simply because of factors like DOF, lighting setups, distance to the camera, movement and so on. Any of these factors are only really visible during the lighting process, there might be times when a web will be in shadow so if it is off a little bit then so be it, regardless if we remove or add in objects. If we really were worried about every single thing being perfect then this will never be finished. It has to look good enough, not perfect.

You can read more of this here : http://projectwidow.wikidot.com/r-d

Shading and Lighting

This portion of the pipeline is the very reason why we are doing the short film in the first place, to showcase the power of Renderman. In all reality this is an ongoing process from start to finish as much of the initial shader work was done in the early months of production. All that is left is to add the AOV code to them and they are ready for production use. The way we wrote the shaders is also important since much of the work is going to be done in Blender, so the shader parameters were made with Blender in mind as opposed to the average shader code. Some of the shaders will never see the light of day, others are a wonder in appearance, some are actually being built to use Blender paint data to apply a separate shader to the object and others will not be seen as much but still look great.

All of the custom shaders made for 'Widow' are designed to be used within Mosaic. When writing a Renderman shader it is not uncommon to have numerous parameters that adjusts the way a shader looks or functions and in most cases this is perfectly fine if you were to use the shader in something like Maya where anything can control them due to it's open API. However since Mosaic's shader fragment system uses Blender material functions to change these parameters, you are limited to this area. Luckily the Blender material system is very robust and one does have quite a selection to use, the hard part is remembering what function of the Blender material controls the Renderman shader, there does need to be some planning involved. It is very possible with Renderman to have multiple functions that control different parts of the shader code, so like you can have 3 Turbulence functions but they can each change the values of
various other parts. Problem is that if you want to be able to change these parameters with the fragment system you are limited to what it can connect to, if using a Turbulence function in the Blender materials you can only have one of these, so you need to find something else for the other functions or not use Mosaic's fragments system. For the most part the shader functions are not too complex and when the ones that are usually only have a handful linked to the Blender material.

Custom shader development and fragment assignment in Mosaic

Custom shader with preview rendering using Pqsl

The other part of shading that usually needs to be completed first is the material assignment to polygons in order to use different shaders on a single object. This does not apply mulitple shaders to a single mesh when exported, this is not possible to do according to the RiSpec (unless of course in the case of Aqsis there is the existance of layered shaders but these require special shader and RIB programming to accomplish this), so what Mosaic does is split up the mesh into sub meshes which it then adds the shader reference in the RIB file. So with an object that uses multiple shaders, when exported these in turn become seperate RIB files. This operation is not visible to the user though and unless you are totally aware of how it works you would never know this would happen.

In addition to the custom Renderman shaders we are also using a lot of Mosaic's shaders as well considering there are many situation that do not require a complex shader. Such as various parts of the train are using the Mosaic surface shader because they wont be seen much at all and thus do not require anything other than a plastic type shader. The Mosaic lighting shader is the primary code we use since it tends to be one of the most complete light shaders seen for Renderman at all, next to uberlight.sl from over 10 years ago. During the course of production Eric had added volumetric shading to be called when the "Halo" setting of a light is switched on, something that was desired by the artistic members.

Lighting is the most crucial step for the production, not only the art aspect but from a technical view as well, there are many industry proven tricks that we will be employing to reduce render times as well as making it appealing to the eye. Since Aqsis is not ray trace capable we will have to use shadow maps as well as environment maps in some cases, however since it is Renderman much of the lighting in the environment can be rendered once beforehand and then later baked in to the scene over a spread of frames, also reducing render times. Custom lighting setups will need to be made of course but much of the general lighting will have already been rendered and baked in for later use.

I also managed to find a python programmer who wrote a script which adds a spotlight that is pointing to an empty object by defualt. This handy tool was something I always wanted to have, it makes lighting such an easier task when you only have to move two objects to get the spotlight to point exactly where you want. So having a script to just add this in without the setup of making the light rig itself is a blessing. At this time it is only a simple script but I imagine can include a GUI someday and hope to work on this script myself later.

Rendering.

This is where we will be finishing up each shot as they come out of the final stages of production. These exported RIB file structures (which can be quite large in the range of 500+ MB) will be uploaded to the remote render farm we have reserved and then using DrQueue to distribute the frames across the 20+ node renderfarm (see down below). We will be using a newer developmental version of the recently released Aqsis 1.6.0, which is now technically 1.70. Prior to this we were testing the developmental alpha version 1.5.0. The reason we are using developmental builds rather than "production stable" releases like 1.6.0 was simply because we are a test bed for them and provide some great cases for them when used in a production environment. So even though later on building a custom Animux rendernode Live-CD will require compiling a stable development build it will be the very same we would be using for our own preview rendering, thus maintaining a consistent rendering environment regardless where the rendering takes place.

Aqsis rendering of our train model with full shaders and DOF, featured in the new Piqsl framebuffer interface

Since we have been using Aqsis from the start, our assets are designed around it. Subdivision surfaces for instance tend to look a little different depending on the renderer used, be it of course between the Blender internal and Aqsis. So it was used during modeling, as well as any testing for ability to do what we wanted. Such as during the R+D process we use Aqsis entirely for the sole reason to see if what we are trying to do is possible at all. Like finding out that curves are not translating animation during export, or finding out that we can make very thin polygon strands that can look just as well as a curve. Testing out render times for full scenes, testing DOF and motion blur on both objects and cameras, testing out instancing methods between dupliverts and Array Modifiers, testing out a way to paint on objects to change shader values, viewing texture mapping results, the list goes on and on. We are not using Renderman much for animation previews simply because it is far faster and easier for the animators to make 3D view preview videos themselves than teach them about Renderman preview rendering. The shading and lighting process and beyond will be entirely rendered using Aqsis.

All of our frames are being rendered in the new Multilayer OpenEXR display driver.

Of all the achievements made in the past year it was the Multilayer OpenEXR display driver and Mosaic counterpart that made the biggest impact. By adding this to both Aqsis and Mosaic, it made AOV rendering a simple task, unless of course you were using custom shaders which requires that you add AOV code to it, something that can be a challenge unless you have experience programming. Openexr has become an industry standard now so having the ability to use an HDR file format through much of the pipeline was desired. Up to the point of editing the final video, the exr format has and will be used and the only other image format used is TIFF, that is only for textures which then get processed into the custom MIP map format. With the ability to put all AOV layers into a single file format was itself a huge contribution to not only Blender but the rest of the community. Being that it was designed for Blender, when added in the node automatically makes output points for each layer in the node, thus not requiring a large amount of nodes for each AOV and making the whole process much easier. The only problem is that Blender has a unique "feature", it writes exr files upside down and any file that is read into Blender will also be upside down and requiring a flip node for each layer. We are not sure if this was intentional by the Blender developers and hope that the the next version umm "corrects" this, Irritation of this aside, making a template composite blend file is an easy workaround and the rest of process can be devoted towards working with a shot and not with setup.

Cinepaint with a single multilayer openexr file opened

'Widow' was a great test bed for the Aqsis developers, during the summer we tried to do everything possible to test every feature or optimization, such as the improvements to depth of field and motion blur, or testing the new Piqsl gui. In fact since I do my own regular builds of Aqsis I have been taking advantage of some of the newest toys like point lights that use single maps as opposed to the old standard of 6 thus reducing the amount of files per light, per shot. We did encounter some errors, sometimes Aqsis failed horribly but with constant bug feedback the Aqsis developers were quick to fix and in turn we were able to continue to test.

The renderfarm operated by Animux went through initial testing this past summer as well, using Dr.Queue to manage Aqsis render nodes. Initial problems existed in the first series of tests then we found out that the way Mosaic writes the render script caused some errors. So one of the Animux devs had written a small shell script that edits this file so that Dr.Queue will correctly assign frames across the network. This is a tool called 'postmosaic' and on the Animux release 'Tremor' this was added by default, all one needs to do is run the command in the shell. This was also released to the public for anyone to add to their own system.

The Animux renderfarm

There is going to be anywhere from 7000 to 9000 frames needed to be rendered so when we do end up starting that process there is going to be 20 times that amount in RIB files, shaders, textures, shadow maps and other data. In all this entire short film could occupy a 500 GB volume, between the production files, the RIB exports, the frames, video and sound. It can be estimated up to 5 times that in the amount of data would be transfered over the internet, considering that we are located all over the world. Eventually this will archived onto a stack of DVD's then an external drive will be purchased and backed up onto that as well.

More about this can be read here :

http://projectwidow.wikidot.com/pipeline:rendering
http://projectwidow.wikidot.com/r-d#toc6

Aqsis Pipeline : http://wiki.aqsis.org/dev/pipeline

Composite

Once each scene is rendered the elements are composited together in Blender. Since the Multilayer EXR format was designed for such a case, the image itself will contain the AOV layers that we specify such as color, specularity, normals, UV, alpha and so on. Since it is one file there is no need to render out each AOV file per frame, it is all self contained. The only issue is that Blender seems to read and write EXR files upside down, it is not clear if this was done on purpose or if it was an oversight but since Aqsis writes EXR files the correct way we need to flip the layers before they are run through filters.
The reason for the AOV rendering is because if anything doesn't look quite right it is far easier to correct that particular layer than rendering the entire frame sequence again. This can't remove issues that occur either from modeling mistakes or rendering artifacts but in turn this can also reveal artifacts not normally seen in a final render, such as tiny grid cracking spots that normally can be very difficult to spot initially. This also is where you first experience where AOV code is not present in which case the layers will have a very different look than expected.

Cinepaint with bad AOV layers composited (including the UV layer which normally would not be visible)

Once all the layers are satisfactory they will be written to an OpenEXR image sequence and placed into the final frame area where they will be brought back into Blender for the final video output and placed into the final stage of production.

Blender composite nodes of a single OpenEXR file

There has been the thought that we can use Blender 2.51 for the compositing of 'Widow' since there are new composite nodes added. Since this would be at the tail end of the production it would not be a bad idea to start upgrading the pipeline to accommodate the next versions of software as it is quite possible that all the tools needed would have at least been updated somewhat.

More can be read about in here : http://projectwidow.wikidot.com/r-d#toc5

Sound

NOYX Studio is taking care of the sound creation and editing for the short and for the first time recently I had a chance to listen to it. Since for the most part the drama of the scene drives the animation, sound is really a post process, in this case he happens to have some of the sounds needed for the short and is adept with sound.

Even in the sound department open source is being used in the form of Ardour, something in my opinion is one of the best audio tools out there. Something I really wish existed 10 years ago but sadly at the time there was no such thing and if there were I was certainly not aware of it.

Ryan has already built up quite a sound library and being an sound artist himself he has taken samples that eventually ended up sounding nothing like the original where others were damn near the original recording (EQ done to them of course).

This is also where the video will be edited, I will be hiking it over to his place and putting together the samples, soundtrack and shots to fully bring this to the final product.

NOYX Studio consists of a small network ran entirely with Linux (64Studio for audio production and Ubuntu for file server use) so Ryan has been very helpful in many areas of the production, not to mention being the glue that holds this whole pipeline together.

Conclusion

Project Widow is still chugging away, though there was little that has been seen so far and the stuff that has been "released" has been in various places, forums, postings and what not. Consider it guerrilla marketing haha. At this time our work is mainly getting all scenes set up for animation and fully enter that phase now that our initial work on the first three scenes turned out nice. People wanted to know more about what was going on and I wanted to speak a little bit of tech talk so this walk through is the result. For Part 2 I am going to explore deeper into some parts of the pipeline with screencasts.

The pipeline is something that can be run on any OS that has Blender, Mosaic, Aqsis, Cinepaint, GIMP, SVN access, and a web browser. Workstation, server, laptop, whatever this pipeline has been tested and developed on all of them. Yes nothing is one complete package from start to finish but considering this is designed around professional studio pipelines it seemed important to explore those methods aside from the neccessity of having to do so. Yes the software is already considered old, except for Aqsis but this is only because it is stable to handle the tasks we want, much of this past summer was finding bugs and development of new functions and tools. We are also using professional production methods and tricks, in fact in some cases the same tools, as such is the case with OpenEXR and Cinepaint, since both were developed by studio employees with the intention of being used by these same places as well. Researching into how these places built their pipelines was also a great starting point, of course with information being limited due to trade secrets and proprietary software unavailable to the public but the idea starts and if you know talented programmers one can develop their own tools and in our project we just did happen to know several.

The development team all use Linux while our artists have been known to use both Windows and Linux, so access to the SVN server had to be compatible across both operating systems. While it seems easier to install the latest stable release on Windows, it is far easier to build the tools on Linux if the source code has changed (such as the case with Aqsis), not to mention some tools such as Cinepaint and Shrimp are only actively developed for Linux. Obviously the further down the pipeline the less we use Windows and rely on Linux for everything, modeling was done mainly on Windows but the rendering will rely entirely on Linux for instance.

After this film is final there is talk of releasing the production files to the public, sort of an open movie. This would be a great way for people to really learn how the process is worked out considering that much of the pipeline has been pieced together from all open source tools. A lot of documentation has been written as well. What will not be included are the exported scenes, only the 7000-9000 OpenEXR composited frames (maybe). Of course this would be released as a torrent file since the eventual 8 GB of potential data this whole thing could take up would be a huge load on the SVN server. Considering that the BRAT toolkit combined downloads exceeded 1000 it seems that it might be a worthy effort to do so, along with a special gift inside. I will also upload the video to the Internet Archive as well.

In the future though there is one part of the pipeline that would need to be fully worked out and that is a solid asset server as well as a web based production tracking and collaboration system. We would also be using the next version of Blender, Mosaic and most likely Aqsis. However the tools we are using right now are battle tested, proven to be stable and can reproduce the same results so we are using these version for this project, the programmers spent a LONG time working day and night to provide some kick ass software for us to use and it would be a waste to let all that work go in vain. Already there has been some experimentation with exporting to RIB format in Blender 2.50, however this was considered a personal research project and 'production stable' at all.

None of this would be possible without Linux, specifically Debian,and any of it's children offshoots such as 64Studio, Ubuntu and Animux.

I hope that this walk through was not a complete bore, I did skim over a lot of things in this first part of the series.

A random collection of thoughts

2010-01-28T00:50:00.005Z

This post is not really about anything in particular, really it has been a month since the last post so I want to just put down some thoughts about some of the stuff that has been sitting in my head over the past year.

Project Widow has become QUITE the task, I really do not think any of us realized just how difficult it was going to become. Considering that this is a small team it is not surprising that the initial 3 month deadline was completely blown. What started as a test became a short film, it will even have its own soundtrack provided by a fairly well known artist (that is MY surprise!!), which that too is considered CC license but anyways back to the point. When the idea started to form it was due to postings on websites that asked if this technology was able to do what we claimed, then why can't we re-render something like Big Buck Bunny? Well one reason was because of the technical implications, BBB was designed for Blender - not something like Aqsis. Another reason was simply why redo something when we can create something new? I took the idea that Pixar perfected, using short films to showcase advances in their software or more accurately - create short films to take advantage of the advances in the software that they developed. Well this is sort of one of those reasons. Quite a bit of programming has been done because of this project, new ideas and methods are also being developed as well. We are doing something never done before using the tools we use and in some cases - develop. Of course we have had more than our fair share of issues as well, in many cases some of the original ideas have either been scraped or re-developed in hopes that this or that would work. In all this is a huge learning experience for everyone and not to mention great demo reel material for all those involved, at the very least something to be proud of! Hopefully before the end of the year this will be completed, we are chipping away at this even if at times we want to throw in the towel (lol) but this is something that needs to be finished.

Something else that has happened over the year or so is that there is a great deal of interest for this pipeline, not only from the average user but also from studios or at the very least certain people within these places. I really cant say who, simply because I have not been authorized to release that kind of information but to the best of my knowlage at least 3 studios are testing these tools in some form and one of them is fairly well known in the CG industry. We have even gotten interest from a member of the Blender Foundation (other than the link on the website that is). Tens of thousands of hits to this very site over the past couple years and some of them from the big studios that we all know. I find this totally mind blowing, regardless of how little I personally have done to develop actual code, this site itself has really grabbed the attention of these people and it all started because I wanted to create a small community where we could bridge that gap between Blender and Renderman somehow.

Here is the best part! We have only just begun! Really this is the technolgical TEST that in a sense has proven that while the intagration of the tools is still not completely %100 compatible and some work arounds are required to achive certain results - all of it was mainly to prove that this WORKS! Project Widow already proved this long before this current stage even, Eric made a quick 10 second small rendered video of a test shot, so the proof of making an animated video using these tools has already been done time and time again. Project Widow is no longer a test, it is a short animation. When Blender 2.50 comes around and the next build of Mosaic is stable enough, who knows what is going to happen but I can say for certain that it will only improve over time.

I promise the next posting (coming early next month) will be a bit more than personal ramblings...

Happy Holidays!

2009-12-24T21:41:00.008Z

Happy Holidays to all!

We want to wish all the best of times and safe travels! This post is a long time coming, considering that there has never been a holiday related post here before but this year is different. Why is it so different than any other year? Well Blender to Renderman has become a valid project this year, at least we like to think so. This has stood the test of time and criticism, has pushed development in other areas, not to mention more people are becoming aware and using these tools for their own needs. Considering that Aqsis is one of 3 external rendering examples featured on the Blender website, I think the efforts done by everyone past and present have started to come to light. While this website is only one effort to bring a community together, the idea and practice of exporting Blender scenes to Renderman RIB files has been around for at least 7 years. It has only been in the past 2 years things have really picked up and only this past year that our efforts are taken seriously and not "Yet Another Project".

Not to say that the previous year was bad, not at all, in fact that year was a step towards the right direction. However even today this is still in it's infancy and we all have a ways to go before we see more start ups using these tools to develop their own animations. As mentioned in the previous post, some already have, we applaud them and encourage them, cheering them on because the more people that use these tools that are not directly involved in the development of Mosaic, Blender, Aqsis or Pixie then that means that we as a community have at least helped steer others in that direction. The tools we use and developed had also been used for research, in the form of RenderAnts, a GPU based Renderman visualization tool.

2009 was also the starting point in which "Project Widow" began, something that we wish would have been completed by now but due to the complexity and just the fact that this has not been done before using these tools, production is still in progress. This project helped in the development of Aqsis, with the multilayer OpenEXR display driver, as well as RIB Mosaic, with the addition of these EXR driver presets. While the production is slow, things are starting to pick up and we are chugging away, hoping that by next years SIGGRAPH we will have something to present. Regardless when it gets done, it will get done, some way, some how.

With Blender 2.50 on the horizon things are taking a turn. If anyone has downloaded the Alpha release you will notice that the interface has gone through a massive transformation. While an interface is only the nice presentation of the underlying code, this interface has truly changed from the Blender we all have been used to over the past 10 years. What is more important though is the Render API, the one thing that many have been waiting for years to come to light. At this point in time it is not known exactly when this will be added but development is supposedly in the works according to one of the Blender devs. This is one of the most important steps towards a more solid link between Blender and Renderman, in fact it is better for ANY render engine period! Be it Luxrender, MentalRay, VRay... whatever the case may be this will offer that ability to choose which render engine one wants to use, with better access to the data that was previously blocked by the Python API.

RIB Mosaic will also go under a massive change, mainly because in order to continue development Eric is forced to, since Blender is using Python 3.x and Mosaic was developed for the 2.5x Python, thus a substantial break of code. Also according to Eric in this recent post there will be a change in how Mosaic will not only function but how we will interface to Renderman. The current Mosaic uses a single pane system in the Python script window, the shader system alone is a massive series of RSL code that tries to replicate the Blender materials, the options and settings are there to try to include each feature and option for every single well known RiSpec render engine available. This has made development hard for Eric because it seemed to go beyond what was expected of the project. According to his latest post, RIB Mosaic will be more or less a framework for others to build upon, be Aqsis, Pixie, 3Delight or PRMan. This way he can concentrate primarily with Mosaic as it is rather than fixing the minute details for each renderer. "Pipelines" are described as these functions for each renderer, such as a pipeline for Aqsis shadow maps will be different than a pipeline for point clouds for Pixie. This approach will also allow others to develop pipelines for each rendering engine and then share them. The idea is to change the approach on how Blender and Renderman are to be used, rather than replicating Blender's material and lighting system, it will encourage users to take advantage of the true power of Renderman from the start. This idea is very similar to how Maya and Houdini approach the Renderman interface, the 3D app is just the geometry and animation engine while Renderman is the primary rendering system and thus anything built in the app is designed to be rendered as such. Not only will this encourage new users to really learn Renderman, it will also help more experienced users unlock the power of Renderman as it has been done for many years by the likes of Pixar and Industrial Light and Magic (for instance).

So changes all around are happening this year and even more so next year. Each year that I have been involved to some degree or another I get more excited about it, not because I am involved per se, it is more because this has been a desire of mine to see happen at all. The first taste of Renderman I had was in 2002 when I had been using Lightwave and downloaded 3Delight and Aqsis to be used with this export script Light-R. Since then I have not looked back and I can tell you hands down that anything done now using these tools has surpassed the Lightwave work I had played with years ago. That is why I am excited about this, the efforts done by many people have not only made the ability possible but work very well together and has reached all over the globe. We are not this massive corporation with millions in marketing funds, we are not even an animation studio.... most of us are just your average geek programmer or artist that have this desire to continue on.

So in the 2010 I believe that our efforts will become noticed more, not only by the Blender community but by the rest of the CG community, as well as the industry as a whole.

The image at the top was modeled by Jeremy Birn (yes of Pixar) and was the Lighting Challenge around this time last year. I never got to complete my render in time, until now. While it is not perfect, forgive me it was done last minute, it at least it is something festive! Not to mention the massive file size and poly count! The tree took up the majority of the render time and rightly so, each one of those needles are polygons! Post processing was done in GIMP.

See you next year!!

KICHAVADI

2009-12-17T17:49:00.003Z

Well it looks like our influence and efforts are starting to pay off! Recently a small team of artists over in India are working on developing an animated series and are using Blender and Aqsis, among other open source tools, to do it.

What a good start as well! They have been posting regular updates on their blog, mainly a lot of test renders but they do look very nice! In the past few days alone there have been many posts just on tests of shadows and DOF, so they seem to be getting the hang of Blender and Renderman quite well!

Hope to see more from these guys and best of luck gentlemen!

Update!! - RenderAnts - Interactive REYES Rendering on GPU

2009-10-27T04:50:00.004Z

This has been floating around the net recently, something that is actually quite impressive for what it does as well as what it could be. Interactive REYES rendering on a GPU, which really in a sense has been something a lot of people and studios have been looking for.

CG Society Link

BlenderArtist Link

Authors page:
http://www.kunzhou.net/

Paper:
http://www.kunzhou.net/2009/renderants.pdf

Video:
http://www.kunzhou.net/2009/renderants.wmv

Updated News!

According to a source recently in the comments of this post the source code(?) for this is located here : http://research.microsoft.com/en-us/downloads/283bb827-8669-4a9f-9b8c-e5777f48f77b/default.aspx

There have been other similar types, such as Pixar's LPics which was featured after Cars was released, as well as Lightspeed which ILM had developed during the Transformer production. However the difference was these used GL shader equivalents of RSL shaders, so they both did not really use a Renderman based rendering. Both were very impressive though.

Gelato was also something that had been designed for such a purpose but was discontinued after a few years, certian tools did have the ability to convert basic RSL shaders into it's own shader language so in a sense it was sort of a start of what could be. Larry Gritz, the same person who had developed the first non Pixar REYES renderer, BMRT, had developed Gelato. So maybe that was another reason for Gelato being non REYES based considering the legal issues between Gritz and Pixar in previous years.

RenderAnts is a GPU based REYES rendering system, using RIB and RSL code to render the resulting image from the GPU, rather than the traditional CPU software we currently use. The ability to get fast rendering feedback is always a great thing, the only current way to do this is to render smaller sized images along with turning down the detail features of REYES, or do something like Crop rendering which will only render a certain region. This does in fact make an image render faster but if you are concerned about details, or lighting changes, having to render out a new image just to see if something works or not is quite a painfully slow task. This is why RenderAnts is a huge deal. It is not because of the fact that Elephants Dream was used to showcase the speed difference of normal CPU based rendering versus GPU, though it was pretty cool to see that. Elephants Dream was used mainly because it is Open Content, these were fully animated scenes that can be used for any reason within legal bounds.

What makes it so interesting for us, the Blender to Renderman users and developers, is that Mosaic was used to export these scenes out. This is why open source Blender to Renderman is important, it can be used for research, not only production. It is far easier and cheaper to use Blender, Mosaic and Aqsis or Pixie to showcase some new 3D research where you have access to the source code and can make your research possible, than it is with closed source commercial software. At best you can make a plugin for Maya if you were to make something like say a new form of fluid simulation that used a custom RSL volume shader. You would also only be able to do this on one system, while with open source you can have several copies spread out over a network, even at home.

This is the first time Mosaic has been officially used and cited in a published research paper.

If you watch the video make sure to notice that this NOT real time, it is fast but it does not have the ability to render at even 1 fps. At best it does take a few seconds, the few that do look fast are more like camera placement changes or lighting changes. Anything really drastic does seem to take a bit longer to render. However considering the same frame using the same data would take a considerable amount of time for PRMan to render does say quite a bit. What this also means is that this is not to replace current software for final frame rendering, at least not for a while. The best use for such a system is for previewing during production, the little changes that artists and TD's make for instance. Something so tedious like shader development would cut such time in half, making 30 renders of minute changes in the shader is a very time consuming task. It is not hard to imagine that this will be used by the big boys very soon, it is also only a matter of time before a commercial adaptation of this is released in the next few years.

We just have a nice warm feeling knowing that our work here has helped in this, we were used first. THAT is something.

Aqsis 1.6 and Project Widow

2009-10-20T01:20:00.007+01:00

Ack! I have been very behind! I recently moved (again) and am also in the process of remodeling a house as well so my time has been limited, obviously when BlenderNation reports news before we do. Not to mention the link to this site as well. Anyways off to the subject at hand.

Aqsis 1.6

Aqsis has undergone some serious changes since version 1.4 and a lot of it has been to improve it's speed and stability. Copied directly from the press release :

General optimisation and performance has been the primary focus for this release, with improvements including:

Avoiding sample recomputation at overlapping bucket boundaries.
Refactored sampling and occlusion culling code.
Enabled "focusfactor" and "motionfactor" approximation by default, for depth-of-field and motion blur effects respectively.
Improved shadow map rendering speed.
Faster splitting code for large point clouds.

In addition, key feature enhancements have been made with improvements including:

Multi-layer support added to OpenEXR display driver.
Side Effects "Houdini" plugin.
New RIB parser, supporting inline comments and better error reporting.
Matte "alpha" support, for directly rendering shadows on otherwise transparent surfaces.
Refactored advanced framebuffer (Piqsl).
Texturing improvements.
Enabled "smooth" shading interpolation by default.

Now to get the point. One of the main additions to Aqsis, the MultiLayer OpenEXR, was from the request of the team that is working on Project Widow. The reason for this of course is because Blender's Compositor can use this directly, much like the way it can with it's own EXR render. This was to facilitate an easier workflow later on during the composite stage, rather than have a mess of multiple image sequences for each and every single AOV render we wanted. Also because of the talks between the Widow team and the Aqsis team, Mosaic was also built to handle this very function. In the latest CVS version of Mosaic there is a much larger menu selection of display drivers available than in previous versions. So Blender, Aqsis and Mosaic all work hand in hand in various stages of the pipeline now, rather than just rendering. Since we used Aqsis for preview renders as well, it was important for us to have the speed and stability. The Piqsl framebuffer was also a request from us working on Widow, we wanted to have the ability to scroll through images using the arrow keys rather than clicking on each render, this saved us a lot of time when working on previews and rendering dozens of images. We also tested Aqsis quite a bit through out the process, though now that it is fully released we can use the "production stable" version rather than the daily builds or sources.

Above is an example of the AOV multi layer EXR renders

Composite Nodes

During the months of pre-production of Widow, all of us would gather in an IRC chat room and discuss ideas that we wanted from Aqsis, also to get feedback over how to work with this or that in the rendering end. Planning for a renderfarm had begun and was tested over the summer, even building a new script tool so that DrQueue could use Mosaic batch output. We also had to design a lot of the assets from Aqsis in, by that I mean the process of figuring out how to make Blender work with what we wanted. There were some ideas scraped simply because of the limits currently imposed by the Python API.

So now that we have covered that...

Project Widow

This short has taken a LOT longer than planned, the idea was to get this done in 3 months starting in May of this year. It is now October. So yes things are way behind but that does NOT mean that it is stopped. At the moment it is at a standstill because there are so few of us working on it but also I have had a lot of real life situations that prevented me from devoting as much time as I want to it. There also has been quite a bit of technical issues as well. Our propsed "Arachnid" system was not stable enough to be considered as workable, it was just not perfectly solid as we had hoped. So now we have decided to use SVN once again and that is still being worked on (issues with speed mainly), the other hosts I had looked at did not offer near enough space for what we needed, so we will be using a private server located in Wisconsin belonging to a personal friend of mine.

One of the main issues we had encountered was texture maps. Sometimes when the map is pointed to a file that is not relative, it will not be found and thus not rendered. This became frustrating to the point that it was decided that all surfaces aside from the spider model will be Renderman shaders rather than a collection of images. This also supports our cause since Blender can do texture maps quite well on it's own but when it comes to displacements nothing beats Renderman. As there were to be quite a bit of it in the short it only made sense to showcase what Renderman can do quite well rather than just say "Hey it can render!" So a lot of work has been going into designing shaders that can take advantage of Mosaic's power, not just look good. Such as using the Blender material system to control the shader parameters so that different models can share a shader but each have it's own look and feel. The train above is such an example, the main body of the train itself is using one shader but the color and subtle pattern differences are controlled by the base Blender material. The only other shaders that do not share this are the wheel assemblies, but even those are also controlled in their own way by their base Blender material. In all the entire short maybe uses 12 custom Renderman shaders, including the displacement shaders, the rest are all Mosaic's power.

Blender 2.50 and the future of Mosaic

This is something that needs to be addressed as the timeline to the next version of Blender gets shorter. Mosaic as it is in it's current form, will not work with Blender 2.50. This is due to the use of Python 3 for the reworked Blender. However all is not lost since the Blender devs have started to work on the much requested Render API that we have been waiting for. This means Mosaic will need to be rewritten from scratch all over again, something Eric is not too excited to undertake since he spent the past year putting much effort and work into what it is now, though we do know that when the time comes it will need to be done. This is good news though since this will allow Blender users to render everything that can currently be done only in Blender (such as particles, animated curves and soft bodies). Currently Mosaic can output about %90 of what Blender can do natively, this is due to the limit of the data that Mosaic can access in Python. This of course is not a Mosaic only issue, ALL render exporters have this limit in Blender (with the exception of possibly Yafray). One of this sites goals was to prove to the Blender devs that having that external renderer support was a good thing, this will offer users a choice to use something they know rather than use just Blender's internal. Again we do not want to say Blender's internal render engine is bad, it is quite an amazing piece of coding and one of the best open source renderers out there. The issue mainly is choice rather than function and since most visual effects and animation studios use Renderman for the final frame rendering it would only make sense to have that option for Blender, thus making it more appealing to the high end market. This site itself has gotten the attention of many such studios and in the process some have even started to use Blender to Renderman for their own evaluation or even actual work.

So what does this mean for the future of this site? Well that is something we have a year to figure out. I do know that things will be changed, ideas are already being drawn out for the site itself though I do know this blog will be used in some form or other. I think our goal of public awareness has been achieved, that is obvious when Pixar, LucasArts, Blizzard, Dreamworks and more have stopped in on more than a few occasions. BlenderNation, BlenderAritst, CGTalk and even Blender.org have directed traffic here every single day. This site has gotten Animux some attention too, people who come here have gone to that Linux OS to check it out and in some cases are now working with them on various projects, including myself.

We have come a long way that is certain but we also have a long way to go.

Fisheye lens distortion using MOSAIC and Aqsis

2009-08-21T03:38:00.004+01:00

Greetings again Blender heads and RenderMan junkies :)

Well I've been hard at work with MOSAIC and recently needed a good test case for the volume shader I'm currently working on. It just so happened at that moment someone over at BlenderArtists inquired about lens distortion so I decided to do a test project and developer blog demonstrating lens distortion but also testing several area of MOSAIC. I've been asked to copy that blog to share with all the good people here also....

From the original developer blog here http://sourceforge.net/apps/wordpress/ribmosaic/

I've recently had someone at BlenderArtists ask whether MOSAIC could do lens distortions. Well since that's not a standard feature of Blender I have no built-in solution for this, however knowing this could be done I figured I'd tell him that RenderMan could do it easy and MOSAIC can set it up. As I was writing the reply I realized that I hadn't actually tried this myself and I'm currently needing an good project to test the new volume shader so... thus was born this fisheye project :) This post is not intended as a tutorial but just an overview of how I achieved this effect, I'll also include the blend if anyone wants to play with it.

Well the first thing I did of course is look around for examples of techniques, and as it so often turns out there's several different ways to do this. If looking for just mild image distortion/displacement then the simplest solution is to just use an image shader to process the image (the same as the post process filter in Blender's compositor). If looking for something more extreme such as the 360 degree fisheye effect then more radical steps are required. One approach is to use a warped plane in front of the camera and use raytracing with the surface normal refraction to fake the lens effect. Another technique, which I prefer, is to render the camera as a cube map in separate passes and then combine the maps into an empty beauty pass with an image shader. This approach can see distortions all the way around the camera, has fine tuned control over image quality and camera rotations and lens distortion and can even be animated with the same maps as long as camera translation doesn't change!

I found several example shaders but was surprised to find one written by my friend Chris Foster in the Aqsis example folder! I only made a few small changes to the shader for creative control:

I added a rather wide filter to the lens mask to blur its edge

I added the ability to flatten the distortion so the lensing effect can be pulled in and out of

I added the ability to rotate the forward vector in the cube lookup on x,y and z axises

The idea behind this technique is simple: use a cube map pass from the camera's position to generate cube faces, then in the beauty pass lookup into the cube faces with the image shader to project the warped perspective on the frame. The first step is to build a standard scene, I decided to use checker displacements on a ground plane and columns around the camera to emphasize the effect. I also decided to test faked soft shadows in a larger more complex space and also to include my partially rewritten volume shader to produce more daigonal light streaks for effect (the finished shader will be included in next CVS update). Next I added the fisheye image shader and created a shader fragment.

First off there's several tricks I had to play on the beauty pass:

Enable an empty scene layer. This is so nothing is rendererd except the image shader otherwise you'll waste time rendering object not seen.

Create and select a RIBset on the camera with the fisheye shader enabled. This is so the beauty uses the fisheye shader but we can force the default RIBset with no fisheye effect for other passes.

Next I created a User Autopass to use as the cube renders with a few filter options applied:

Blank the "Layers Scene:" filter. This is so we can specify what layers to use in this pass, otherwise it will use the beauty's empty layer.

Set "RIBset Bypass:" to DEFAULT. This makes sure the camera used from the beauty pass is not using the fisheye lens.

An autopass is necessary instead of just using a global env pass because better filtering can be achieved in Aqsis using textures then an env map. In this custom pass I made several custom scene RIBset's named as numbers from 0000 to 0005. Then I set this pass in the Project tab to use "RIBSETPASSES" so MOSAIC will export the numbered RIBset's as separate passes and ignore the DEFAULT RIBset. This is so I can use the same scene setup for each cube perspective. Then for each RIBset I used the "Show Autopass Settings" to setup the following:

For each RIBset I use one of each of the cube Camera: Perspectives (Object: nx, Object: px, Object: ny, Object: py, Object: nz, Object: pz). I use the Object instead of World perspectives so the cube faces are relative to the cameras orientation.

Setup each "file" display to point to ./Maps/ and use the name of each cube face, as "ny.tif", "py.tif" ect.

Setup the "Texture" dialog to convert each file display tif into mipmapped tex, as "ny.tif" - "ny.tex"ect. This is not strictly necessary but produces much better results with the image shader ;)

So at this point what's happening is the user autopass is exporting each RIBset using the active camera from the beauty scene with one of each cube face directions and optimizing them into one of 6 images. Now all that has to do done is pull up the fisheye shader in the shader editor and put in each of the images from the cube pass and adjust "thetaMax" to the distortion angle and render the beauty pass.

However since the cube faces can be reused in a simple rotational animation with minimal render time I decided to take things further and do a 20 second animation. Also since the cube faces are static I decided to try really high quality occlusion maps, shadow map with faked soft shadows, DOF and volume atmosphere shading. This is because the addition time needed to calculate these passes on the first frame are more then made up for by the really fast render times of the animation in the imager pass (it only has to grab the cube faces and calculate lookup direction and lensing). I also thought it would be interesting to synchronize settings across the pipeline from Blender to MOSAIC by adding animated composting effects and by using the same camera controls to drive multiple shader parameters in MOSAIC. In particular I'm animating the "lens" control on the camera and hooking that to the thetaMax shader control but also grabbing the same lens data and modifying it in a python token to control the lens distortion parameter and finally using the frame count in another python token to feed y axis rotation in the cube lookup. As a finishing touch I've animated a spectral lens distortion effect in Blender's compositor, this could fairly easily be done in the image shader but this gave me a chance to try sychronizing animation in Blender's compositor with RenderMan :) Anyway Here's the video, project file and a few frames of the animation from my gallery...

Here's the youTube video...

Here's a direct download of the mp4...
http://www.dreamscapearts.com/Public/fisheye.mp4

Here's a frame at 100 degree lens at 0 degrees rotation...

Here's a frame at 200 degree lens at 90 degrees rotation...

Here's a frame at 360 degree lens at 180 degrees rotation...

Here's a frame at 360 degree lens at 180 degrees rotation...

And if anybody want's to play with the blend here it is too.
NOTE: I embedded a modified version of MOSAIC that includes the Object:py-nz camera perspecitves that is not in CVS yet so you'll need to run MOSAIC from the text editor!!
http://www.dreamscapearts.com/Public/fisheye.blend

That's it, thanks for reading :)
Eric Back (WHiTeRaBBiT)

SIGGRAPH 2009

2009-07-21T22:25:00.005+01:00

I decided that with 2 weeks until this years SIGGRAPH convention that I should make a post about some of the behind the scenes talks between myself and the Animux devs. Since a lot of Blender to RenderMan integration has been done on the Animux distro, Mark Puttnam (the founder of Animux) has asked for some screencasts and imagery so that he can show this during his presentation.

So I decided that instead of just showing off normal screenshots of the default Blender startup screen, why not show something with some punch to it? Such as the one below, a simple test render done for Project Widow in early June.

So the idea is to setup and render at least static frames of Project Widow, if not maybe 10 seconds of animation of the spider, the tunnel system and the train. This not only would be the first official test of the pipeline, it will also serve as a small technical demo for the SIGGRAPH presentation. Most likely this preview will not end up in the final production short, much like Pixar did for the first Finding Nemo trailer. What this will do is not only draw attention to Project Widow itself, it will also draw attention to the whole Blender to RenderMan idea. SIGGRAPH has traditionally been the place to present "proof of concept" ideas and papers, showcasing new technologies and amazing artwork. So it only makes sense that after years of pain staking work trying to get where we are now that we at least begin to present our efforts at the biggest CG event in the industry.

The downside is that I am not able to attend this, I cannot afford it. I am not upset though since what we are showcasing is more of how Blender to RenderMan works with one OS - Animux, rather than how it can work for everyone. It just so happens that Animux is delivering us to SIGGRAPH. We could not ask for more publicity than SIGGRAPH anyway. If anyone does manage to get to New Orleans this year, please stop by the Animux Birds of a Feather meeting, take pictures too!

Monday, 3 August

Animux: Free Software for Animators
Animux is an absolutely FREE animation toolset that is used to handle all the tasks of pre-production, production, and post-production stages of a high-quality animation project.

Monday, 11 am - 1 pm
Ernest N. Morial Convention Center
Room 264
Mark Puttnam

The ball starts rolling

2009-06-03T05:43:00.003+01:00

Since the last post there has been quite a bit of activity on the net in relation to the Blender to RenderMan projects, chatter on websites and our group has seen a very large increase of posts. Seems that we are bigger than we thought, that our collective efforts are starting to get noticed and paying off. I for one can say that I have underestimated the effect and reach this website has. So I am taking this time to inform people some of the things that are going on around the world.

Animux
http://www.animux.org

This is a newer Linux distribution that I only recently found, why I only just found it I can't say, however from what I have seen on the website this seems to be much like my idea of having a Blender to Renderman Linux distro. Not only is this available NOW but they have been following this site. This is right up our alley! This is exactly what we've been trying to influence! Best part is that I don't have to do the hard part as I have never even tried to make my own Linux distro and I wouldn't know where to start. This is here now and only getting better.

So.... I am making an unofficial statement of which Animux would be considered as the Blender to RenderMan "primary" Linux distro. The reason is that they have established quite a bit to make it workable for artists and TD's alike, for all skill levels not just the Linux guru's. That was one of the main issues I felt was important. They also have quite a roster of people that are either developing it or advising, some of these people are very important to the success of the open source 3D movement.

One of the coolest things I have seen is their IKEA renderfarm how-to! This is something anyone could, and SHOULD build.

http://www.animux.org/wiki/index.php?title=Animux_Caseless_%22Ikea%22_Rackmount_Renderfarm

One aspect of the Blender to RenderMan pipeline that kind of got overlooked was Digital Asset Management, something of which is VERY important for any kind of studio. They are working on what is known as ADAM, short for Animation Digital Asset Management. They seem to be well on their way to something very special for us 3D artists.

That is all I can say about that right now ;)

"Project Widow"

This is very much an early announcement (something I was going to hold back for a little longer but got excited tonight over the Animux finding). Though if anyone has been in the forum group section, this really is not much of a surprise. This is a short 1-2 minute "test" that some of us have been pulling together, something that has taken off quite fast. This was started as a Blenderartist forum topic discussion where the debate over whether or not Aqsis was being used to render the new Blender Foundation Open Movie "Durian". Well no is that answer. Either way over the next week the subject kept coming up and somehow a test was thought up. But it is not like any normal test, this is a short story, very short but it is still a story and not just some walk cycle. I felt it was more important to use an original story to make our statement heard and that is Blender to RenderMan WORKS.

Over the next couple of weeks a LOT of progress has been made. We have Paul Gregory and Chris Foster from the Aqsis team backing us up, we are also using Aqsis 1.5.0 development builds to be the test bed for that version. They are helping us with the technical issues, we are helping them find some obscure bugs. We also have the help of WhiteRabbit (Eric Back) who is furiously busy writing the next version of Mosaic, again we are going to test that version out as well. We have a talented modeller, Daniel Wray, that has built the vast majority of our assets so far, including the main character model. We also have the help from Cedric, an animator. Not only that but we also have the help from a couple of concept artists and a sound fx engineer. We are still on the lookout for some more animators and RenderMan users. This week I am busy with my local film friend punch out the final storyboard so we can start blocking out camera shots. My own tasks are quite varied but it's been in the shading and TD area, writing the pipeline documentation and testing things in both Blender and Aqsis to make sure when we get to that stage - it will work without too much trouble.

The short is being done to test the pipeline, to put it through a real world situation that involves a number of people working together on different parts of the "production". The nice part about this short is that we are doing this over the internet, which also has made it very challenging.

For more information and to watch our progress as we plug along on this here is the website.

http://projectwidow.wikidot.com/

Things seem to be starting here and I have been wishing for this day for a very very long time, so it is nice to see a little progress here.

"It's a very exciting time!" - a quote from one of my favorite movies.

Blender to Renderman Artist Tools v 0.5 Released! (UPDATE!!!!)

2009-05-03T16:29:00.011+01:00

(EDIT: UPDATE! See below original post for more info!!!)

Finally this LONG awaited release has come! Sorry for such a long delay everyone, it has been a hectic year for me. Over the past 2 months I have been working hard on testing Blender 2.48 and the recent versions of Aqsis and Pixie to make sure that it can be considered "production stable", I have been on and off with making this ISO over the past year (to many people's dismay - sorry again) but so far with latest developments this looks good. Most of the tests I have done have been successful and I decided to finally put together this ISO for everyone to use, previous versions were not so bug free. I am listing it as version 0.5 because this is the fifth time I have undertaken such a task, the first time was just for my own use and each time since marked another "version" of this toolkit.

Anywho...... on to the goods!!!!

In this release are:

Compiled and sources of Blender 2.48, Aqsis 1.4.2, Pixie 2.2.5
Mosaic 0.2 Beta
Python 2.5.4 (installation for Windows - Linux already has it)
CGKit 2.0
Shaderman 0.7 and ShadermanNEXT
SLer
Shader sources (hundreds of them!!)
Shaderman shader projects
OpenEXR 1.4.0 (Windows install, Windows and Linux source)
OpenEXR 1.4.0 sample images
Dr. Queue (compiled and source)
Cutter
GIMP
Cinepaint (Linux only!! There is no recent Windows build)
Documentation from Pixars Online Research library as well as SIGGRAPH papers
Crimson Editor (Windows code editor)
Dev C++ and MinGW (Windows only, Linux has gcc which is the basis for all Linux builds)
Python scripts for Blender (various usefull ones not released with Blender)
Voodoo (for visual effects camera matchmoving)
Blender files (examples and test files)
Some usefull textures

This ISO is available HERE and we are also working on having it hosted elsewhere on a more permanent basis. This ISO is available free of charge, nobody is making money off of this at all, we have included all the required licenses (such as GPL and BSD). You are free to host this ISO and redistribute it as we have done so, we only require you to credit Blendertorenderman.org as original source since it has taken quite a number of man hours to test the software and put together the ISO. Please note that Pixar and ILM do have copyright information that MUST be included with the package, we do NOT want to upset these guys and it is only respectful that we do this since they pretty much influenced the industry and provided us with the means to do all of this.

Please note that while this is a "production stable" release, that there may be unforeseen bugs. Due to the nature of programming on different operating systems there is always the chance that something might be wrong. While this has been tested on Linux and Windows by myself personally, I have experienced some bugs here and there. That is the nature of the game, sometimes things get broken in the mix and there is a lot of code between all of the software. For the most part, and I mean %95 of the time, this release is stable enough for production, be it small studio or individual.

Also I am posting my updated Blender to Renderman Pipeline document originally posted in 2006. This has been revised to reflect current developments but is still being worked on and should be complete by late May, at most.

All the Development software for Windows like MinGW and DevC++ are to be considered AS IS! Like I said I am not a programmer but have included these into the ISO anyway, it is up to the end user to collect the necessary libraries and tools. I have not included any Linux libraries because it is easier to download them as needed from a repository, thus ensuring proper compiling of code. Any Linux programmer will be well versed in the trials of finding the right source if not found in repositories.

Lastly I want to thank the following people for their work and contributions towards this (of course not listed in any order).

Temujin
Eric Beck
Ildar Ahmetgaleev
Ton Roosendaal
Paul Gregory and the entire Aqsis development team
Okan Arikan
Alexei Puzikov (ShaderMan!)
Bobby Parker
Malcolm Kesson
Syoyo Fujita
Andrew Silke (for the original Generi Rig!!)
Larry Gritz
Saty Raghavachary
Tal L. Lancaster
Florian Kainz (for developing OpenEXR)
Robin Rowe

And everyone else who has joined our project, offered advice, testing and support!! Without everyone's encouragement none of this would be possible.

Oh yeah and thank you Google for developing superb software to host our site!!

UPDATE

Due to some oversight an update was required. Sorry for that and promise to not make the same mistake!

Changes :

Code:Blocks added to replace Dev C++
GIMP source added
Python source added
CGKit 2.0 source added
Blend files removed (plan to add it next update with BRAT stable models, some required too much initial setup and didn't render right)

Hosting update

For now a torrent file has been created for this update but we are still hosting the original ISO as well since not everyone uses torrent programs.

BRAT 0.5rc1 (original host)

BRAT Release Update 0.5rc2

RenderMan is a registered trademark of Pixar.
All other products mentioned are registered trademarks of their respective holders.
© 2009 Lucas Digital Ltd. LLC. OpenEXR, Industrial Light & Magic and ILM are trademarks and service marks of Lucasfilm Ltd.; all associated intellectual property is protected by the laws of the United States and other countries. All rights reserved.

Aqsis/Air Depth-Mapped Occlusion using multiple light rigs

2008-11-17T05:16:00.012Z

Hey gang :-)

The short version of this post...

I decided to do a 35 second video demonstrating multiple Depth-Mapped Occlusion maps using Aqsis :-D

Here's the low quality YouTube version...

Or you can download a 25meg high quality version here: http://www.dreamscapearts.com/Public/MultiOccDemo.mp4

The long version of this post...

I noticed a post last week over at Aqsis asking how to use multiple occlusion maps in large scenes or animations. This is something thats has crossed my mind several times while designing MOSAIC's render pass system but not something I've actually tested. Since the BBB shader work is going to be a lot of work and I've needed a little distraction (not to mention just wanting to use MOSAIC at least a little) I decided to do a little 35 second movie using multiple occlusion maps :-D For those of you who don't know ambient occlusion lighting is simply indirect ambient lighting usually from hemispherical directions such as the sky. In RenderMan there are several ways of achieving ambient occlusion depending on your renderer such as irradiance caching, photon mapping, point clouds (usually with in combination with other techniques), depth-mapped occlusion, and plain old light arrays. Depth-Mapped Occlusion is a technique specific to Air and Aqsis similar to a light array however the depth maps are combined into a single file and the file is fed into a shaderop that uses the depth data to figure occlusion shading on the surface. I'm particularly interested in this technique because I'm looking into very, very high resolution renders on a farm that require highly "parallel" techniques, that is the image is broken into many tiles but the tiles can't be rendered until the support data is calculated but usually only by one computer holding up the whole farm. With Depth-Mapped Occlusion each depth pass can be distributed to the farm so the entire farm can contribute to the occlusion data as well as rendering tiles which is more "parallel" in nature ;-)

I decided a good simple scene to demonstrate multiple maps would be a fly through of a city scape broken into blocks with a central subject. The objects of the scene would then be attached to groups and multiple occlusion passes would be generated filtering for each group. The reason large scenes need to be broken down into multiple occlusion maps is because of there scale, it becomes impractical to use a single really high resolution occlusion map for everything (to long to calculate not to mention file sizes). Its also beneficial to break them up for greater controls, such as baking the occlusion maps on the first frame in the background and only calculating occlusion for animation on the subject in the foreground, ect.

As a result of doing this project I've added several new features as well as tweaked several things in MOSAIC, however they are currently only in my developer copy and won't be available to CVS until I finish the shader work :-( Some of the things done for this project are:

Added the ability to use the "Enable Occlusion Mapping" utility in the "Scene Setup" tab to generate occlusion passes with user defined names.
The occlusion passes are now using the pass names for the outputted occlusion file so the user can know what its name will be for the shader parameter.
Made each occlusion rig in the occlusion passes unique so they can be edited separately, before MOSAIC only expected one occlusion pass for each beauty scene so the rigs where all the same :-s
Added the occlusion specific controls in the occlusion utility dialog to the "Scene Setup" tab so the occlusion setting can be edited form within the pass (since the occlusion utility can't be used for user named passes after there generated).
Added the ability to hide groups of controls in MOSAIC with toggles in the GUI so I could hide the automap controls to make the Scene Setup tab less cluttered

With these modifications its now possible to use any of the autopass utilities to generate custom user defined passes that can later be edited directly by hand, such as a env map pass thats used for multiple objects or a depth map pass used for multiple lights... the only drawback to doing it this way is the shader parameters have to be hand edited since MOSAIC uses the pass names to figure out how to hook pass display data to tokens in shaders :-s

To setup this project I created a plane and used the "discombobulator" script to quickly subdivide and extrude it into a city block. I then instance the block 3 times to create 4 side by side city blocks, each assigned to a different object group. I then created a cube and stretched it into a tower and instanced it twice to create 3 towers in the middle of the city and placed 3 instanced suzanne heads atop each tower, assigning the towers and heads to another group. Next I gave each city block a unique material and used a single unique material for the towers and suzannes shared (this is because each group will need separate occlusion file entries applied to the surface shader of each material). Then in I ran the "Enable Occlusion Mapping" dialog 5 times from the main scene, changing the "Pass Name" and assigning a different object group to the "Select Group" filter for each object group. I named the passes City1.om, City2.om, City3.om, City4.om, Suzannes.om using the object group for each. Once each pass was generated I them switched to each scene and adjusted the occlusion rig to properly surround the objects filter to each pass. Next I used the shader editors "C" button to copy the standard built-in ss_MOSAICsurface shader fragment into 5 new fragments called ss_City1, ss_City2, ss_City3, ss_City4, ss_Suzannes. Then I selected each fragment in the editor and changed the "OccMap" parameter of each from the standard <GetOccMap_S> token to the name of each occlusion file, the occlusion file names are created from the name of its pass with the frame number appended... so for the pass City1.om and its shader ss_City1 on frame one then the parameter should be "[ F1City1.om ]" or if you wanted to do animation you could use the frame token "[ F<#>City1.om ]". Finally I selected each of the 5 materials assigned to the objects and selected the appropriate suface shader for each, such as selecting the material for the first city block and selecting ss_City1 for its surface shader, ect. Then of course I added animation, motion blur, dof and intro-outro graphics to the video sequencer :-D

Anyway heres some screen shots of the basic setup:

the complete beuty scene...

here the City1.om occlusion rig...

here the City2.om occlusion rig...

here the City3.om occlusion rig...

here the City4.om occlusion rig...

here the Suzannes.om occlusion rig...

If anybodies wants to mess with this yourselves you can download the complete project here: http://www.dreamscapearts.com/Public/MultiOccDemo.zip

This zip contains the intro/outro graphics, blend file for Blender 2.48a and a developer copy of MOSAIC pre-loaded in the text editor (WARNING this developer copy of MOSAIC has broken texture support as it is not complete yet and you should NOT overwrite your own copy of MOSAIC with this one!!). To render the project execute the text copy of MOSAIC in the text editor, click "Render Animation" to render out all shadow, occlusion and animation passes (this took 4 days straight on my Core2 Duo 2.8 duel core 8gig ram). Once all frames are rendered into the /tmp/MultiOccPass folder then in Blender click ANIM to composite all tif frames, insert intro/outro and compile them into a mp4 in /tmp ;-)

Thats it... thanks for reading,
WHiTeRaBBiT

MOSAIC progress report on BBB related changes

2008-11-17T02:01:00.010Z

Greetings all,

The good fellows over at Aqsis have put forth a rather daunting challenge... to render at least a frame if not a small animation of the Blender Foundations "Big Buck Bunny" movie. At first I wasn't very keen on the idea but after considering it for a while I decided it would be the perfect project to really push MOSAIC's integration with Blender and its ability to efficiently export a large animation. Most of the work over the last few months have been related to getting MOSAIC and Aqsis capable of rendering BBB but because of the nature of MOSAIC's RenderMan design and its goals to do all things non-renderer specific these improvements will benefit all RenderMan renderer's using MOSAIC :-)

One of the first big challenges required rewriting key sections of MOSAIC to better handle large scenes and objects with large amounts of data. In particular MOSAIC was dying a horrible death when exporting large numbers of particles, hair strands or high density meshes. The problem was MOSAIC was storing all generated RIB archives in memory before writing to file, now MOSAIC generates and exports the RIB one line at a time (managing archive interactions through open file handles) thus file size is now only limited by the OS. I've also optimized many areas of MOSAIC related to instancing and RIBset passes making occlusion map animations as well as much larger scene animations possible (or at least not as painfully slow as before).

One of the next big challenges has been dealing with the painfully slow export times in Python when dealing with millions of strands of hair :-( I'm still planning experimenting with Python wrappers in the near future to squeeze faster export directly out of MOSAIC, although I'm not keen on complicating compilation and installation of MOSAIC for the user. A far more RenderMan like way of dealing with the problem is to use DSO's (dynamic shared objects) for generating any procedural like object such as hair. A DSO is C library object that can be dynamically loaded and executed by the renderer. These DSO's are capable of accessing the render state as well as calling functions from within the render and can use this information to generate and return RIB code to be rendered (such as growing hair on another object). The advantages of this approach are huge not only because MOSAIC doesn't need handle these large amounts of data but also because neither does the RIB files. This is a big deal for render farms since several hundreds of megs for a single hair RIB for a single character for a single frame will kinda slow down traffic on the network for a large animation :-s The down side to DSO's is they have to be properly compiled to use (something non-programmers will be intimidated by) and often times they call on renderer specific functions making them often times non-universal to other renderer's (unless carefully designed). In either case I have added a new series of controls so that code fragments can now be attached to individual particles systems and geometry materials indices's as well as a toggle to determine if the code fragment "replaces" the exported RIB. So in the case of the BBB hair problem you just make a code fragment to call a hair DSO, select the body mesh of the character and finally attach the code fragment to the particles system (toggling "R" on to not export any hair from MOSAIC). Chris (c42f) over at Aqsis is in the process of writing an excellent hair DSO that will eventually mimic enough of Blender's hair behavior to properly render several of the hairy characters, although I think it may be useful for grass or other such things with tweaking and maybe some modifications :-)

There are also several new modifications related to the DSO stuff mentioned previously. The exporter now always export particle and geometry RIB into a cache file that is always generated regardless of the archiving type of the object. This was originally done so DSO's that require a RIB of the geometry are always guaranteed one, but has several side benefits such as improved export times of motion blur and more efficient sharing or geometry data throughout the export system :-) The geometry cache RIB path/file name can be returned in a code fragment using the new <GeometryCache_S> token and particles cache RIB path/file name can be returned using the new <ParticleCache_S> token. Also there are some improvements to the token system for more flexibility in the returned token string. Originally the tokens were only designed for return values inside shader calls that are always in square brackets but this isn't very useful when in a code fragment. Now its possible to leave the type off to return a straight value or use the "_Q" type to return a quoted value. So for instance <Test_F> = [ 1.0 ], <Test> = 1.0, <Test_Q> = "1.0". Another big new feature added to help with DSO's in MOSAIC is the inclusion of what I'm calling Python tokens. A Python token is just a token including the name of a Python text loaded in Blender that writes RIB text into a global variable tokenReturn that MOSAIC then places in the export stream. So if you made a Blender text called "test.py" and put tokenReturn = "[ \"Hello World!\" ]" in it and then created a fragment and put a token <test.py>, then "Hello World" would be placed in the RIB that the fragment was attached to. This is mainly helpful for accessing data in Blender through Python that MOSAIC doesn't have a token for, such as accessing a control for a parameter to a DSO that MOSAIC doesn't have, it could also be very handy for procedurally generating RIB with python in Blender (although if doing something intense it would be better to use a DSO).

There are a few small changes made to MOSAIC to help with managing larger more complex projects. The "Generate Shader Fragment" utility now only lists shader source files instead of all shader sources and library shaders. This is because when dealing with a lot of shaders the menu was becoming to large to use. Instead I've added a "Fragment" button to each shader library in the "MOSAIC Settings" tab that allows you to create fragments for only those shaders in each library. This has not only the advantage of making the menus smaller but makes it possible to deal with shaders in logical groups. I've also added a "list all tokens" utility that will generate a text file called "tokens.txt" in Blender that automatically lists all MOSAIC tokens grouped according to there datablock and type using there full format, this is not only handy for seeing what tokens are available outside the shader editor but is great for copy/pasting tokens into code fragments ;-) I've also had to make several changes to how MOSAIC interprets dupli systems, in particular how it manages dupli groups conected to empties. This is important to how Blender manages content linked to external libraries in large projects and such.

Another big problem is how to deal with complex characters with multiple materials applied to the same mesh. Since standard RiSpec doesn't have a method for dealing with this in the past MOSAIC just separated the mesh where each material is applied however this process is slow to export and when dealing with SDS it is still required to export the entire mesh for each material (using hole tags so curvature matches between materials) making for very large RIB file sizes. MOSAIC now supports three different methods for separating materials using a control called "Material Set Mathod" located in the Geometry tab, the first two methods will work with all renderer's however the most efficient and elegant method will only work in Aqsis or Gelato, heres a breakdown of the pros and cons of each:

Separate Geometry
Separates the geometry per material either using Os 0/1 values for polygons or hole tags for SDS.
PROS:

the only benefit of this approach is it guarantees that all renderers and shaders will work with multiple materials.

CONS:

Since the geometry is copied for every material this can produce massive project sizes- Since the geometry is re-processed for every material this can be very slow to export
All that data ends up needing to be loaded into the render which consume large amounts of memory and will render slowly

Multipass Materials
Calls the cache with read archives per material using a user parameter in the geometry to adjust Os values in the shader per face.
PROS:

Requires the geometry only be processed once greatly increasing export times
Produces far less overall RIB size since geometry's only used once (unless datablock is set to "Inline Code")

CONS:

Requires that all shaders be modified to recognize the geometries user parameters, however this only effects polygons (particles are still separated)
Depending on the renderer still consumes large amounts of memory for each copy of the mesh per material
Still very slow to render since each material has a complete mesh even if its not visible per material

Layered Materials
This elegant approach will only work in Aqsis or Gelato and uses the user parameter in the geometry to shade or skip each face in a chain or layered shaders.
PROS:

Only requires the geometry to be exported once, so exports fast
Only requires the geometry to be loaded into the renderer once, so uses less memory
Only requires one geometry for all materials, so renders faster

CONS:

Will only work in Aqsis or Gelato
Requires all shaders be modified to recognize the geometries user parameters, and unlike the previous method will mess up both particles and geometry shading if not.

The last method required adding Aqsis/Gelato style layered shading support to the internal structure of MOSAIC so it was a small step to add user control of layered shading to materials. MOSAIC is using the concept of "chaining" Blender materials together to create layered shading for surface and displacement shaders. How this works is fairly straightforward, open up the materials tab and select the material you want to be the "root" material in the chain then select a material with "Next Material Layer" menu to link to, then goto that material and select another material to link to, so of so forth... All materials in a chain are exported together into each materials archive separately so multiple objects can intercept different parts of the chain.
You can also use the "Surf Output Variables" and "Disp Output Variables" to specify surface and displace output variables to use for the current materials shaders. If more then one variable is entered (separated by spaces) then separate connect calls are chained together for each so for example...

if Material.001 "layer1" used "a1 a2 a3" and called Material.002 and
if Material.002 "layer2" used "b1 b2 b3" then MOSAIC would export
ConnectShaderLayers "surface" "layer1" "a1" "layer2" "b1"
ConnectShaderLayers "surface" "layer1" "a2" "layer2" "b2"
ConnectShaderLayers "surface" "layer1" "a3" "layer2" "b3"

Also note that you can have varying numbers of parameters per control and can use None selections to disable export of certain shaders in a chain (such as only building a displace chain, or skipping a surface shader in a long chain).

Here's a simple example using all these features together. In particular this is demonstrating combining highly refined or integrated shader (such as MOSAIC's integrated shaders to Blender) with fast customized shaders (such as procedural shaders). This in my mind is a key benefit of layered shading because you don't have to re-create the shaders for every new surface (such as having to be sure every new shader can use occlusion, or env maps, or SSS).

At this point in development I'm finally at the point that I've begun to work on re-writing the built in shaders for more complete support of Blender's material system. I'm currently working on adding support for multiple layered textures using some if not all blending modes and UV layers. This is important because currently I can export the characters geometry into RenderMan (even using linked libraries) but without layered textures, alpha and layered UV's it won't be possible to get accurate renders of the charaters :-( The trickiest part wont be putting this together but getting the top 5 RenderMan renderer's compiling the shaders without problems :-s
Anyway I'm hoping this will only take a few weeks to do and if all goes well I also hope to add some fancy techniques such as better SSS support for skin and faked soft shadows using depth maps (should be considerably faster then raytracing).

Thanks for reading, WHiTeRaBBiT

Unexpected archive from the past

2008-11-13T05:36:00.003Z

While surfing the net tonight I ran across an old article that was archived on some server somewhere in the vast cyberspace. It caught my eye since I actually used to read this publication as a child so I clicked the link from Google and was reminded at how much time has changed the computer industry. Sometimes we forget the "good ol' days" and even I have to remind myself of this. Recently I was sort of griping about my "old" 1.6 Ghz system with 512 MB RAM running Linux, this page tonight kind of snapped me back into shape and despite it's shortcomings this little system built from spare parts isn't that bad....

For a little chuckle check this out.

http://www.atarimagazines.com/compute/issue135/88_Start_your_own_carto.php

Linked from Blender.org

2008-10-19T02:17:00.003+01:00

Today I got a nice message from ZanQdo, aka Daniel Salazar from Blender.org.

Hi, just added a link to http://www.blendertorenderman.org/ in the rendering section of this page

http://www.blender.org/features-gallery/features/

I'm impressed with your blog, keep up the great work

cheers

So now when you click on the Renderman (RIB) link in the features of the Rendering section, it goes directly to here. This is a first! To be on the Blender.org site is another breath of accomplishment, even though I had nothing to do with the code itself. Nonetheless I think our voice has just gotten a lot stronger. We will see what happens.

HAIR!!

2008-10-16T23:20:00.013+01:00

The developers of Aqsis and MOSAIC have recently been working very hard on correctly exporting Blender fur to Renderman and the results are paying off very well. One of the major issues with Blender and Renderman is that the particle system in Blender is difficult to work with and up until recently had been impossible. Since Blender's fur system is based on particle data there was only the ability to export a general description of the fur to the RIB file but no way to actually control the fur. This makes for some ugly fur, let alone hair.

Now there is a way to export Blender fur using guide hairs! A lot of it comes from a custom DSO that handles the generation of the hairs based on the guide splines, so it's not so much a part of MOSAIC but the script does make calls to it using fragments associated with a particular shader assigned in Blender. There is also work to allow the layered shader function of Aqsis (note: Aqsis is the ONLY RiSpec renderer capable of this, not even PRMan can do this!!), so this allows for even more interesting work.

One of the projects in the works is some talk about rendering the entire Big Buck Bunny short using Aqsis as the render engine with little modification to the scenes. However that is only a rumor and not set in stone. hehe.

To view the topic posts on the Aqsis site click HERE.

Blender to Renderman is now a domain!

2008-10-08T16:50:00.005+01:00

Google is awesome, simply put.

This blog is now www.blendertorenderman.org!!!

This morning I was checking this out on Google, the ability to have the blog as an actual domain name, which honestly is easier to remember than the blogspot URL that has been in action for most of the year. Best part is that the blogspot URL will redirect to the .org address so there is no need to completely redo any posts or links made in the past. That is awesome!

Plus it cost only $10 a year!

Blender To Renderman has been upgraded, tell your friends and family!

Blender Renderman Artist Tools Downloadable ISO soon

2008-08-16T05:51:00.005+01:00

This is a new approach to the spread of this project to the rest of the world. Tenzin and I have discussed the compilation of a downloadable ISO of the tools we use and are developing and call it BRAT - short for Blender Renderman Artist Tools. This was about 4 months ago, and after a brief moment of real life issues can continue to work on this. Soon there will be an ISO for Blender and Renderman.

The first will be an early release with tools, shaders, resources and such to test it's functionality and to test how easy to implement into an existing CG pipeline. All you need to do is just install the software and shaders and you are ready to go. So far it is almost ready for final release, just need to tie things up and give it a test run on fresh install of Windows before unleashed to the world and tested on Linux. There should not be any issues with Linux, the first pipeline using the current versions was being built on 64 Studio, a 64 bit Linux distro, and it worked just fine.

The next part of my project will create an installer of some sort that will setup the required programs, libraries and plugins to run pretty much out of the box without having to install and configure each and every one by hand. A pipeline setup tool for lack of a better term. That will be a bigger project that might not be seen until the end of the year.

More details will be outlined later, but expect this to be available for download early to mid September of this year (next month).

MOSAIC feature ramblings - part 12

2008-07-23T04:58:00.044+01:00

Part 12 - Mapping utilities tutorial:

This post represents the last of the MOSAIC feature ramblings series and will focus on actually building and rendering a simple scene using mapping.
In particular this tutorial will focus on the following tasks:

Build a basic scene in Blender highlighting RenderMan setup

Prepare shaders via materials

Set up MOSAIC

Set up an occlusion map pass

Set up an environment map pass

Set up a shadow map pass

Set up a caustic map pass

Set up camera DOF

Add, build and use RenderMan shader sources and fragments

Tweak RenderMan settings

Tweak shaders via MOSAIC's GUI

This tutorial will specifically target MOSAIC's mapping utilities to create advanced rasterization techniques, because of this I will be using Aqsis for this tutorial (since it's a pure REYES renderer). Before we begin be sure you have at least Blender 2.46, Aqsis 1.4 and CVS mosaic.py 1.39 or newer.

If you're impatient and, like me, just want to see the scene, you can download it here:http://www.dreamscapearts.com/Public/mapping.blend

Also the first image is the final render, so you can use it as reference for building your scene ;)

Building the scene

To start off with, we will need to build a scene in Blender keeping in mind a few details related to how MOSAIC and RenderMan work. To save a little time instead of outlining every step of this I'll just explain what's in the scene and show some scene shots. I'm assuming a basic knowledge of Blender if we're using external renderers :)

Here's what's in the scene, look at the pictures to the right for the layout:

1024x1024 UV test grid image saved as a tif.

1 mesh plane Scale 13.7x13.7, double sided, UV unwrap, with unique material.

1 mesh Suzanne Scale 2.1x2.1x2.1, double sided, smooth, SDS mod with unique material.

4 instances (alt d) Suzanne Scale 1x1x1, double sided, smooth SDS mod with unique material.

1 standard spot light, energy 1.2, color RGB 1.0,0.9,0.8.

1 standard camera with 35mm lens.

Now that we have the basic components and layout of the scene let's setup the RenderMan related settings. To start off with we need to assign the large Suzanne to a group, this is because later on we will assign it to caustic pass by itself.

Preparing shaders via materials

Next let's quickly outline the material settings:

For the plane use standard material :

Col RGB=1,1,1,

Amb=1 (sets occlusion),

Spec=0,

create image texture using tif image, disable map to Col, enable map to Disp, and set its Disp slider to 0.477 (this tells MOSAIC to use texture for micropoly displacements).

For big central Suzanne use standard material :

Col RGB=0.098,0.665,0.544,

Ref=0.709,

Spec=2,

Hard=309,

Amb=0.607,

RayMir=1,

Mir Fresnel=1.2,

IOR=1.3,

Transp Fresnel=2.0.

For the instanced Suzannes use standard material :

Col RGB=0.617,0.617,0.617,

Spec=0.184,

Hard=215,

Amb=1,

enable "Subsurface Scattering";
Scale=1,
IOR=1.3,
Error=0.05,
Col RGB=1,0.791,0,
Front=0.8,
Back=1.

One thing to note about the big Suzanne's material is you'll notice that we're setting the ray mirror and transp settings even though we're not enabling Ray Mirror and Transp. This is because if MOSAIC sees an environment map enabled on an object it will use its material's ray mirror and transp settings on the map as if it were raytraced. This allows more advanced control such as fresnel over the environment map. If an environment map is enabled you will need to first disable it before being able to use raytracing even if you enable the "Ray Mirror" and "Ray Transp" toggles (maps take precedence since they involve render passes to MOSAIC).

Just for a nice effect let's also enable some fog. Go to Blender's world material settings and set the HorRGB color to 0.289,0.542,0.817. Also enable "Mist" and set "Dist" to 30. The other default settings should work but you may want to play with them to get other effects :)

Finally we need to setup the camera for DOF by switching on the camera's Limits and adjusting the Dof Dist (yellow cross) so that it's near the front of the big Suzanne. This will tell MOSAIC where the focal point for the DOF will be.

Setting up MOSAIC

Now that we have the camera, lights, objects and materials setup now it's time to setup MOSAIC. Before we begin be sure to go to the "MOSAIC Settings" tab and make sure you have "Aqsis" selected in the preset menu.

In the previous posts I briefly mention the mapping utilities and several buttons related to this, let's describe this in a little more detail.

The mapping utilities collectively are just a series of buttons throughout MOSAIC interface that allow you to create and edit map related render passes. You can find these button connected to the thing they make a map for, such as occlusion maps with scenes, environment maps with objects, shadow and caustic maps with lights. Once clicked , you will be presented with a dialog that allows you to setup how you want the map to be generated and how you want its contents updated. When complete MOSAIC will generate a render pass entry in the "Project Setup" tab and a scene to use as the pass using the name of the object and a special extension as its name (such as lamp.sm, see post 5 for details). Once the pass is created the button for the utility will be pressed in (letting you know at a glance if the pass already exists), if you click on the utility button again the scene and all its render pass entries will be removed. You can click the "edit" button next to the utility buttons to edit an existing pass without destroying its contents. The mapping dialogs have a set of controls that are standard for all dialogs and some that are specific to the map type.

Here are some of the standard ones:

SizeX/Y - These are standard controls for all utilities and adjust the width and height of the map.

Use Shaders - This is standard for all utilities and if enabled the shaders for the scene are used in the pass. This should be turned on if the map needs to see displacement mapping or surface shader related transparency (for deep shadows, etc). This is best left off for faster render times unless needed.

Use Preview - This is standard for all utilities and if enabled the pass will use the framebuffer display (will popup a render window). This should only be enabled if you wish to see the passes render output.

Degrees/Scale - This is standard for all utilities and has different meaning depending on the object type. If this is an environment or point shadow pass then this controls the seams for the cube mapping, if this is a sun lamp then this is orthographic scale (usually good to start a 9 or so), if this is a spot light then it does nothing (lens determined from spot size). In the case of occlusion mapping this does nothing because the occlusion rig uses spot lights.

Shading Rate - This is standard for all utilities and sets the shading rate for the pass. This is by default set very high for lower quality but faster rendering (which is usually OK for support passes), set this lower for higher detail and higher for faster render times.

Group - This is standard for all utilities and combined with the other filter settings control how the generated pass is built from the beauty pass. MOSAIC creates the pass from the current scene which becomes the passes beauty scene, the filter settings at the end of all utility dialogs tell MOSAIC what to use from the beauty scene. Depending on the pass type, some of these controls are always forced to certain values and some are available to the user. This one (group filter), is the most commonly used and just tells MOSAIC to build this pass only from objects contained in the specified group.

Now that we've covered a little about how mapping utilities work let's use them to setup the passes for this scene.

Set up an occlusion map

Let's start by going to the "Scenes Setup" tab and pressing the "Enable Occlusion Mapping" button. The default setting for this should be fine.

Just in case you were wondering, here are what some of the controls do:

Hemisphere - This is exclusive to occlusion mapping and controls whether the occlusion rig is a hemisphere or a full sphere. MOSAIC does occlusion mapping by creating a mesh in the pass and dupliverting a spot light to it, thereby making a dome light rig.

Rig Segment / Rings - This is exclusive to occlusion mapping and controls the number of segment and rings used in the occlusion rig. The higher these numbers the more lights are used in the rig.

This will produce an occlusion map that Aqsis will use to calculate occlusion.

The occlusion color is set by the world's HorRGB color and its intensity is controlled by each material's Amb slider, just like Blender.

Set up an environment map

Next click on the big Suzanne and let's give her an environment map!

Once you've clicked on the big Suzanne go to the "Geometry Setup" tab and click the
"Enable Environment Mapping" button.

Unlike last time instead of using all defaults enable the "Use EnvDOF" toggle and set
"fstop" to 600.

This will produce a glossy like reflection by using DOF to make objects further away
blurry (in this particular scene it's not very visible so could be skipped).

Set up a shadow map

Next click on the light and go to the "Lights Setup" tab and press the "Enable Shadow
Mapping" button. The default settings should be fine for this, but note if we weren't
wanting displacements in shadows we could cut render times by disabling "Use Shaders".

Set up a caustic map

We also want to click "Enable Caustic Mapping" for this light but instead of using all the defaults set "Group" to "Group" (or whatever group you assigned the big Suzanne to
earlier).

We need to do this because by assigning a group to the filter, this pass will only use
objects in that group, in this case that's just the big Suzanne.

Since we only want caustics for that one glass object then this works well, if you were to
add more glass objects with caustics you would just assign them to the same groups.

Set up camera DOF

Finally the last thing we need to setup is the camera.

Click on the camera and go to the
"Cameras Setup" tab.

Enable the "Use DOF" toggle and
set the "fstop" to 240.

This tells the renderer to use DOF
and MOSAIC will set the focal point
to the camera's Dof Dist setting.

At this point we can now render a
basic scene but you'll probably
notice that the environment map
renders get "eyesplits" errors and
overall the rendering is slow.

Also the scene lacks the interesting procedural displacements.

Adding, building and using RenderMan shader sources

Let's go ahead and play with some RenderMan procedural shaders :) If you've installed a full version of MOSAIC you will have a folder in the installation called "shaders", let's use a couple of the shaders in there. In Blender setup a window to the "Text Editor", click "File" and browse to MOSAIC's "shader/displacements" folder and load two shader sources: "dented.sl" and "bubbly.sl". When shader sources are loaded into Blender's text editor MOSAIC can use them automatically, but in order to use them in the project we need shader fragments. To do this go to the "MOSAIC Utilities" tab and click "Generate Shader Fragment". Once clicked, select the "dented.sl" and "bubbly.sl" one at a time to automatically generate shader fragments for those shaders. Once shader fragments have been generated then you can select them in the "Shader Parameters" menu to manually edit them (and of course you can now use them in the "Materials Setup" tab).

Now that we have shader fragments let's edit them so they look like my example. Select "ds_bubbly" in the "Shader Parameters" menu and edit the following (including the square brackets):

Kd = [ -0.15 ]

bubsize = [ 0.5 ]

For the "ds_dented" the default values will be fine. Now that we have tweaked our shader values let's apply them. Select the big Suzanne and go to the "Materials Setup" tab (make sure this really is the material for the big Suzanne). Change the "Displacement Shader" entry to "ds_dented", this will apply the dented shader to this material which is applied to the big Suzanne. Next select one of the instanced smaller Suzannes, go to the material setup tab and change the "Displacement Shader" entry to "ds_bubbly". This will apply the bubbly shader to this material which is applied to all the instanced Suzannes.

That's it for using shader sources, very easy :)

Tweaking RenderMan settings

At this point everything should begin looking like the example render I've provided, but you're probably getting errors on the environment passes and things are a little slower than they should be, so let's look at optimizing this scene for RenderMan :)

Eyesplits happen when geometry passes through the eye plane of the camera (it helps to think of this as the near clip visually), when this happens the renderer has to continue to dice and split the geometry into finer pieces to create a clean edge. How many times this happens is controlled by the "eyesplits" control in the "Scenes Setup" tab, but you want to be careful because eyesplits are very slow and can usually be avoided. One of the first things to look for when getting eyesplits is whether the camera is too close to any geometry, when rendering environment maps the camera is placed at the center of where the object is (which is usually very close to other objects). To correct this one of the simplest things to do is decrease the DisplaceBound setting. The DisplaceBound setting basically extends the bounding box of an object to make extra room for displacement shaders, this is necessary because RenderMan renderers are really sensitive to the bounding box since it's used to determine how far to calculate the shaders. The bounds have to be manually adjusted because the renderer has no way of knowing how far the displacements are passing outside the bounds box. By default MOSAIC uses 0.100 for all objects which is actually very large (I did this so all displacements would work for beginners).

So, I said all that to say this, to remove the eyesplits error for the environment map and increase overall render performance change the "DisplaceBound" settings in the "Geometry Setup" tab for each object to these:

plane = 0.010

big Suzanne = 0.010

smaller Suzannes = 0.030

Another small tweak that can help performance depending on your machine and memory is to increase the "bucketsize" in the "Scene Setup" tab to 32. This determines how large each render bucket is and will usually use more memory the larger it is but render each bucket a little faster (up to a point).

Tweaking shaders via MOSAIC's GUI

Finally one of the last areas I want to discuss for tweaking the scene is manual shader parameters.

The built-in shaders that come with MOSAIC have several parameters that have no where to hook into Blender's interface.

One thing to keep in mind when tweaking these are that they are global in scope, this is because the same shader fragments are usually used by everything in the project (this is possible because tokens allow each object to pass different settings through the same fragment).

One way around this would be to copy the built-in fragment and apply it to the individual objects you wanted.

Here's some parameters on "ls_MOSAIClight" I've tweaked to improve the caustic effect by coloring, smoothing and adding a little procedural noise:

CausticAlpha = [ 0.7 ]

CausticColor = [ 0.0 1.0 0.6 ]

CausticSamples = [ 256 ]

CausticBlur = [ 0.12 ]

noisefreq = [ 1.5 ] (this turns on noise)

Well that's it, thanks to everybody who's encouraged me to continue writing these blogs (it's been a lot of work).

Also a big thanks for everyone who's played a part in making MOSAIC better, it's absolutely amazed me how people's ideas, encouragements and bug reports have made MOSAIC far better then I ever planned :D

Thanks for reading, WHiTeRaBBiT

MOSAIC feature ramblings - part 11

2008-07-19T03:23:00.019+01:00

Part 11 - The Materials Setup tab and raytrace attributes:

The "Materials Setup" tab allows you to control different aspects of how MOSAIC exports Blender materials.

MOSAIC uses Blender materials as the place to apply RenderMan shaders and attributes related to surface shading, in particular you can apply surface, displacement, interior volume, exterior volume and area light shaders as well as both integer and string based raytrace attributes.

Since MOSAIC exports all material associations to geometry including multiple materials per object and datablock, there is a wide range of possibilities.

Traditionally RenderMan shaders are applied to individual objects, but with MOSAIC you can apply shaders to materials and assign multiple materials to portions of the same mesh allowing much more complex setup and rigging. The exporter automatically separates the mesh into different objects to be shaded, when using an area light shader the geometry is placed with the light declarations before any other geometry (area light shaders are for true geometry based illumination and is not the same as the area light type which is only a light array).

The "Materials Setup" tab also has a set of attribute menus for setting the material's raytracing behavior. In RenderMan you can use these attributes to define whether a surface is visible to specular (shadows), diffuse (occlusion) and photons (caustics). There are two forms of these settings with varying support by different renderers, the older string type and the newer integer type (see your renderer's documentation for detailed instructions on how these attributes work). MOSAIC uses your renderer preset selection (in "MOSAIC Settings" tab) to automatically setup all new material settings to use the type best suited for your renderer. By default all options are on so you can immediately begin using raytraced shadows, occlusion and caustics :)

Since MOSAIC provides tokens that can hook Blender controls to shader parameters (see "Shader Parameters" in the "MOSAIC Utilities" tab) the built in shaders automatically use the most common Blender material controls. At the moment only the most important controls are linked, and not all of them behave the same as Blender... but after this series of blogs my next big project is to add almost all light, material and world controls into the shader system with near identical behavior :)

Here's a list of which material controls are currently hooked to the default shaders:

Halo (this will turn all geometry including hairs into point clouds)

HaloSize (this not only controls point size but also the base width for hairs)

Add (this controls hair tip width relative to base width)

HaloPuno (if enabled MOSAIC attempts to export normals for hairs to create ribbons)

Shadeless

Shad A

Col RGB

Spec RGB

Mir RGB

A (Alpha)

Spec

Hard

GR: (light groups do not use "Exclusive")

Tralu

Amb (this controls both hemi light and raytraced and mapped occlusion)

Emit

Ray Mirror (this will enable raytraced reflections but if "Enable Environment Mapping" is enabled on any object using this material it will be used for reflections regardless of this toggle)

RayMir (this controls both raytracing and environment maps)

Fresnel (this controls both raytracing and environment maps)

Ray Transp (this will enable raytraced refractions but if "Enable Environment Mapping" is enabled on any object using this material it will be used for refractions regardless of this toggle)

IOR (this controls both raytracing and environment maps)

Fresnel (this controls both raytracing and environment maps)

Sub Surface Scattering (this enabled a depth map based sss effect therefore it's recommended you use this with shadow mapped lights, however you can manually adjust the SSSWidth parameter for ls_MOSAIClight to get similar result with raytracing)

Scale (adjusts the SSS strength)

Radius R

Radius G

Radius B

IOR (adjusts the sss map blurring)

Error (adjusts the sss map bias)

Scattering color

Front

Back

Also the world "Ambient Occlusion" toggle enables a non cached raytraced occlusion using the worlds HorRGB color (mapped based occlusion is enabled in the "Scene Setup" tab independently of this toggle.

The surface shader also support texture channels. All "map to" channels are currently supported and work similar to Blender with one exception, only one texture of each channel type can be used for each material (I intend on changing this to match Blender's behavior by using arrays of texture names in the future). Something else to keep in mind with textures is that MOSAIC only supports the "image" texture type not any of the procedurals (that's what RSL is for), and that when loading an image you should probably stick with .TIFF since most RenderMan systems have problems with anything else. Also remember to use the "Texture Export Options" in the "Project Setup" tab to disable any textures you're not using.

Here's a list of which material texture controls are currently hooked to the default shaders:

UV (only uses this coordinate type, any other is default to primitives type)

ofsXYZ

sizeXYZ

All "Map To" channels supported

Disp (controls displacement map height)

That covers most of the high points of the materials tab so let's go ahead and list its groups and controls:

Navigation and RIBset management:
This group of controls is at the top of the tab and allows you to select available cameras, updating all controls and Blender selections accordingly. It also has controls for creating, deleting and selecting RIBsets for this tab.

Here's a breakdown of the controls in this group:

Select Material - This will show a list of available materials for selection, once selected it will update all controls in this tab.

Select RIBset -This will show a list of available RIBsets for selection, once selected it will update all controls in this tab.

Create New RIBset -This will create a new RIBset from the current RIBset control settings and select it.

Delete This RIBset - This will delete the currently selected RIBset and select the DEFAULT RIBset.

Code management:
This group of controls is for attaching user created code fragments (text files with the "cf_" prefix in their names) to the beginning and end of different RIB blocks. As with the previous group, this group of settings is available in various configurations for all the remaining tabs.

Here's a breakdown of the controls in this group:

Material Archive -This menu allows you to specify whether the exported RIB code for cameras is exported into separate RIB archives or inlined into the object RIB.

Material Begin Code - This allows the insertion of custom code fragments into the beginning of the material block before anything MOSAIC exports.

Material End Code - This allows the insertion of custom code fragments into the end of the material block after anything MOSAIC exports.

Shader management:
This group of settings is available in various configurations for all tabs and is for selecting shaders for the selected material.

Here's a breakdown of the controls in this group:

Surface Shader - This allows you to select a surface shader from a list of available system or loaded shaders.

Notes - This will display a popup of any notes attached to shader fragments by the author (usually containing information about which Blender controls are used by this shader).

Displacement Shader - This allows you to select a displacement shader from a list of available system or loaded shaders.

Int Volume Shader - This allows you to select an interior volume shader from a list of available system or loaded shaders. Volume shaders are similar to atmosphere shaders but for filling volumes of space.

Ext Volume Shader - This allows you to select an exterior volume shader from a list of available system or loaded shaders. Volume shaders are similar to atmosphere shaders but for filling volumes of space.

Area Light Shader - This allows you to select an area light shader from a list of available system or loaded shaders. Area light shaders are for turning geometry into true area lights, but are only supported by a few renderers and usually require special shader ops.

Options and attributes:
This group of controls is for setting material related options and attributes for this material.

Here's a breakdown of the controls in this group:

transmission - Is this material visible to transmission rays (casts shadows)? This control uses both the new integer style (on or off) and the older string style (sets how shadows cast through material such as "transparent", "opaque", "shader", "Os").

specular - Is this material visible to rays created by trace() (receives shadows)? This control uses both the new integer style (on or off) and the older trace command.

diffuse - Is this material visible to color bleeding and occlusion (new integer style)?

photon - Is this material visible to photons such as caustics (new integer style)?

camera - Is this material visible to the camera (new integer style)?

Shading Model - Which shading model to use when scattering photons (newer style)?

transmissionhitmode - How is opacity for transmission rays determined?

specularhitmode - How is opacity and color for specular rays determined?

diffusehitmode - How is opacity and color for diffuse rays determined?

camerahitmode - Allows you to control culling of geometry behind camera's visibility.

Use Material in Animations - This option allows you to manually take advantage of a "speed hack" in MOSAIC. This option can drastically improve export times in an animation for any material that is not animated. If enabled then MOSAIC will only export this material on the first frame of this animation and will then just re-use it without recalculating any of its data.

Flip "U" Tex Coor - This allows you to manually flip the exported "U" UV value for this material (handy when certain image formats are working but inverted in the U direction on your renderer).

Flip "V" Tex Coor - This allows you to manually flip the exported "V" UV value for this material (handy when certain image formats are working but inverted in the V direction on your renderer).

Shader MBlur - This enables the motion blurring of the material's parameters. This is particularly helpful for blurring displacement animations (if your renderer supports this).

frames - This specifies the number of frames to blur across.

Note : MOSAIC begins the blur by this number before the current frame so blur leads to current frame.

Well, that's it for the materials tab... next up a deeper explanation of using the mapping utilities :)

Thanks for reading, WHiTeRaBBiT

MOSAIC feature ramblings - part 10

2008-07-18T02:20:00.025+01:00

Part 10 - The Lights Setup tab and light export types:

The "Lights Setup" tab allows you to control different aspects of how MOSAIC exports lights. The exporter can handle Lamp, Area, Spot, Sun, and Hemi lights in much the same way that Blender does, making reusing existing scenes and creating new ones an easy task. MOSAIC's built-in light shader has built-in hooks to most of Blender's light controls, and have been designed to behave very similar to Blender's (When re-writing the built-in shaders I intend on enhancing this even further). For all lights the shader supports "Dist", "Energy", all "falloff" types, "Sphere", "No Diffuse", "No Specular" and light RGB color. If your renderer supports raytracing then MOSAIC's built in light and material shaders can use "Ray Shadow", "SpotSi", "SpotBl", "Soft Size", "Samples" and "Threshold" for soft raytraced shadows. For doing shadow mapping the shader supports "Buf Shadow", "SpotSi", "SpotBl", "Samples", "Bias" and "Soft". Also since Blender's Python API does not have hooks for light textures, there are several parameters in the light shader that can be manually set to use projection mapping and a few features not available in Blender.

Since MOSAIC handles shadow mapping with scene passes, setting a light to "Buf Shadow" does not create the shadow map or passes, in order to create the shadow map you need to use the "Enable Shadow Mapping" and "Enable Caustic Mapping" buttons in the "Lights Setup" tab.

Once clicked you'll be presented with a dialog that allows you to setup exactly how you want the pass created. This offers more control and fine tuning than Blender's built in shadow mapping is capable of (such as enabling deep shadows, fine tuning which objects are in the map, fine tuning shading rates and other optimizations, etc). It also allows you to directly manipulate the shadow pass since it's created as a Blender scene.

Once a pass is created then it is always preferred even if "Buf Shadow" is disabled or "Ray Shadow" is enabled, and you need to disable the "Enable Shadow Mapping" button to remove it.

Mapping controls and setup is a lengthy topic so I'll stop here and discuss it latter in another blog :)

A few other things worth mentioning is that MOSAIC can export cube shadow maps for the Lamp type (same thing as a point light), orthographic shadow maps for the Sun type (same thing as a distant light), Hemi light types control constant ambient light and color, Spot light types work just like Blender's and finally Area lights which export a diffused wide cone spot light array. This last type (area light) simulate Blender's area light by building a grid array of diffused spot lights with the same shape as Blender's area light. It uses the area light's "SizeX" and "SizeY" for the "Rect" shape and the "Ray Shadow" "SamplesX" and "SamplesY" for the number of lights in the array. This works for both ray traced and shadow mapped lights and since MOSAIC is building the light array (instead of the shader) you can even use your own shaders on this light type. Also because MOSAIC is using the "Buf Shadow" settings for shadow map tweaking and because Blender only offers these controls for the spot light type, you'll need to switch the light to spot to tweak these controls and then switch it back when using non spot shadow mapped lights. You can now also use lights in dupli systems and particles as raytraced or shadow maps, although if you use them in particles you will need to parent the particle emitter to the light in order for MOSAIC to see it. I should also mention that caustic mapping is still experimental and at the moment it does not take the shape of the occluding objects into account, only the shape of the inverted shadow with an option to control its blur, color, intensity and add noise.

Now let's begin listing the controls, I'll break them down by group explaining what each group does and then outline each control in that group.

Navigation and RIBset management:
This group of controls is at the top of the tab and allows you to select available geometry objects, updating all controls and Blender selections accordingly. It also has controls for creating, deleting and selecting RIBsets for this tab.

Here's a breakdown of the controls in this group:

Select Light - This will show a list of available lights for selection, once selected it will update the current active object selection and all controls in this tab.

Select RIBset - This will show a list of available RIBsets for selection, once selected it will update all controls in this tab.

Create New RIBset - This will create a new RIBset from the current RIBset control settings and select it.

Delete This RIBset - This will delete the currently selected RIBset and select the DEFAULT RIBset.

Light Archive - This menu allows you to specify whether the exported RIB code for lights is exported into separate RIB archives or inlined into the scene RIB.

Light Begin Code - This allows the insertion of custom code fragments into the beginning of the lights RIB archive before anything MOSAIC exports.

Light End Code - This allows the insertion of custom code fragments into the end of the lights RIB archive after anything MOSAIC exports.

Shader management:
This group of settings is available in various configurations for all the remaining tabs and is for selecting shaders for the selection.

Here's a breakdown of the controls in this group:

Light Shader - This will select a light shader for this light.

Notes - This will display a popup of any notes attached to shader fragments by the author (usually containing information about which Blender controls are used by this shader).

Pass utilities:
This group of controls is for creating specialty render passes related to this light.

Here's a breakdown of the controls in this group:

Enable Shadow Mapping - This will generate a scene and render pass entry for a shadow map for this light using the current scene as its beauty pass. There will be a future blog covering this in more detail latter.

Edit - This will pop-up the shadow map dialog for editing the shadow pass if it exists.

Enable Caustic Mapping - This will generate a scene and render pass entry for a caustic map for this light using the current scene as its beauty pass. There will be a future blog covering this in more detail latter.

Edit - This will pop-up the caustic map dialog for editing the caustic pass if it exists.

Options and attributes:
This group of controls is for setting object related options and attributes for this light.

Here's a breakdown of the controls in this group:

Use Light in Animations - This option allows you to manually take advantage of a "speed hack" in MOSAIC. This option can drastically improve export times in an animation for any light that is not animated. If enabled then MOSAIC will only export this light on the first frame of this animation and will then just re-use it without recalculating any of its data.

Use Transform - In many standard RenderMan shaders there are two techniques for passing the light's transform data to light shaders, by setting the light transform before calling the shader or by passing "to" and "from" parameters to the shader. For maximum compatibility MOSAIC and its light shader supports both methods. When enabled a transform will be setup before calling the light shader and "to" and "from" will equal (0,0,0) and (0,0,1) respectively, when disabled no transform will be used and "to" and "from" will equal the light positional data.

Light MBlur - This enables the motion blurring of the light's transform motion, that is the change in the objects position, rotation or scale.

frames - This specifies the number of frames to blur across.

Note : MOSAIC begins the blur by this number before the current frame so blur lead to current frame.

Well, that's it for the lights tab... next up is the "Materials Setup" tab :)

Thanks for reading, WHiTeRaBBiT

MOSAIC feature ramblings - part 9

2008-07-17T01:34:00.017+01:00

Part 9 - The Geometry Setup tab and geometry export types:

The "Geometry Setup" tab allows you to control different aspects of how MOSAIC exports geometry objects.

The terminology of the tab can be a little confusing, by "geometry" I'm referring to any Blender object that contains mesh, surface (patch), curve or particle data (I plan on adding blobbies later on).

Something else to keep in mind is that Blender handles this in two parts, the object (container) and the geometry data (datablock), even though MOSAIC's GUI is showing both in one tab.

MOSAIC follows this structure by exporting the object RIB and geometry data RIB separately, this allows efficient sharing of geometry datablocks by multiple objects. This is why you'll see two archive methods and multiple code begin/end menus in the tab.

This topic represents the absolute heart of MOSAIC's export code and I could discuss this in fine detail for weeks, so instead let me try to summarize which geometry and its data can be exported:

Mesh and SDS modifier geometry

Double/single sidedness

Object/per face smoothing

Object/per face solid (flat)

Per vertex colors

Per vertex UV coordinates

Per face normals

multiple materials per object

multiple materials per face

SDS edge creasing

Export of all modifiers (be careful about type and ordering)

Particles

Multiple particle systems per object

Export of Hair, Emitter and Reactor types

Supports child particles

Showing and hiding the emitter geometry

Hair, point, object, group and billboard visualizations

Surfaces (aka in RenderMan as patch)

Multiple patches per object

Multiple material code is in place but Blender does not support yet

Support for both "Uniform" and "Endpoint" UV knots

Support for control point "Weights"

Curves

Currently ONLY supports Bezier curves (natively supported by RenderMan)

Multiple curves per object

Multiple materials per object

Supports "extrude" for creating ribbons

Supports node "tilt" parameter for ribbon control points

Uses nodes "radius" parameter to further tweak per node extrude

Support for cyclic curves (periodic, some renderers don't support this)

Dupli Objects

Support for DupliFrames, DupliVerts, DupliFaces, and DupliGroups

Support for dupli lights and cameras

Support for shadow mapping on dupli lights (basis for occlusion rigging)

Duplis make automatic efficient use of RIB archives

Now let's begin listing the controls, I'll break them down by group explaining what each group does and then outline each control in that group.

Navigation and RIBset management:
This group of controls is at the top of the tab and allows you to select available geometry objects, updating all controls and Blender selections accordingly. It also has controls for creating, deleting and selecting RIBsets for this tab.

Here's a breakdown of the controls in this group:

Select Geometry - This will show a list of available geometry objects for selection, once selected it will update the current active object selection and all controls in this tab.

Select RIBset - This will show a list of available RIBsets for selection, once selected it will update all controls in this tab.

Create New RIBset - This will create a new RIBset from the current RIBset control settings and select it.

Delete This RIBset - This will delete the currently selected RIBset and select the DEFAULT RIBset.

Code management:
This group of controls is for attaching user created code fragments (text file with the "cf_" prefix in their names) to the beginning and end of different RIB blocks. As the previous group, this group of settings is available in various configurations for all the remaining tabs.

Here's a breakdown of the controls in this group:

Object Archive - This menu allows you to specify whether the exported RIB code for the object is exported into a separate RIB archive ("Read Archive") or inlined into the scene RIB ("Inline Code"). For this tab there is also a "Delayed Archive" selection, this uses the delayed read archive call which only loads the RIBs for the object in memory if its bounding box is on camera (great for animations with lots of objects).

Datablock Archive - This menu allows you to specify whether the exported RIB code for the datablock (geometry data) is exported into a separate RIB archive ("Read Archive") or inlined into the scene RIB ("Inline Code"). For this tab there is also a "Instance Object" selection, this uses the ObjectBegin/End blocks just before each frame block in the main RIBs for instance calls. These make efficient use of memory but are limited as to which RIB code can be used in them (see the RiSpec or your renderer's manual) and are not as efficient to export.

Object Begin Code - This allows the insertion of custom code fragments into the beginning of the object RIB archive before anything MOSAIC exports.

Geometry Code - This allows the insertion of custom code fragments directly in the object RIB after the objects geometry (if any). This is handy for creating custom geometry code such as using Quadrics by hand.

Object End Code - This allows the insertion of custom code fragments into the end of the object RIB archive after anything MOSAIC exports.

Atmosphere Shader - This will select an atmosphere (fog) shader that will only affect this object.

Notes - This will display a popup of any notes attached to shader fragment by the author (usually containing information about which Blender controls are used by this shader).

Also note that the built-in vs_MOSAICfog shader automatically uses all Blender's world Mist settings and uses the HorRGB color for the mist. This means that setting up and using the world mist should feel identical to using it in Blender.

Note : Immediately following this blog series I will be rewriting the built-in shader system so some shader related information may change.

Pass utilities:
This group of controls is for creating specialty render passes related to this object.

Here's a breakdown of the controls in this group:

Enable Environment Mapping - This will generate a scene and render pass entry for a environment map for this object using the current scene as its beauty pass. There will be a future blog covering this in more detail latter.

Edit - This will pop-up the environment map dialog for editing the environment pass if it exists.

Options and attributes:
This group of controls is for setting object related options and attributes for this object.

Here's a breakdown of the controls in this group:

Shading Rate - This will bypass the current scenes shading rate for this object only (0 uses scene's shading rate).

orient - This allows you to manually specify the geometry orientation as left or right handed (DEFAULT export nothing).

shading - This allows you to manually specify smooth or constant shading interpolation, see you renderer's docs for more info (DEFAULT export nothing).

para class - This lets you set which parameter class to use. These let you specify if "facevarying" or "facevertex" is used for UV and color mesh data which can produce very different result depending on your renderer.

DisplaceBound - This lets you specify how much displacement bound to use (0 exports nothing). This parameter is used by RenderMan to extend the objects bound box to make room for displacement shaders that push geometry out of bounds. This is necessary because most RenderMan renderers use the object bounds to limit shader calculations and will clip anything that falls out of bounds.

CoorSystem - This specifies the coordinate system to use for the displacement bounds, see you renderers docs for more info.

cull hidden - Whether or not to cull hidden primitives, see your renderer's docs for more info (DEFAULT exports nothing).

cull backface - Whether or not to cull backfaces, see your renderer's docs for more info (DEFAULT exports nothing).

dice binary - Whether or not to use binary dicing, see your renderer's docs for more info (DEFAULT exports nothing).

dice raster - Whether or not to use raster oriented dicing, see your rendere'rs docs for more info (DEFAULT exports nothing).

trace displace - Whether or not to raytrace displacements, see your renderer's docs for more info (DEFAULT exports nothing).

trace motion - Whether or not to raytrace motion blur, see your renderer's docs for more info (DEFAULT exports nothing).

Use Object in Animations - This option allows you to manually take advantage of a "speed hack" in MOSAIC. This option can drastically improve export times in an animation for any object that is not animated. If enabled them MOSAIC will only export this object on the first frame of this animation and will then just re-use it without recalculating any of its data. Even though this option is on by default (to eliminate confusion) you should always disable this for ALL objects not being animated for much improved export times :)

Extend Bounds Calculations - This is another speed hack and is disabled by default. Some RenderMan renderers require that particles and the motion of a motion blurred object within the shutter be contained in a bounds box. You can tell if this is the case if your renderer clips a motion blurred object or particles. The calculations for recalculating the bounds for these (especially for particles) can be excessive and not necessary for all renderers.

Transform MBlur - This enables the motion blurring of the objects transform motion, that is the change in the objects position, rotation or scale.

frames - This specifies the number of frames to blur across.

Note : MOSAIC begins the blur by this number before the current frame so blur leads to current frame.

Geometry MBlur - This enables the motion blurring of geometry motion, that is the morphing of vertices or control points of the geometry.

Warning : this can be very slow for dense geometry and it is recommended you stick with transform MBlur unless the geometry is morphing far and fast enough to actually see it blur.

frames - This specifies the number of frames to blur across.

Note : MOSAIC begins the blur by this number before the current frame so blur leads to current frame.

Well, that's it for the geometry tab... next up is the "Lights Setup" tab :)

Thanks for reading, WHiTeRaBBiT

MOSAIC feature ramblings - part 8

2008-07-16T01:30:00.016+01:00

Part 8 - The Groups Setup tab:

The "Groups Setup" tab allows you to use code fragments and atmosphere shaders with groups of objects instead of just one at a time. This can prove especially helpful when dealing with large and complex scenes with lots of custom fragment work. The exporter achieves groups in RenderMan by wrapping every object in a group in a single AttributeBegin/End block, allowing custom code to be entered at the beginning or end of the block. This ensures that any custom code entered in the block is pushed and popped off the render state so they will not affect anything else outside of the group.

The exporter handles objects in groups in a very simplistic manner, it cycles through each group exporting each object in the group only once. This means that multiple or nested group setups are ignored and each object is only used in the first group it belongs to.

Also note that lamps must be declared before all geometry (unless dealing with area light geometry), so lamps will not be apart of any groups (however lights can still be put in groups for the material GR: control).

The group selection menu will only recognize groups that have something in them (empty groups are ignored), and groups cannot use RIBsets (due to some internal complexities). The "Group Block" archive menu has options unique only to groups. By default this option is set to "Ignore Group" for all new groups and must be set to "Attribute Block" before the group will be exported (although the objects in the group will still export but not as apart of a group).

Let's illustrate a simple example of using groups for scene setup. Let's say you're browsing the 3Delight docs and see a SSS example you want to try.

The example shows some RIB source using an attribute like this:

Attribute "subsurface" "scattering" [ 2.19 2.62 3.00 ] "absorption" [ 0.0021 0.0041 0.0071 ] "refractionindex" 1.5 "shadingrate" 16 "scale" 0.2

You read that this attribute simply needs to be placed before any geometry you want to use SSS. To do this in MOSAIC you would simply create a new text file and name it something like "cf_sss" and copy the code in it, then select it in the "Object Begin Code" menu in the "Geometry Setup" tab for the object you want to use SSS, simple! Now let's say you like the effect but want to experiment with 30 objects switching SSS on and off them individually, but you don't want to have to turn "cf_sss" code fragment on and off each one individually. This is where groups come in. You can assign the objects to a group and then attach the "cf_sss" to that group's "Group Begin Code", using Blender to add and remove objects from group without ever having to touch MOSAIC making experimenting much faster :)

Now let's outline the controls for this tab:

Navigation management:

Here's a breakdown of the controls in this group:

Select Group -This will show a list of available groups for selection, once selected all controls in this tab will update.

Code management:
This group of controls is for attaching user created code fragments (text file with the "cf_" prefix in their names) to the beginning and end of different RIB blocks. As with the previous group, this group of settings is available in various configurations for all the remaining tabs.

Here's a breakdown of the controls in this group:

Group Block - This menu allows you to specify whether to export the RIB code into an attribute block or completely ignore the group.

Group Begin Code - This allows the insertion of custom code fragments into the beginning of the group attribute block before anything MOSAIC exports.

Group End Code - This allows the insertion of custom code fragments into the end of the group attribute block after anything MOSAIC exports.

Atmosphere Shader - This will select an atmosphere (fog) shader that will only affect the objects in this group.

Notes - This will display a popup of any notes attached to shader fragment by the author (usually containing information about which Blender controls are used by this shader).

Well, that's it for the groups tab... next up is the "Geometry Setup" tab :)

Thanks for reading, WHiTeRaBBiT

MOSAIC feature ramblings - part 7

2008-07-15T02:11:00.026+01:00

Part 7 - The Cameras Setup tab:

The "Cameras Setup" tab allow you to set various properties of the camera for export. This tab will only work with Blender camera objects and will not be available for lights or objects set as active cameras, anything other than a camera as active camera is considered a specialty render pass and is setup in the "Scenes Setup" tab. The exporter automatically uses these camera controls under the Blender camera object "editing" tab:

Lens/Scale - Uses both the lens size and degrees as well as scale (for ortho).

Orthographic - Uses both standard and orthographic perspectives.

Dof Dist - Dof distance is used for the focal point if DOF is enabled in MOSAIC.

Dof Ob - Works by default from Blender.

Start - Just like Blender this sets the cameras near clipping.

End - Just like Blender this sets the cameras far clipping.

Something else to note is some RenderMan renderers can use something called a imager shader that can process both the background and entire render buffer. MOSAIC by default uses the built-in imager shader that simulates Blender's World background settings, although currently it only uses the HorRGB color to fill the background. After this blog series is complete I intend on rewriting the built-in shaders to fully simulate Blender's background settings (if possible). The imager shader can be applied to the camera (meaning different cameras could use different imager effects), and the the render pass scene setup tab so environment maps can match active camera.

The cameras tab is fairly straight forward so let's go ahead and list its groups and controls:

Navigation and RIBset management:
This group of controls is at the top of the tab and allows you to select available cameras, updating all controls and Blender selections accordingly. It also has controls for creating, deleting and selecting RIBsets for this tab.

Here's a breakdown of the controls in this group:

Select Camera -This will show a list of available cameras for selection, once selected it will update Blender's current selection and all controls in this tab.

Select RIBset -This will show a list of available RIBsets for selection, once selected it will update all controls in this tab.

Create New RIBset -This will create a new RIBset from the current RIBset control settings and select it.

Delete This RIBset - This will delete the currently selected RIBset and select the DEFAULT RIBset.

Camera Archive -This menu allows you to specify whether the exported RIB code for cameras is exported into separate RIB archives or inlined into the scene RIB.

Camera Begin Code - This allows the insertion of custom code fragments into the beginning of the camera block before anything MOSAIC exports.

Camera End Code - This allows the insertion of custom code fragments into the end of the camera block after anything MOSAIC exports.

Image Shader - As mentioned previously this selects the desired imager shader for this camera.

Notes - This will display a popup of any notes attached to shader fragment by the author (usually containing information about which Blender controls are used by this shader).

Options and attributes:
This group of controls is for setting camera related options and attributes for this camera.

Here's a breakdown of the controls in this group:

Camera MBlur - This enables camera motion blur.

frames - This specifies the number of frames to blur across.

Note : MOSAIC begins the blur by this number before the current frame so blur leads to current frame.

Use DOF - This enables the depth of field effect (uses the Blender's camera Dof Dist control for focal point).

fstop - This sets the RiDepthOfFeild "fstop" parameter (see your renderers docs or the RiSpec for more details).

focalL - This sets the RiDepthOfFeild "focal length" parameter (see your renderer's docs or the RiSpec for more details).

Shutter min - This sets the RiShutter "min" parameter (see your renderer's docs or the RiSpec for more details).

Note : if set to 0 RiShutter will not be exported.

Shutter max - This sets the RiShutter "min" parameter (see your renderer's docs or the RiSpec for more details).

Note : if set to 0 RiShutter will not be exported.

Well, that's it for the cameras tab... next up the "Groups Setup" tab :)

Thanks for reading, WHiTeRaBBiT