ILM and Sony Imageworks release Alembic OSS

"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

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

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

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)