The Audi Rubix commercial we worked on here at Digital Domain was nominated for a VES award for "Oustanding Visual Effects in a Commercial."
AUDI - Intelligently Combined
Jay Barton, Visual Effects Supervisor
Rafael F. Colon, Sr. Compositor
Chris Fieldhouse, Visual Effects Producer
Ronald Herbst, CG Supervisor
Here is the commercial itself.
http://www.youtube.com/watch?feature=player_detailpage&v=AFHk3JU_pcs
Friday, January 22, 2010
Thursday, January 7, 2010
Project Challenge: Disney Jungle
I had the pleasure of working on a very cool spot for Disney recently. The project was called "Jungle" and it was our job to take many of the animals from the world famous Disney jungle boat ride and do photo real CG head replacements for them so that they could be made to talk in the commercial. On this project I was the lead lighting artist and assistant CG supervisor. Near the end of the show I had to step in as CG sup when my good friend Richard's (senior CG sup on the project) wife went into labor.
Right off the bat I knew this project was going to test me. It was entirely character work which I've done very little of over the years. My first task was to model the face of the baby gorilla who at the time had the most dialog in the entire spot. So I put my character modeling skills to the test and modeled up the little guys face. My second task was to model the zebra's heads which also had a lot of dialog and we would see some close up shots of them. After the models were approved I moved onto morph targets. All the while we had two other artists modeling the other characters. In total we created 3 gorillas, 1 zebra, 1 lion, 1 lioness, 1 elephant, 1 tucan, 1 giraffe and 1 wildebeest. The models and lookdev was moving along very smoothly. There was just one problem at this point. We were never budgeted to do fur. All of these animals were actually rubber animatronics so they didn't have fur on their faces. The only exception to that was the zebra's manes and some whiskers on the lions. So I set out to find a way to create the fur. At first I went with a simple approach of using a bunch of cards with hair strands mapped on them. This was ok...but it really didn't look too realistic. We didn't have a fur solution that we could render in Maya/Vray so we needed to come up with some way of creating geometry that we could style and use. That's when I remembered my good friend 3dsmax. I took the zebra model into Max and used Max's hair and fur tool to create the zebra's mane. The bummer was that in Max the hair and fur tool does not create uv's...I just uses the color of the texture the hair is grown from to give the hair its color. Since I needed this to get rendered in Maya, I needed UV's so that I could have the black and white zebra stripes. I exported the geometry back to Maya and in a side view I planar projected UV's...Then I went in by hand and selected all the hairs that grew out of the black stripes on the head and moved their UV's to one side of the UV layout and all the white hairs to the other side of the UV layout. Then a simple texture map that was black on one side and white on the other was used to created the diffuse color of the hairs. This approach looked a million times better than the cards, but it was a longer render. It also allowed us to get backscattering on the hair and make them translucent.
Our pipeline had recently been given a major overhaul and we now had tools in place that made bringing in characters and animation into our lighting scenes a snap. It was literally a 3 click process for each character in the scene and you were ready to go. The lighting was all done using HDRI probes that were taken on set in Disneyland. A few extra area lights were used in some shots, but for the most part it was just a vray dome light with the HDR mapped to it.
midway through the project we got an updated cut of the commercial and realized large portions of the spot now had new dialog, characters that were not originally talking now had tons of lines and the characters that were talking the most before no longer were. This required us to go back in and create lots more morph targets and also look at what turned out to be the biggest challenge on the spot...The wildebeest.
The wildebeest was only ever intended to have one line...He was to say "huh?" We planned to do a 2d warp of his mouth in Flame, but now this character was saying all kinds of stuff. So we now faced a huge problem...This characters head is totally covered with scraggly hair. His lips barely were visible through his mustache. This now put a huge burden on our Flame artist and several of us 3d guys set out to create a mouth with morph targets that we could use to replace the lower half of the wildebeests head. We though maybe we could get away with only replacing the lower jaw. This worked ok, but it didn't look right that the upper jaw and nose did not deform at all (because we were just seeing the original plate photography). So we decided to try camera mapping the plate onto a larger model that included the upper jaw and nose as well as the lower jaw. This turned out to be really tricky to make look right. It even required us at one point to scrap the model and morph targets we had and start over. We needed our CG model to match as closely as we possibly could to the actual wildebeest in the plate. We eventually got it and started cranking out elements to pass to Flame. In Flame we still had a lot of 2d warping to do to marry the CG and the plate properly. In the end I think it turned out pretty well for having such a short amount of time to do it in, and never having planned or budgeted for this character to talk.
With our new pipeline tools in place the project went very smoothly. We were able to build shots and update them in no time. Even rebuilding a shot from scratch only took a couple minutes. At the end of this project the senior CG sup had to hand the project over to me when his baby was born. So the last weekend of the project and final delivery was in my hands. By that point everything was pretty much done and it was just down to the wildebeest shots. We delivered the project on time and I'm very proud of the team and the work that we did. Its one of my favorite projects that I've worked on during my time here at DD.
Tim
Friday, July 31, 2009
Project Challenge: Audi "Rubix"
http://www.youtube.com/watch?feature=player_detailpage&v=AFHk3JU_pcs
In this project challenge I'm going to cover my experience working on a commercial for Audi. At the time of writing this the commercial was not released and I do not have a link to it. Hopefully I'll get a link sometime soon after its release. You have to see it to appreciate it I think.
In this commercial we were asked to do every raytracers worst nightmare. Create a photo-real 9x9x9 glass rubix cube full of car parts in a photo-real CG environment. Then animate the cube rotating around and assembling the car as it spins until the car is completely built. For anyone keeping score...A 9x9x9 grid of boxes means that we had 729 cubes, each with at least one object inside it and most of them having several objects. Each individual cube had realistically modeled sides made of glass, which means we were seeing through a minimum of 36 panes and even more if viewing from an angle. So...729 cubes, made of 6 objects each. At least 3 times as many part objects. That put us at 26,244 nodes, just for the geometry of the cube and parts. Once you throw in the nodes for the environment and cube rig I can't even come up with that number...but these were some HUGE files to work in. Probably the most complex I've ever worked with.
When the project began I was one of the first modelers/lighters to start on it. There was a lot of uncertainty about what the environment should be like. It needed to not distract from the cubes, but also look good in its own right. Myself and two other lighters modeled up rough environments with temp glass cubes in it every day for a week or two. All similar but also quite different. As things progressed the environments that kept getting the most response were the very simple plain white rooms. In the beginning these all had white artificial lighting and no natural light sources. We went this direction for a long time, but when you put a glass cube in an evenly lit white room it disappears. We needed to have contrast in the scene in order for the glass to look like glass. I was pulled off of the environment for a week or so while the client, director and supervisors all worked out what they thought the environment should be. I was put on the task of creating the cubes and their glass shaders. At first I went with a totally realistic approach. I modeled all the sides of the glass cubes and stuck them up against each other. I put a realistic glass shader on them and hit render. Now I've never seen an actual 9x9x9 glass rubix cube before so I was a little suprised at first to find that the center of the cube was very dark. It was like the light just couldn't penetrate into the glass. I made the glass totally transparent and fresnel reflection at 100%, but it still had the same problem. The only way to make the center of the glass not get dark was to reduce the IOR for reflections and refractions. So I started breaking reality and it was starting to look better. After I had something kinda working I started adding a slight bump map near the edges of the cubes because I noticed in my glass reference on my desk that towards the corners the glass was warped a bit when the pieces were fused together. As soon as I did this it became aparent that with as many refractions as we needed you couldn't see through the cube again. Parts just became invisible inside all the crazy refractions. Not only that, but the rendertime suffered an almost 200% increase.
Eventually the environment was sorted out again and because I have architecture experience I was taken off the cube glass set up and put back on environments. Another artist took over the glass set up and came up with some nice looking results that totally broke reality, but that didn't matter because it looked good. I worked on variation after variation on the environment nearly right up until it delivered. At one point we finally decided that there wasn't going to be a good way to make the artificial lighting look good. We ripped open some holes in the ceiling and I was told to light the thing naturally. I think that was the best decision we made on the job, it really changed the look of the project and finally it was working.
In the meantime the other lighter who took over the cubes was getting creative with ways to reduce the rendertimes and still get great results. He came up with a great solution, but unfortunatly it was very complex. It was still faster than just waiting for frames though. His solution was to render the parts all by themselves without any glass in the scene. We did this three times. Once with an HDR generated from the actual 3d environment I built. A second time with an HDR of a studio lighting setup, and finally a third that only had a big area light above the parts. Our compositors would blend these three passes together over the environment background render until the parts looked cool. Then they would render an un-premultiplied pass of the parts back out for the lighters. The lighters took that pass into our cubes scenes and projection mapped it from the shot camera back onto the parts. Then we deleted all lighting from the scene. Only the glass cubes and projection mapped parts. This was rendered with the HDR of the CG environment for reflections and refractions. We still needed the ability to render mattes for the compositors, so we had to make scenes that had everything black except the parts which were 100% illuminated white. We also did an extra pass which was just the connecting edges of the glass cubes. This pass was used to tint only the fused faces of the glass cubes to have a greenish hue.
In this project challenge I'm going to cover my experience working on a commercial for Audi. At the time of writing this the commercial was not released and I do not have a link to it. Hopefully I'll get a link sometime soon after its release. You have to see it to appreciate it I think.
In this commercial we were asked to do every raytracers worst nightmare. Create a photo-real 9x9x9 glass rubix cube full of car parts in a photo-real CG environment. Then animate the cube rotating around and assembling the car as it spins until the car is completely built. For anyone keeping score...A 9x9x9 grid of boxes means that we had 729 cubes, each with at least one object inside it and most of them having several objects. Each individual cube had realistically modeled sides made of glass, which means we were seeing through a minimum of 36 panes and even more if viewing from an angle. So...729 cubes, made of 6 objects each. At least 3 times as many part objects. That put us at 26,244 nodes, just for the geometry of the cube and parts. Once you throw in the nodes for the environment and cube rig I can't even come up with that number...but these were some HUGE files to work in. Probably the most complex I've ever worked with.
When the project began I was one of the first modelers/lighters to start on it. There was a lot of uncertainty about what the environment should be like. It needed to not distract from the cubes, but also look good in its own right. Myself and two other lighters modeled up rough environments with temp glass cubes in it every day for a week or two. All similar but also quite different. As things progressed the environments that kept getting the most response were the very simple plain white rooms. In the beginning these all had white artificial lighting and no natural light sources. We went this direction for a long time, but when you put a glass cube in an evenly lit white room it disappears. We needed to have contrast in the scene in order for the glass to look like glass. I was pulled off of the environment for a week or so while the client, director and supervisors all worked out what they thought the environment should be. I was put on the task of creating the cubes and their glass shaders. At first I went with a totally realistic approach. I modeled all the sides of the glass cubes and stuck them up against each other. I put a realistic glass shader on them and hit render. Now I've never seen an actual 9x9x9 glass rubix cube before so I was a little suprised at first to find that the center of the cube was very dark. It was like the light just couldn't penetrate into the glass. I made the glass totally transparent and fresnel reflection at 100%, but it still had the same problem. The only way to make the center of the glass not get dark was to reduce the IOR for reflections and refractions. So I started breaking reality and it was starting to look better. After I had something kinda working I started adding a slight bump map near the edges of the cubes because I noticed in my glass reference on my desk that towards the corners the glass was warped a bit when the pieces were fused together. As soon as I did this it became aparent that with as many refractions as we needed you couldn't see through the cube again. Parts just became invisible inside all the crazy refractions. Not only that, but the rendertime suffered an almost 200% increase.
Eventually the environment was sorted out again and because I have architecture experience I was taken off the cube glass set up and put back on environments. Another artist took over the glass set up and came up with some nice looking results that totally broke reality, but that didn't matter because it looked good. I worked on variation after variation on the environment nearly right up until it delivered. At one point we finally decided that there wasn't going to be a good way to make the artificial lighting look good. We ripped open some holes in the ceiling and I was told to light the thing naturally. I think that was the best decision we made on the job, it really changed the look of the project and finally it was working.
In the meantime the other lighter who took over the cubes was getting creative with ways to reduce the rendertimes and still get great results. He came up with a great solution, but unfortunatly it was very complex. It was still faster than just waiting for frames though. His solution was to render the parts all by themselves without any glass in the scene. We did this three times. Once with an HDR generated from the actual 3d environment I built. A second time with an HDR of a studio lighting setup, and finally a third that only had a big area light above the parts. Our compositors would blend these three passes together over the environment background render until the parts looked cool. Then they would render an un-premultiplied pass of the parts back out for the lighters. The lighters took that pass into our cubes scenes and projection mapped it from the shot camera back onto the parts. Then we deleted all lighting from the scene. Only the glass cubes and projection mapped parts. This was rendered with the HDR of the CG environment for reflections and refractions. We still needed the ability to render mattes for the compositors, so we had to make scenes that had everything black except the parts which were 100% illuminated white. We also did an extra pass which was just the connecting edges of the glass cubes. This pass was used to tint only the fused faces of the glass cubes to have a greenish hue.
Thursday, July 2, 2009
Project Challenge: Fight Club
I recently had the pleasure...wait...was it a pleasure? After I fully recover and get some sleep I'll look back on this and consider it to have been a pleasure to work on ;)
At any rate. DD recently finished a very cool project for the Blu-Ray released of the movie "Fight Club." We were hired to create some graphics for the dvd menu screen. This project was FULL of challenges. Our goal was to re-create the scene from the film where Ed Nortons character is walking through his empty apartment while one by one pieces of furniture fade into the scene while text pops up over some of the items making it look like items from a catalog. However, in our version we planned to extend that shot into a full 360 degree panorama with half of the room being his apartment from the film and the other half being the gross dirty kitchen from the house on paper street. This also had to be a totally seamless 360 that would loop repeatedly. So as we came back around to the end of the shot we needed to make the rooms blend back together and start empty again. Did I mention that this all needed to be done from start to finish in less than two weeks?
To make this project harder. I wasn't supposed to be on it. However, the CG supervisor on the show was going on vacation and was not going to be here for the last half of the project. DD decided that they needed to have a CG supervisor on the show and they asked me to drop what I was doing on a different commercial and take the reigns as CG supervisor on this fight club project to help finish it. So I got to put on my supervisor cap again for the first time since leaving Blur. I was asked if I would do this about 15 minutes before the original CG sup left for his trip. I got a 15 minute crash course on what was currently done and what still needed to be done and what the expectations were.
We had a small team. Two lighters, two modelers, one compositor (although we did get some help from a few other artists here and there) and myself. The first plan was to get the modeling started. Half of the modeling was done before I came onto the project. The other half continued up until the last minute.
The plan was to render a 900 frame nodal pan around the entire empty living room and kitchen. Then we would create HDR's of the room and map it back onto the walls and render separate passes for all the different items in the room. After spending a little time thinking about this it became clear that we would run into a problem with this approach. First of all we would need multiple reflection and shadow passes for every object in the room, but more than that we were rendering with GI and as lights turn on and bounce off of objects in the room it should change the lighting on the rest of the objects in the room. Unfortunately, there was no way for us to render a pass that was ONLY the bounced light from the addition of a single prop into the room. So we needed to find a new approach.
The next idea was to actually just keep adding one more prop to each pass and then disolve between them in the comp. This was a good approach because we could elimiate all the shadow and reflection passes completely, and we only needed to render about 30 frames of each pass because we would be frequently disolving to other passes. So this was a good plan because we greatly reduced the number of passes and complexity in the comp and made life a bit easier for everyone. Then we discovered the next problem...GI flickering and glossy reflection noise.
We tried raising settings which was helping, but in order to get renders nice and flicker free we would need to bake out the GI. Since this would require over 100 separate GI calcs and would need updated everytime a prop was moved or changed this became a major problem to manage. We didn't have time or tools in place to help us do that. So it was time again to come up with a new plan.
The key to the solution ended up being that the camera was just a nodal pan AND that nothing in the room moves. Items just fade on. Late at night on my first day on the project I started thinking about this problem. The solution to our GI and reflection problem would be to only render single frames and stitch together a panorama. That would greatly reduce the number of frames we had to render. In fact that would mean we only needed one single frame for each prop that fades on. Then it occured to me. Vray has a cylindrical camera. We could render one single high res frame of the entire 360 degree room and map it onto a 3d cylinder in Nuke. We could also bake out our cameras motion and feed that into Nuke also. Then the compositor would just disolve between our single frames and have complete control over when things blended on. The only problem with this plan was that Vrays cylindrical camera didn't work the way I thought it did. So that idea wasn't going to work. However, Vray's spherical camera could do something close enough. Instead of a cylinder we could use a sphere. I rendered out a few lower res spherical panoramas to give to the compositor to try the idea out with. It worked. We scraped all our other methods and moved forward with the spherical pano idea.
In order for the final resolution pano's to hold up we needed to render 6000x3000 pixels. This took a while, but it was a safer way to go. Renders took a maximum of about 10 hours. Things were kind of interesting in the comp. The tree itself was pretty simple...just a huge line up of read nodes and disolves. But because we were rendering panoramic images and only still frames it made some tasks easier, and others harder. For example it was very easy to roto. You didn't have to animate any beziars because the images didn't move. The camera just pans across them. What wasn't easy was rendering mattes. We rendered a few, but we knew going into it that things would be disolving on and screwing up the matte, so we would either have to render a new matte for every time an object blends on, or the compositor would have to work their magic a bit with mattes. Ultimately, roto would be faster.
While lighting was going on we had two and sometimes 3 prop modelers creating props to fill up the rooms with. We were referencing all of these models into the lighting scene so the lighter could keep working while the modelers were updating things. It sounds great in theory, but in all my years I've never seen this work well. The biggest reason this was a problem this time around was that we discovered some bugs in our model publishing tool that was screwing up shaders and geometry in the lighting scene. We also had a lot of trouble with Maya's render layers which have proven to be a total mess. The biggest issue with them was they would lose texture assignments. This has happened on several shows now and I'm not thrilled about it. On top of that we just started using a tool called "Atomic" that greatly simplifies setting up render layers. Its a lot like Blur's "Render Elements" tool, but in some ways much stronger, and others much weaker. Atomic is still going through stages of being integrated with Vray, so we ran into a few issues there as well. The modelers did a great job. Two of them had never used Vray before and the third had used it only once before. They are a talented bunch and quick learners so they picked it up pretty fast.
At any rate. DD recently finished a very cool project for the Blu-Ray released of the movie "Fight Club." We were hired to create some graphics for the dvd menu screen. This project was FULL of challenges. Our goal was to re-create the scene from the film where Ed Nortons character is walking through his empty apartment while one by one pieces of furniture fade into the scene while text pops up over some of the items making it look like items from a catalog. However, in our version we planned to extend that shot into a full 360 degree panorama with half of the room being his apartment from the film and the other half being the gross dirty kitchen from the house on paper street. This also had to be a totally seamless 360 that would loop repeatedly. So as we came back around to the end of the shot we needed to make the rooms blend back together and start empty again. Did I mention that this all needed to be done from start to finish in less than two weeks?
To make this project harder. I wasn't supposed to be on it. However, the CG supervisor on the show was going on vacation and was not going to be here for the last half of the project. DD decided that they needed to have a CG supervisor on the show and they asked me to drop what I was doing on a different commercial and take the reigns as CG supervisor on this fight club project to help finish it. So I got to put on my supervisor cap again for the first time since leaving Blur. I was asked if I would do this about 15 minutes before the original CG sup left for his trip. I got a 15 minute crash course on what was currently done and what still needed to be done and what the expectations were.
We had a small team. Two lighters, two modelers, one compositor (although we did get some help from a few other artists here and there) and myself. The first plan was to get the modeling started. Half of the modeling was done before I came onto the project. The other half continued up until the last minute.
The plan was to render a 900 frame nodal pan around the entire empty living room and kitchen. Then we would create HDR's of the room and map it back onto the walls and render separate passes for all the different items in the room. After spending a little time thinking about this it became clear that we would run into a problem with this approach. First of all we would need multiple reflection and shadow passes for every object in the room, but more than that we were rendering with GI and as lights turn on and bounce off of objects in the room it should change the lighting on the rest of the objects in the room. Unfortunately, there was no way for us to render a pass that was ONLY the bounced light from the addition of a single prop into the room. So we needed to find a new approach.
The next idea was to actually just keep adding one more prop to each pass and then disolve between them in the comp. This was a good approach because we could elimiate all the shadow and reflection passes completely, and we only needed to render about 30 frames of each pass because we would be frequently disolving to other passes. So this was a good plan because we greatly reduced the number of passes and complexity in the comp and made life a bit easier for everyone. Then we discovered the next problem...GI flickering and glossy reflection noise.
We tried raising settings which was helping, but in order to get renders nice and flicker free we would need to bake out the GI. Since this would require over 100 separate GI calcs and would need updated everytime a prop was moved or changed this became a major problem to manage. We didn't have time or tools in place to help us do that. So it was time again to come up with a new plan.
The key to the solution ended up being that the camera was just a nodal pan AND that nothing in the room moves. Items just fade on. Late at night on my first day on the project I started thinking about this problem. The solution to our GI and reflection problem would be to only render single frames and stitch together a panorama. That would greatly reduce the number of frames we had to render. In fact that would mean we only needed one single frame for each prop that fades on. Then it occured to me. Vray has a cylindrical camera. We could render one single high res frame of the entire 360 degree room and map it onto a 3d cylinder in Nuke. We could also bake out our cameras motion and feed that into Nuke also. Then the compositor would just disolve between our single frames and have complete control over when things blended on. The only problem with this plan was that Vrays cylindrical camera didn't work the way I thought it did. So that idea wasn't going to work. However, Vray's spherical camera could do something close enough. Instead of a cylinder we could use a sphere. I rendered out a few lower res spherical panoramas to give to the compositor to try the idea out with. It worked. We scraped all our other methods and moved forward with the spherical pano idea.
In order for the final resolution pano's to hold up we needed to render 6000x3000 pixels. This took a while, but it was a safer way to go. Renders took a maximum of about 10 hours. Things were kind of interesting in the comp. The tree itself was pretty simple...just a huge line up of read nodes and disolves. But because we were rendering panoramic images and only still frames it made some tasks easier, and others harder. For example it was very easy to roto. You didn't have to animate any beziars because the images didn't move. The camera just pans across them. What wasn't easy was rendering mattes. We rendered a few, but we knew going into it that things would be disolving on and screwing up the matte, so we would either have to render a new matte for every time an object blends on, or the compositor would have to work their magic a bit with mattes. Ultimately, roto would be faster.
While lighting was going on we had two and sometimes 3 prop modelers creating props to fill up the rooms with. We were referencing all of these models into the lighting scene so the lighter could keep working while the modelers were updating things. It sounds great in theory, but in all my years I've never seen this work well. The biggest reason this was a problem this time around was that we discovered some bugs in our model publishing tool that was screwing up shaders and geometry in the lighting scene. We also had a lot of trouble with Maya's render layers which have proven to be a total mess. The biggest issue with them was they would lose texture assignments. This has happened on several shows now and I'm not thrilled about it. On top of that we just started using a tool called "Atomic" that greatly simplifies setting up render layers. Its a lot like Blur's "Render Elements" tool, but in some ways much stronger, and others much weaker. Atomic is still going through stages of being integrated with Vray, so we ran into a few issues there as well. The modelers did a great job. Two of them had never used Vray before and the third had used it only once before. They are a talented bunch and quick learners so they picked it up pretty fast.
Monday, June 22, 2009
Project Challenge: LG Transformers 2
I'm back with another project challenge post about our latest LG commercial. This time around we had a tie in with the upcoming film Transformers 2. Here is a link to the commercial on Youtube.
Our main workflow these days is to use Maya/Vray on our commercials. This project, however, came at a period of time where it would be more beneficial to us (for internal scheduling reasons) to dust off our old Max/Vray pipeline again and do another commercial with it.
This time around we had a very small team. There was only 3 of us doing any 3d work. We were able to get a model to start from of the phone from the client. I took the model and reworked some areas of it and cleaned it up so that we would get proper meshsmoothing on it. I also did the same for the laptop model. Another artist modeled the camcorder from scratch while our supervisor modeled the GPS unit using the phone as a base model to start from. After all of the modeling was done, all of the models were given to me to create materials for. Since the phone was supposed to appear to be transforming into all of these other objects, everything basically needed to have the same materials applied to them. After we got the materials all set up, the three of us began animating. Since we were a very small team we had to handle all the animation ourselves which was a little daunting at first. I handled two of the transformation shots and ended up taking over and finishing a third one. While this was going on I also set up the light rig that we ended up using for all the shots. The rig was entirely set up using an HDR panorama that was shot on location durring the shoot. I plugged that HDR into a Vray dome light and used Light Cache and Brute force for GI.
Animating was probably the biggest challenge on this project. Although once you got your head wrapped around it, it really wasn't that difficult to do. We first focused on the big moves. We didn't care if it was physically possible for something to move a certain way or if it was floating out in space. We just focused on making some interesting movements with the bigger and more noticable pieces. After that we went back in and starting the real work which was to connect up all the big pieces so they weren't just floating around and give them connectors and gizmos that would support their motion. Finally, we did a pass on the animation where we added parts inside the objects to make them appear to have circuit boards and components that would actually be inside these objects and we used those to help hide any bits behind as the transformation happened. So a piece of the phone may slide behind a circuit board while another piece of the camcorder swung out from behind something else. You do this enough times with enough pieces and eventually you have a transforming phone.
The next challenge we had to overcome was that the actor was holding the real phone in his had in all of our plates. So when we did our animations on top of it you could see the real phone in his hand underneath our CG. We already had an artist do some camera and geometry tracking for us so we had a rough hand model that we were using for shadow catching. I took that model as well as a still image we had of the actors empty hand that they shot on set and mapped the hand photo onto our 3d geometry. I had to do a lot of pulling and pushing of the UV's to get them to line up ok since the angle of our camera and the hand photo were fairly different. I rendered out an empty hand pass that the compositor used to help paint out the original phone from the plate. He would just use little bits and pieces from my render as needed to fill in some gaps. We ended up do this for several shots.
Rendering was simple. These weren't complex scenes really so they rendered pretty fast. I think we were around 1 hour a frame for the worst case close up shots. Everything else was between 10 and 30 minutes. It was a lot of fun to work on this project. Not only did it turn out looking pretty cool, but I got to push myself a bit with the animation, and nobody had to work any long hours.
Our main workflow these days is to use Maya/Vray on our commercials. This project, however, came at a period of time where it would be more beneficial to us (for internal scheduling reasons) to dust off our old Max/Vray pipeline again and do another commercial with it.
This time around we had a very small team. There was only 3 of us doing any 3d work. We were able to get a model to start from of the phone from the client. I took the model and reworked some areas of it and cleaned it up so that we would get proper meshsmoothing on it. I also did the same for the laptop model. Another artist modeled the camcorder from scratch while our supervisor modeled the GPS unit using the phone as a base model to start from. After all of the modeling was done, all of the models were given to me to create materials for. Since the phone was supposed to appear to be transforming into all of these other objects, everything basically needed to have the same materials applied to them. After we got the materials all set up, the three of us began animating. Since we were a very small team we had to handle all the animation ourselves which was a little daunting at first. I handled two of the transformation shots and ended up taking over and finishing a third one. While this was going on I also set up the light rig that we ended up using for all the shots. The rig was entirely set up using an HDR panorama that was shot on location durring the shoot. I plugged that HDR into a Vray dome light and used Light Cache and Brute force for GI.
Animating was probably the biggest challenge on this project. Although once you got your head wrapped around it, it really wasn't that difficult to do. We first focused on the big moves. We didn't care if it was physically possible for something to move a certain way or if it was floating out in space. We just focused on making some interesting movements with the bigger and more noticable pieces. After that we went back in and starting the real work which was to connect up all the big pieces so they weren't just floating around and give them connectors and gizmos that would support their motion. Finally, we did a pass on the animation where we added parts inside the objects to make them appear to have circuit boards and components that would actually be inside these objects and we used those to help hide any bits behind as the transformation happened. So a piece of the phone may slide behind a circuit board while another piece of the camcorder swung out from behind something else. You do this enough times with enough pieces and eventually you have a transforming phone.
The next challenge we had to overcome was that the actor was holding the real phone in his had in all of our plates. So when we did our animations on top of it you could see the real phone in his hand underneath our CG. We already had an artist do some camera and geometry tracking for us so we had a rough hand model that we were using for shadow catching. I took that model as well as a still image we had of the actors empty hand that they shot on set and mapped the hand photo onto our 3d geometry. I had to do a lot of pulling and pushing of the UV's to get them to line up ok since the angle of our camera and the hand photo were fairly different. I rendered out an empty hand pass that the compositor used to help paint out the original phone from the plate. He would just use little bits and pieces from my render as needed to fill in some gaps. We ended up do this for several shots.
Rendering was simple. These weren't complex scenes really so they rendered pretty fast. I think we were around 1 hour a frame for the worst case close up shots. Everything else was between 10 and 30 minutes. It was a lot of fun to work on this project. Not only did it turn out looking pretty cool, but I got to push myself a bit with the animation, and nobody had to work any long hours.
Monday, June 15, 2009
Project Challenge: LG Advanced Learning
Its been a long time since I've done a Project Challenge post. I haven't done a single one since moving to Digital Domain either. So lets go over a spot that I really enjoyed working on...LG Advanced Learning. Here is a link to the commercial. This is the 30 second cut. We did a 60, but I can't find it anywhere online that you don't have to subscribe to.
This project was a lot of fun to work on. It was a pretty good challenge and in the end it went very smooth and I'm quite pleased with how it all turned out. This was the third project I worked on at DD.
The great thing for me was that another co-worker of mine and I convinced our supervisors to use Max/Vray for this job. Vray is exceptional when it comes to photo real metalic surfaces. The only problem with this idea was that DD didn't currently have a Max TD around to write tools, and DD's older tools for max hadn't been updated in a while. There were a few tools that we HAD to have in order for this to work, so right off the start I set to work creating the ones we didn't have, and my co-worker, Chris(who had used the older DD max pipeline), started testing the existing tools to make sure they were working and stable. Fortunately, they were all in good condition, so it was up to me to script a few needed tools. I ended up writing a tool that would allow us to automatically import animation data in the form of MDD files onto objects in max from Maya. We had hundreds of objects and there was no way this was going to be done by hand. I was very happy to see it get used the first time in production without breaking. In fact, I think we only broke it once durring the project. I also re-wrote a tool that I originally came up with at Blur, but needed re-written to plug into DD's pipeline with Vray. It was a quick test render tool which allowed you to override render settings at the push of a button to do very quick test renders while not actually changing any of your final render settings.
When the project first got rolling we learned that the director had already had another company model the characters. So we were given meshes to start working with. For the most part the models were well done. However, we really wanted these characters to be hyper detailed, so we went back into the models and re-worked them A LOT. We added tons of tiny details that you will only see if your lucky enough to catch the commercial in HD, and maybe not even then unless its a close up shot. We went so far as to model little weld points for all the circuitry. Every inch of these characters had some fine detail on them. We spent a lot of time in this part of the production. Perfecting textures and models. This was the hardest part of the project actually. As soon as the characters started getting signed off on it was pretty smooth sailing to the finish.
When it came time to start rendering shots it was a breeze. The time we spent up front getting the tools ready really paid off. Shots came together quickly and we had very little issues on the render farm. The one thing that did present a problem for us though was grainy noise. We were throwing everything at Vray on this spot. We had GI calc'd per frame, glossy reflections, glossy refractions, translucency, depth of field rendered in camera and motion blur. We also had nuclear hot lights which didn't help the grain at all. Then the challenges started. It really wasn't all that bad to solve the grain issues, but it was the most challenging thing about this project. I love working with Chris though. He and I come from two different schools of thought about rendering with Vray. He is very much in favor of using Light Cache and Irradiance mapping for GI, where I'm in favor of Light Cache and brute force, or in some cases completely brute force GI. What we learned was that about 50% of the time his method worked the best. We got fast render times and clean GI. However, the other 50% when things got more complicated we found that my approach worked out better. It ultimately came down to what was happening in each shot. With so many variables it was a little tricky at first to figure out what needed to be tweeked in order to get rid of the grain. The best way to figure it out was to look at all the buffers we were saving out. We could do test renders looking only at the GI pass to see if our settings were causing grain there and we could tweak the GI settings apart from everything else. We did the same for reflection and refraction passes to make sure our samples were high enough there. Then finally we'd turn on motion blur and DOF and check again to make sure everything was clean before submitting to the farm again. Naturally the render times went up, but all in all none were very long for what we were doing. Most frames averaged around 30-40 minutes at 1024x576. A few of the close up shots were rendered at 1920x1080 and those were about 3 1/2 hours per frame for finals.
This was a rare project. Things went so smoothly on the back end that the lighters pretty much finished a week early and were just there to help the comp artists with additional matte passes and misc fixes. We pulled a few late nights in the beginning durring the modeling phase, but once we were into lighting it was regular work hours til delivery.
The FX were very cool on this spot. DD hired an artist to come in and code real time particle FX and render them in open GL. I sat next to this guy and it was very interesting to listen to him click away for hours writing code, then there would be a flash from his monitor and I'd look over and he'd be testing his particle system...It would just swirl endlessly without looping until he stopped it and went back to coding. In order to get those FX into our scenes with the correct camera motion he rendered out cards of his particles and another 3d artist took them into Lightwave and positioned them and rendered out passes for the compositors. In some cases the compositors took care of the FX placement themselves. The lighters didn't have to do any of this, but we did have to render interactive lighting passes and a few reflection passes.
That's about it.
This project was a lot of fun to work on. It was a pretty good challenge and in the end it went very smooth and I'm quite pleased with how it all turned out. This was the third project I worked on at DD.
The great thing for me was that another co-worker of mine and I convinced our supervisors to use Max/Vray for this job. Vray is exceptional when it comes to photo real metalic surfaces. The only problem with this idea was that DD didn't currently have a Max TD around to write tools, and DD's older tools for max hadn't been updated in a while. There were a few tools that we HAD to have in order for this to work, so right off the start I set to work creating the ones we didn't have, and my co-worker, Chris(who had used the older DD max pipeline), started testing the existing tools to make sure they were working and stable. Fortunately, they were all in good condition, so it was up to me to script a few needed tools. I ended up writing a tool that would allow us to automatically import animation data in the form of MDD files onto objects in max from Maya. We had hundreds of objects and there was no way this was going to be done by hand. I was very happy to see it get used the first time in production without breaking. In fact, I think we only broke it once durring the project. I also re-wrote a tool that I originally came up with at Blur, but needed re-written to plug into DD's pipeline with Vray. It was a quick test render tool which allowed you to override render settings at the push of a button to do very quick test renders while not actually changing any of your final render settings.
When the project first got rolling we learned that the director had already had another company model the characters. So we were given meshes to start working with. For the most part the models were well done. However, we really wanted these characters to be hyper detailed, so we went back into the models and re-worked them A LOT. We added tons of tiny details that you will only see if your lucky enough to catch the commercial in HD, and maybe not even then unless its a close up shot. We went so far as to model little weld points for all the circuitry. Every inch of these characters had some fine detail on them. We spent a lot of time in this part of the production. Perfecting textures and models. This was the hardest part of the project actually. As soon as the characters started getting signed off on it was pretty smooth sailing to the finish.
When it came time to start rendering shots it was a breeze. The time we spent up front getting the tools ready really paid off. Shots came together quickly and we had very little issues on the render farm. The one thing that did present a problem for us though was grainy noise. We were throwing everything at Vray on this spot. We had GI calc'd per frame, glossy reflections, glossy refractions, translucency, depth of field rendered in camera and motion blur. We also had nuclear hot lights which didn't help the grain at all. Then the challenges started. It really wasn't all that bad to solve the grain issues, but it was the most challenging thing about this project. I love working with Chris though. He and I come from two different schools of thought about rendering with Vray. He is very much in favor of using Light Cache and Irradiance mapping for GI, where I'm in favor of Light Cache and brute force, or in some cases completely brute force GI. What we learned was that about 50% of the time his method worked the best. We got fast render times and clean GI. However, the other 50% when things got more complicated we found that my approach worked out better. It ultimately came down to what was happening in each shot. With so many variables it was a little tricky at first to figure out what needed to be tweeked in order to get rid of the grain. The best way to figure it out was to look at all the buffers we were saving out. We could do test renders looking only at the GI pass to see if our settings were causing grain there and we could tweak the GI settings apart from everything else. We did the same for reflection and refraction passes to make sure our samples were high enough there. Then finally we'd turn on motion blur and DOF and check again to make sure everything was clean before submitting to the farm again. Naturally the render times went up, but all in all none were very long for what we were doing. Most frames averaged around 30-40 minutes at 1024x576. A few of the close up shots were rendered at 1920x1080 and those were about 3 1/2 hours per frame for finals.
This was a rare project. Things went so smoothly on the back end that the lighters pretty much finished a week early and were just there to help the comp artists with additional matte passes and misc fixes. We pulled a few late nights in the beginning durring the modeling phase, but once we were into lighting it was regular work hours til delivery.
The FX were very cool on this spot. DD hired an artist to come in and code real time particle FX and render them in open GL. I sat next to this guy and it was very interesting to listen to him click away for hours writing code, then there would be a flash from his monitor and I'd look over and he'd be testing his particle system...It would just swirl endlessly without looping until he stopped it and went back to coding. In order to get those FX into our scenes with the correct camera motion he rendered out cards of his particles and another 3d artist took them into Lightwave and positioned them and rendered out passes for the compositors. In some cases the compositors took care of the FX placement themselves. The lighters didn't have to do any of this, but we did have to render interactive lighting passes and a few reflection passes.
That's about it.
Subscribe to:
Posts (Atom)