Sunday, January 29, 2012

Pixar and Greenbutton reveal RenderMan On Demand

In 2010 Pixar had demonstrated RenderMan running on MicroSoft's Azure platform, as reported here, 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 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 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 yet the two are completely different entities.

The question I have is, why not start something like this for Aqsis, or Pixie? 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, 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 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 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 but in communication with so that if this works and tests well, then maybe it can be added to the 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!

Monday, January 02, 2012

Cinepaint Developments

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.


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.


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.


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.


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


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.


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.


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.