Ptex and the Open Source Community

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)

Update!! - RenderAnts - Interactive REYES Rendering on GPU

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.

Labels

Labels to apply, so posts can be searched by topic.

Blender to Renderman tools :

blenderman, neqsus, btor, blenderpixie, blenderlucille, ribkit, ribber, sler, svat, ribmosaic, blendergelato, blenderpbrt, luxblend

Renderers :

prman, bmrt, entropy, 3delight, rdc, air, angel, aqsis, pixie, lucille, gelato, pbrt, luxrender

RenderMan terms :

rib, rsl, shader, dso, shadeop

This post might be edited to add more.