Rudy's Spot

A new journey

Rudy — Wed, 09 Jan 2013 17:51:20 +0000

I have been lucky enough to have achieved one of my life long dreams, to work on VFX/Animation for films. As much as I always loved and enjoyed visual effects, I have always had a complete fascination with animation. Thats how my journey into this field started as I initially wanted to be an animator.

Days came and went and I realized that I had a more natural inclination towards the technical aspects of CG production, so naturally my career took a deviation and I became a Technical Director. However my love and admiration for animation have never dwindled. Of the different animation mediums available, stop motion has always been among my favorites. The artistry and craftsmanship of each set, background, prop and characters is something that has always intrigued me.

So I started reading and learning about the different ways that puppets and sets can be built as well as reading on how cameras can be controlled for shooting. After enough reading I have decided it is time to take the plunge. So here we are at the beginning of a new journey for me. I dont know how long this new hobby will last, but I am sure having fun. Here are some pics of my current state in pre-production.

Web Dev Portfolio

Rudy — Tue, 08 Jan 2013 06:45:23 +0000

I have been writing websites for personal use for quite a while now. In the process of writing websites, I have played with different frameworks and languages, of which PHP and Wordpress have become my platform of choice.

Below are some samples of the different websites I have developed.

www.lumativ.com

Design: Scott Campbell
Programming: Rudy CortesWebsite for a new startup company specializing in self illuminating, rechargeable clothing.

www.alexacuisine.com

Design and Programming: Rudy Cortes

Website for Chef Alexandra Mata (my dear wife)

I Had a Leak!

Rudy — Tue, 27 Sep 2011 22:39:07 +0000

Equinox, my little renderer, is slowly making progress. I had reached a point where I could render a simple shape (a sphere) which had its own transformation matrix. Having a working renderer that supports a pinhole orthographic camera and a sphere, I figured this was the perfect time to try to do something that I had never done before, Multi-threaded programming! I will discuss the multithreading portion of Equinox on another post. At the moment I will like to cover a nasty little side effect that poped out out of nowhere (as usual) and bit me square in the ass!

Equinox was already rendering an array of spheres, granted the render times where higher than expected, but at this point this was expected. I usually concentrate on getting my code to work, before I concentrate on optimization. This is a common practice in software development. I was implementing the multi-threading when I saw that using 8 cores did not give the render any significant speed up. I opened the activity monitor window to track the processor usage and to my surprise the eight working threads would only pickup the first 8 buckets, afterwards only two or three threads would be performing calculations. No wonder I was not seeing much of a speed up. What a strange behavior I thought. But even more surprising was the memory usage.

As I saw the threads act all weird, I also saw the memory usage sky rocketed to 1.6 GIGS! Something was severely wrong as there is no way a single EXR image and 20 spheres would use so much memory. It seemed that I had just ran into what is known as Memory Leaks. This is something that I had never really had to deal with in the past. All scripting languages that I had ever used handle dynamic memory allocation and deallocation. Languages such as MaxScript, Mel, HScript, RSL, PHP and Python they all do automatic memory management. Even In C++, I had used constructors and destructors, which also performs memory management.

As you might have read, Equinox is being developed in C, which means the programmer (that would be me ) is 100% in charge of all memory management. So I put on my “CSI” hat and I began to dive into the code, hoping to find where I was leaking memory. After a little bit of digging I was able to track the issue to this function:

void EiProcessBucket(EtBucket bucket, Rgba *px) {
    extern EtWorld world;

    int x,y;
    for (int y = bucket.pos.y; y < bucket.pos.y + bucket.height; y++) {
        for (int x = bucket.pos.x; x < bucket.pos.x + bucket.width; x++){
            EtCameraInput camIn;
            camIn.x = x;
            camIn.y=y;
            camIn.xres=world.film.xres;
            camIn.yres=world.film.yres;
            EtCameraOutput *camOut = EiCameraOutput;
            EtCameraMethods *cammtds = (EtCameraMethods*)world.cameras->mtds;
            cammtds->createRay(world.cameras,camIn,camOut);

            float r,g,b;
            int j;
            g = y / (float)camIn.yres;
            r = x / (float)camIn.xres;
            b = 1;
            for (j = 0; j < buf_len(world.shapes);j++) {
                EtNode *shape = &world.shapes[j];
                EtShapeMethods *mtds = (EtShapeMethods*)shape->mtds;
                if (mtds->intersectP(shape,camOut->I)){
                    r = g = b = 1;
                    }
            }
            // (y * camIn.xres) + x makes sure the pixel
            // values are stored in scan lines
            Rgba *p = &px[(y * camIn.xres)+x];
            p->r = r;
            p->g = g;
            p->b = b;
            p->a = 1;
        }
    }
}

