Wednesday, July 28, 2010

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.

Sunday, July 25, 2010

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.

Tuesday, July 20, 2010

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.