I started by commenting out most of the lines in the inner loop. I left only this code inside the loop:
   EtCameraInput camIn;
   camIn.x = x; camIn.y=y;
   camIn.xres=world.film.xres; camIn.yres=world.film.yres;
   EtCameraOutput *camOut = EiCameraOutput;
   EtCameraMethods *cammtds = (EtCameraMethods*)world.cameras->mtds;
   cammtds->createRay(world.cameras,camIn,camOut);

   float r,g,b;
   int j;
   g = y / (float)camIn.yres;
   r = x / (float)camIn.xres;
   b = 1;

I ran the code again and I saw that the memory usage had dropped from 1.6 gigs to 100 mbs. Huge improvement, but still not what it should be. I see that I am not manually allocating any memory into the heap and that all my variables are on the stack. This seemed to tell me that I dont really have a memory leak, but I am consuming way to much memory. I analyzed the code a little longer and spotted the what I though was the problem. For every pixel of the image I am creating a new variable of type EtCameraInput and a new pointer to a EtCameraOutput. This looks bad, I moved the declaration of such variables to outside of the double “for” loop. This greatly reduced memory consumption, however it still did not feel as the right answer to the problem.
The stack should deallocate “camIn”, “camOut” and “cammtds” once they go out of scope, so this cant be the issue. I looked at the code and found this line to be quite interesting:
//
//
EtCameraOutput *camOut = EiCameraOutput;
//
//
In an effort to write a framework that would allow me to write faster code, I had written this pre processor macro.
//
//
#define EiCameraOutput (EtCameraOutput*)malloc(sizeof(EtCameraOutput))
//
//

So I was allocating memory on the heap and I was not deallocating It. Once again, I seem to conspire against myself by trying to be a little too smart. Maybe using such shorthand macros is not such a good idea. I re-arranged the code to what is listed below and the memory usage dropped to 3 mb.
void EiProcessBucket(EtBucket bucket, Rgba *px) {
        extern EtWorld world;

        int x,y;
        float r,g,b;
        int j;
        Rgba *p;
        EtCameraOutput *camOut = EiCameraOutput;
        EtCameraMethods *cammtds = (EtCameraMethods*)world.cameras->mtds;
        for (int y = bucket.pos.y; y < bucket.pos.y + bucket.height; y++)
        {
            for (int x = bucket.pos.x; x < bucket.pos.x + bucket.width; x++)
            {
                EtCameraInput camIn;
                camIn.xres=world.film.xres;
                camIn.yres=world.film.yres;
                camIn.x = x; camIn.y=y; 

                g = y / (float)camIn.yres;
                r = x / (float)camIn.xres;
                b = 1;
           ......
           ......
           }
       }
       free(camOut);

Next I uncomment the lower part of the loop, the part where the intersections are actually performed and vroom, memory usage again launched to 1.5 gigs! There is a very serious memory leak in this block of code. After a good amount of digging I found that the code responsible for the memory leak was the intersectP method in the sphere shape. Inside this function I am performing several operations to apply the transformation to the shape. Here is the code that handles the transformation
    EtPoint pos = EiNodeGetPnt(node,"center");
    EtMatrix m = EiNodeGetMtrx(node,"matrix");
    EtMatrix mi;
    EiMatrixInvert(&m,&mi);
    // create a transform
    EtTransform xf = EiTransform(m);
    // create a trasform for the center
    EtTransform xpoint = EiTranslate(pos);
    // Multiply the object transform by the pos
    EiTransformMult(&xf,&xpoint);

I commented lines of code one by one and I realized that the issue was in EiTransformMult. I opened the transform module and I found 2 variables that where dynamically allocated and where not being deallocated at all. Here is the old code
void EiTransformMult(EtTransform *aa, const EtTransform *bb)
{
    EtMatrix *mat = malloc(sizeof(EtMatrix));
    float *mm = (float*)mat;
    float m[16];
    EtTransform *tmp=malloc(sizeof(EtTransform));
    float *a = (float*)&aa->m;
    float *b = (float*)&bb->m;

    ......

    memcpy(&tmp->m,&m,sizeof(float) * 16);
    EtMatrix mi;
    EiMatrixInvert(&tmp->m,&mi);
    memcpy(&tmp->mInv,&mi,sizeof(float)*16);
    memcpy(aa,tmp,sizeof(EtTransform));
}

First of all, one of the allocated pointers (*mat) is not even used anymore, so I deleted it. The other pointer, *tmp, is never deallocated. I added a free(tmp) at the end of the function and voila! The renderer memory usage now stays at a mere 3mbs per render and as a side effect, now using 8 threads greatly improves the render times. A scene that takes 71 seconds to render on 1 thread, takes about 20 seconds with 8 threads. Here is an image rendered with the latest version of Equinox.



So keep an eye open for those malloc()s while programming in C. Remember to always deallocate whatever you allocated or evil leprechauns will spawn and consume as much memory as the can get your hands on. Oh, and like a good friend told me once, dont try to be too smart or over complicate things with C. It is already super simple, which makes it super powerful.

The Importance of Technical Knowledge

Rudy — Mon, 26 Sep 2011 23:36:54 +0000

CG production is an exciting career. Just look back at the changes that have taken place over the last 10 years and im sure you will realize how fast this industry moves. This industry of ours, so new, so fresh, so desired. Every year at Siggraph I see a large river of young new comers, eagerly applying for the scarce few openings that are available here in the USA.

Amazing how things have changed. I have met plenty of seasoned artists who have shared their stories. They remember how back in the old days (the 90s), big studios would snatch up anyone who had just a little bit of CG training. The demand for CG was so hi and the available talent pool was so small, that studios would pretty much open their doors to anyone who was willing to learn.

I became obsessed with the industry in 1999, effectively missing that sweet window of opportunity by about 4 years. By the time I had reached a level of mild competence, the industry had exploded! Nemo, Monsters, Shrek, Lord of the Rings, The Matrix had all been released and people where flocking in mass quantities to Siggraph. The lines to drop off demo reels at the ILM, Pixar, Imageworks, Digital Domain and Dreamworks booths where huge!

It was Siggraph 2001 and I managed to get acquainted with some industry heavy hitters. Being the young, eager beaver that I was, I kept trying to get information on what would be the best way to break into the industry. One of the industry veterans from Digital Domain, told me; “Learn RenderMan and scripting, for one animator opening, we get 20 to 30 reels, but for 10 technical openings we get 2 reels”. That conversation pretty much changed my life, as I went back home and completely changed the focus of my CG training. Instead of studying how to become an animator, I would learn RenderMan and scripting. Such career change eventually paid its dividends and I am glad to have the technical knowledge that I have. It has opened so many opportunities as a TD with good technical knowledge is always sought after by employers. Granted, I still have so much to learn, but that goes with the territory, as being a TD is a never ending learning journey.

Fast forward 8 years. The industry is very mature by now, the amounts of work being done is huge, with a talent pool that is even bigger. There are hundreds of extremely talented CG artists out there, all competing for a limited number of jobs available. This has made getting into the industry extremely hard. The amount and level of competition, for even the simplest entry level jobs is way higher of what it used to be. With such an environment, it is essential that new comers find a way to differentiate themselves from the rest.

While running TD College, I was lucky enough to meet may young talented artists. There was one in particular that caught my attention. This young artist had sinked a small fortune (around 90 thousand US dollars) into his education. He had received an internship at Pixar and graduated with very good grades. However, a year after graduation, he had still not landed “the” job that would place him in the industry. This artist enrolled in our “Python Programming” course. A course that lasted only 6 weeks but it covered a lot of very important programming concepts. The course was all taught in python, a language that has become the most popular for scripting in the CG industry. With 6 weeks of training, he was able to walk into interviews with new found confidence, applying for positions that he was not even considering before. Well, very soon he landed a job at IMD, then ILM and at the moment is at Dreamworks Animation. How much did he learn in those 6 weeks? Not much im sure, but he did learn enough to get him into the industry. These days this young artist is learning and growing by leaps and bounds, constantly improving his CG skills.

Our industry is a weird mix of talents. So unless you are a complete bad ass on your art, be it modeling, animation, lighting, texturing or else, your chances of breaking into the industry will be a lot higher if you are able to bring some technical knowledge to the table. What kind of knowledge? Here is a list of things that I believe will help anyone trying to enter the industry:

Python: The most used language for scripting. Easy to use, easy to learn but soooo powerful. Python will allow you to script for pretty much every major CG application in the market, as well as develop quick pipeline tools.
C/C++: The most used language in the industry. The APIs for most CG programs is usually in C++. If you want to develop plugins for Maya, Nuke, XSI or Houdini you will need to learn C++. If you want to write shaders for MetalRay, Arnold or VRay, you will also need to use C++
Linear Algebra: Learn how to use vectors,points and matrices. Give special attention to vector operations such as cross and dot products. Learn the properties of vectors as well as the operations when you mix types (point + vector). Learn the properties of matrices.

So dont be afraid of programming or math, they are after all, the backbone of our industry and the stronger your understanding the more productive you will be able to become.

“Take the Red Pill …

Rudy — Fri, 02 Sep 2011 03:49:45 +0000

..and ill show you how deep the rabbit hole goes” – Morpheus.

One of the coolest lines from one of my favorite movies, The Matrix. So why do I bring this up? Well In the process of writing Equinox I had to implement transformations, which of course means dealing with matrices and linear algebra.

I have used matrices in the past as they are one of those things that you will have to deal with as a TD, specially a shader TD. If like me, you did not have the luxury (or the debt) of a university education on computer science or engineering, then matrices might be intimidating and it might be one of those things that you avoid constantly until you are cornered and you can not dodge them any more.

As I stated earlier, matrices are a necessity in the TD world, but do not dispair, you can use them without really understanding the math theory behind them. To use matrices all you need to do is understand the output and uses of the most common matrix operations. Lets examine matrices a little closer.

What is a Matrix?

From wikipedia: “In mathematics, a matrix (plural matrices, or less commonly matrixes) is a rectangular array of numbers, symbols, or expressions. The individual items in a matrix are called its elements or entries. The horizontal and vertical lines in a matrix are called rows and columns, respectively”. The following is a picture of a generic definition of a matrix.

A Generic Matrix

Matrices are used a lot in day to day activities. Perhaps one of the most unseen use of matrices are spreadsheets, where if you select a large range of cells and perform an operation on them, the application is performing matrix operations.

How Are they Used in CG?

One of the most common uses of matrices in CG are transformations. Matrices, specially homogeneous matrices, are elegant data types for these kinds of operations. They are used extensively because a 4×4 matrix (homogeneous) can represent any of the most used afine transformations such as translation, rotation, scale, skew and reflection. This means that software developers have to deal with a single “entity” to handle all their transformation needs instead of having to use vectors for translation, scalars (floats) for scales and 3×3 matrices for rotations.

I.D. Please!

We will not get into much of the math behind matrices on this tutorial, and we will not look at the different matrices used in CG transformations. There is however one matrix that we must cover as it is extremely important for the current tutorial to make sense. This matrix is also essential in many transformation manipulations.

Give this matrix a good look:

: Identity Matrix

You see it has 0 on every spot of the matrix except for the numbers that make up the diagonal from top left to bottom right. This matrix is known as the identity matrix and it is special because it represents a transformation set to Translate(0,0,0), Rotate(0,0,0), Scale(1,1,1). So when you create an object at the origin of the world, its transformation matrix is the identity. If an object is parented to another, and its transformation is the exact same as the transformation of the parent, then the child’s local matrix is also the identity.

Multiplying a matrix by its inverse will always result in the identity matrix, so to move an object to the origin you would multiply the objects world matrix by the inverse of the object’s world matrix.

We will not go into the details of how matrices are calculated as I usually like to go over how something “can be used” before I go into “how something works”. Lets take a look into some of the uses for matrices.

Note: All code examples are done in Blender, but the concepts should be applicable to any CG software.

Apply the transformation of an object to another

This is probably one of the simplest uses of transformation matrices. Just store the value of the source in world space and apply it to the destination object.

#
#
dst.matrix_world = src.matrix_world
#
#

Find the position of an object in relation to another

Need to find an object’s position in relation to , lets say the renderig camera? Then just invert the world matrix of the camera and multiply it by the world of the object.

#
# Make sure to perform this operations in this order as
# A*B != B*A
#
camera.matrix_world.inverted() * object.matrix_world
#
#

Convert Z-up to Y-up Coordinate Systems.

This is something I had to deal with when writing a RenderMan exporter for 3DS Max. Back on those days I did a lot of “juggling” to make things work. For instance when I got the transformation of an object in the form [x,z,y], I would shift the elements to [x,y,z]. This might seem easy but once rotations, and position of vertices had to be exported, the code got a lot uglier.

I ran into the exact same issue lately when writing BtoA. I am pretty certain that the previous versions of Blender used to use Y-up, but on the latest (2.5.x) it is using Z-up. Arnold on the other hand allows you to specify left or right handed worlds, but they are both Y-up. If you analyze the problem, you will realize that rotating the object 90 degrees on the X axis will make Y point up. Depending if you are converting to a left or right handed coordsys, you might need to rotate by -90 degrees. With a simple matrix multiplication we can solve the issue.

#
# Create a new matrix that is rotated -90 degrees
# on the X axis
#
mrot90 = Matrix.Rotation(math.radians(-90),4,'X')
# multiply the rotated matrix by the world matrix of
# object to be exported
#
newMatrix =  mrot90 * object.matrix_world
#

Freeze Transformations

Maya and several other 3D apps provide a way to freeze or reset the transformations of an object. Sometimes this is very useful, specially if you want to make sure that your object has a “starting point” in the scene that is an identity transform matrix and not some random numbers. A freeze transform on a mesh can be applied by:

Multiplying the object’s world matrix to each point in the mesh. This will give the appearance that the object has moved, but its pivot point is still in the same location, because we actually moved the points, not the coordinate system of the object.
We then multiply the objects matrix by its inverse matrix to get rid of the double transformation and move the points back to their original location. Now you will see that the transformations are back to the identity.

# Capture object to an easier variable
p = bpy.data.objects['Plane']
# Get the matrix and the inverse matrix
m = p.matrix_world
mi = m.inverted()
# Apply the matrix to every point in the mesh.
# This will apply a "double" transformation
# to the whole mesh
for i in p.data.vertices:
    i.co = m * i.co
# Multiply the object matrix by the inverse,
# officially setting the xform of the object
# to the identity and getting rid of the
# double transformation
p.matrix_world *= mi
#

 but wait a minute, the pivot point of the object is no longer where it was, lets take a look at how we can change the pivot point.
Center Pivot
To center the pivot point to an object we need to follow the following steps:

Get the center of the object’s bounding box in world space (cworld)
Find the position cworld in relation to the pivot point of the object (cwToPiv)
Multiply every point in the mesh by the inverse of cwToPiv. This will center the mesh points to the pivot point.
Apply cworld as the matrix of the object to move it back to its original location

# quick access variable
c = bpy.data.objects['Cube']
# get the bounding box. Blender calculates it
# in object space
b = c.bound_box
# get the min and max of the bounding box.
# through exploration I see that the min is
# at b[0] and the max is at b[6]
vmin = Vector([b[0][0],b[0][1],b[0][2]])
vmax = Vector([b[6][0],b[6][1],b[6][2]])
# get the center of the bounding box. This
# is still in object space
cent = (vmin + vmax) * 0.5
# make a matrix with the center point
cm = Matrix.Translation(cent)
# make a new matrix of the point in world
# space.
cworld = c.matrix_world * cm
# Get the position of cworld in relationship
# to the pivot point. See above how to do this
cwToPiv = c.matrix_world.inverted() * cworld

# multiply every point by the inverse of
# cwToPiv
for i in c.data.vertices:
    i.co = cwToPiv.inverted() * i.co
# Now apply the bounding box center
# in world space to the world space
# of the object
c.matrix_world = cworld
#

Of course we can use this technique to se the pivot point to anywhere in the bounding box of the object. All we need to do is use a little math to set the value of cent (rename the variable to be easier to read). Everything else should after that point should be the same

Multiple Objects (and an API)

Rudy — Thu, 25 Aug 2011 16:08:18 +0000

Moving forward. Made a little more progress on Equinox. One of the things that I disliked the most about renderran was the fact that it was kind of hard to create new scenes. specially for those not familiar with the code. The way the code was written you could only create objects by making instances of them, knowing where to place them in the code and how to access their parameters. I talked with some more experienced programmers about how I could make scene creation easier. I was thinking about creating file format that I could parse. My friends recommended that I first create an API, and since I was writing the code in C, I could then create some Python bindings with ctypes. I thought these where great ideas since I have never written a rendering API and never written python bindings for C. Even more learning to do!

I have seen on several rendering APIs that there is usually a “begin” statement. For RenderMan it is RiBegin(), Arnold has AiBegin so naturally I wanted Equinox to use EiBegin(). This placed me in a spot that I had not been before. I new that EiBegin would do a lot of initialization of the necessary defaults for a scene to be rendered. Things such as default resolution and image output. I also knew that I needed a “world” structure. A structure that would hold the data of my rendering world, such as an array of lights, materials, textures, cameras and objects. I gave other APIs a look and I saw that none of them passed a world structure around to every function. This being the case, I realized that I needed the world to be global variable.

I am sure that at some point I will need other global variables so I needed to figure out a way to create global variables when someone used the Equinox api. The goal was to be able to do this:

#include "equinox.h"

int main() {
    // Initialize the Equinox rendering environment
    EiBegin();
    ....
}

Getting the global variables to work was a bit tricky. I wanted the global variables to be created automatically so I created a Globals.h file. This created som issues mainly because I would get redefined symbols if I placed the global file in any of the source files that would end up in my equinox library. I did some reading and consulting and I figured that I needed to make sure that Globals.h was only included once and only in the main file. Everywhere else all references to my global variables would just need to use the “extern” keyword. The commit for these changes can be found on github. Here is an image generated with the very early API.



and here is the code that generated the image
#include "equinox.h"

int main() {

  EiBegin();
  // Create the camera
  EtNode cam = EiNode("ortho_camera");

  int i;
  for (i = -250; i <= 250; i+=50) {
    EtNode sph = EiNode("sphere");
    EiNodeSetFlt(&sph,"radius",25.f);
    EiNodeSetFlt(&sph,"zmin",-25.f);
    EiNodeSetFlt(&sph,"zmax",25.f);
    EiNodeSetPnt(&sph,"center",i,0,0);
  }
  // start the renderer
  EiRender();
  return 0;
}

Introducing Equinox

Rudy — Sat, 20 Aug 2011 18:12:54 +0000

Some time ago I began to write a little ray tracer based on the book “Raytracing from the Ground Up“. The book proved to be very easy to follow and before I knew it I had a little program that could generate images. I continued to push the rendering engine until I was able to get several interesting images. The project was hosted on google code and a blog for the raytracer was hosted on blogspot. Here are some of the images i was able to generate with it.

Eventually I wanted to implement more features into the renderer, but as I went through the code I realized that it was very messy and hard to extend, even though I had used objects (C++) to write the code. I started to read other rendering books and I decided to have another go at the renderer. This time I would start from scratch but I would build a plugin based system. I would concentrate on building a core rendering engine, a rendering API for describing scenes and a plugin API to extend the renderer as needed.

I began to read on how to implement a plugin architecture and a lot of the information I found mentioned that it is better to implement the plugin part in C and combine the code with C++. I began to talk with several co-workers about how to approach this project. Slavomir Kaslev, a very talented developer at Blizzard Cinematics, convinced me to write the whole system in C. I analyzed his proposal and even though I knew that C++ and objects would make things a bit easier, learning C is something that has been on my list for a long time.

So straight C it is! Boy what a decision it turned out to be. I was immediately amazed with how much “magic” languages such as C++ and Python perform behind the scenes to make the developers life easier. I decided to merge different concepts from different renderers and books I have read. I liked the Arnold C API and their node based approach. Being that my renderer would also be C, Arnold proved a good inspiration for the API. Since I dont have source code access to Arnold, and even if I did I would not want to use it ( that work belongs to Marcos and Solid Angle ), I decided to use PBRT as a base for most of the calculations, but at one point I would try to get away from the “physical” aspect of it and try to develop different integration and rendering methods.

It took me a lot of work, a lot of errors and a good deal of consults with my C mentors to get to a point where I could generate an image. At the moment I am still working on the plugin API, trying to decide what goes where. In the mean time here is the first image generated with Equinox.

BtoA – Blender to Arnold

Rudy — Sat, 20 Aug 2011 04:55:27 +0000

Some time ago i was lucky enough to get on the beta of Solid Angle’s Arnold renderer. This is a renderer that caught my eye back in 2000, when a short film named Pepe was all the rage at Siggraph. I managed to acquaint Marcos Fajardo, founder and lead developer of Arnold. Back then I was extremely excited over the fact that Arnold would be included with PMG’s Project Messiah.

Years went by and Arnold kind of disappeared from the public eye. Then, out of nowhere it made a big come back when it was chosen as the renderer for Monster House. Since then Arnold has grown by leaps and bound. Little by little it has begun to penetrate the industry and several small and big studios are beginning to jump on board.

Once I got into the beta, i was anxious to play with the renderer. Problem was that the only available turn key solution was a plugin for XSI. Since I dont own a copy of XSI, I started looking at what other options are out there. I found that Solid Angle was also working on a Maya exporter, but it was still to early in development for my taste. I figured the best way to learn a new renderer and its API would be to write an exporter. Thats how I learned RenderMan so it must also work with other renderers, right? Since I didn’t want to duplicate efforts done by others in the community I decided to do an exporter for Blender.

BtoA for Blender 2.49

I began to write the exporter for Blender 2.49. I must say that Blender’s Python API made things quite simple. Things where pretty straight forward except for the GUI. Writing a gui for Blender pre 2.5 was a royal pain in the ass! I got it to work, but it was not pretty. Since I knew that Blender 2.5 was about to hit beta, and the Python API was going to be completely updated, I decided to stop development until 2.5 was closer to release.

On that first attempt I took a RenderMan approach where I would write out an .ass file and then invoke kick (the cmd line renderer) to render the image. As I said before, this worked, but once I tried to render a very heavy scene, the export would take 7 minutes while the render would take only 8 seconds. Needles to say, I had created a huge bottle neck. For this reason I decided to try to write directly to the process using the Arnold python API.

Here are some of the images that I was able to render from BtoA 2.49

BtoA 2.59

Blender 2.5x went alpha, then beta and finally at version 2.57 I decided that it was time to do a retake on the abruptly abandoned exporter. I was extremely surprised, almost giddy, when I read how easy a new renderer could be integrated, how users could easily extend the system with new classes and how now I had python access to the GUI! I was pretty happy with most of what the Blender community had done. So now time to look at Arnold again.

I opened the docs and gave the API another read. Then I went through the python code provided by Arnold. The python bindings looked pretty good, but i still had no idea how to write anything with it. As I dugg deeper through the code samples from all of Arnold’s open source projects, (yeah, open source!! thats so smart of them!) I had gathered enough information on how the task could be executed. I began to recode using the Python bindings of the Arnold API. Getting a file to render to disk was pretty straight forward, but figuring out how to render to the render buffer proved to be a bit harder. Thats when Angel, from Solid Angle, stepped in to give me the necessary guidance to get the system working.

Here is a screenshot if the current version (0.1) of BtoA

and…..we’re back!

admin — Mon, 15 Aug 2011 02:38:16 +0000

After 6 years of patiently waiting for those darn cyber squatters that took ownership of rudycortes.com to give up on the stupid idea of making money from me, I finally was able to recover it. Now I have enrolled in auto renew of the domain, so I hope this is the last time I have to deal with these sort of issues.

So what has happened over the last 6 years?

Moved to San Francisco, California to work at The Orphanage on The Day After Tomorrow and Sky Captain and the World of Tomorrow.

Moved to Texas to work at DNA productions on The Ant Bully.

Niky was born.

Moved to Burbank, California to work at Disney Animation Studios. Got hired for Rapunzel (Tangled) but did work on Meet The Robinsons and a Goofy 2d short.

Started TD-College with some fellow TD’s/Entrepreneurs.

Left Disney to go work on effects at Digital Dimension. The same year DDimension closed its doors and landed a freelance job at Uncharted Territory for Roland Emerich’s 2012.

Published a RenderMan book.

Celebrated my 10 year wedding anniversary.

Finally had enough of the craziness of the VFX industry and looked for a change of scenery. Ended up moving AGAIN to Irvine, California to work at Blizzard Entertainment in the cinematics department.

Closed TD-College

At the moment im working on a couple of research projects. Always working on improving my skills and become a stronger TD.