The Gnomon Workshop has posted in their "coming soon" section news about the release of my next training DVD. It is called "Multi-pass compositing" and deals with rendering passes out of 3ds max using several different renderers and compositing in Digital Fusion. The DVD mainly focuses on the compositing side of things. I really tried to include as much information as I could. I started off with some basics, but then I got into the "meat and potatoes," if you will, about how to work with passes. I feel that over the years I've come across many compositing work flows and issues in production and I made sure to include examples and explanations on how to deal with as many of them as I could on this DVD. I feel really good about how this DVD turned out. Hopefully if anyone reading this checks it out they'll enjoy it too. :)
www.thegnomonworkshop.com
Friday, August 15, 2008
One week and counting
I've just completed my first week at Digital Domain. So far its been exciting, frustrating and overwhelming at times. I've been bombarded with a ton of new software to learn, both proprietary and off the shelf. The amount of new software to learn has been the overwhelming part. Each day its gotten easier, but its still a lot to try to soak in all at once. At times its been frustrating because for the past 5 years at Blur I've known the pipeline and tools inside out. Even helped to create some of them. But now I find myself the struggling new guy all over again. So far that has been both exciting and frustrating as I mentioned before. Knowing one pipeline inside out and then being dropped into a new pipeline and software that is completely foreign has been the hard part. Your faced with wanting to produce work at the same level and speed that your used to doing, but you know no matter what that there has to be a period of time in which to learn and your going to be slower until you gain experience with the new tools and pipeline. I'm excited about learning new software and work flows. I'm also excited to get to work on different types of projects and make new friends.
Wednesday, July 30, 2008
Project Challenge: Hawx
So as I mentioned in my previous post. Hawx is finished. So its time to give a little breakdown on it. :)
Hawx is a 30 second television spot for the game. The final output resolution was 1920x1080 HD at 30 fps. We had a total of 17 shots. We had 1 animatic artist, 2 vehicle modelers, 2 riggers, 2 animators, 2 scene assemblers and 2 FX artists on the project. The project was for the most part rendered in Mental Ray. I ended up needing to render a few passes in Vray though. More on that later.
The biggest problem as usual ended up being memory management. The city street shots were pretty heavy on the poly count and textures, but nothing above and beyond the normal range. What made it difficult to render was that we needed to have the characters render in the scene in order to get proper reflections and light interaction on the environment as them move through it. Since the final output res was 1080p we had some very high res texture maps. It only takes a few of those before your in memory troubles (This project was in 32bit so we had the 3 gig RAM limit). It came down to carefully optimizing each shot so that it would be as high quality as possible but still render.
Another issue we came across was one that we originally thought would save us time. In this spot we were re-using some characters and vehicles from a previous project we did. The only difference was that the materials needed to be changed over to Mental Ray from Brazil. So we didn't need to worry about new character models or rigs. Unfortunately, in the end it came out as a wash. The models were over a year old and weren't up to date with our current pipeline needs as far as our tools are concerned. So the animators and riggers fought against that enough that it probably didn't save us any time at all in the long run and caused headaches for them. Sorry guys :(
Scene assembly was pretty straight forward. Most of the shots took place in the air so there was no interaction with the environment to worry about. Renders were pretty fast even at final quality. I think the longest render times I had were about 1.5 hours per frame at final quality. That was for some closeup shots of the pilot in the cockpit.
The aerial shots turned out to be simpler than I was originally anticipating. For the most part we got away with some satellite photos mapped onto a rough landscape model. Then we sprinkled in some models of the taller buildings, but left the shorter ones as just part of the aerial photo texture. This map ended up being HUGE. I broke it into two maps cause it was just too big. Each of the two texture maps was 19,000 pixels square. I could just barely get these two maps to render by themselves on the landscape model. So I spent some time looking into ways of dealing with extremely large texture maps. Which lead me to tiled .map and .exr files. In the end I ended up not needed to use them and just rendered as normal, but what you can do with them is really impressive so I plan to start making use of them more often in my work.
The beauty of a tiled .map or .exr is that Mental Ray can look at these texture maps and know if they are tiled or not. When I say "tiled" I don't mean you take a texture map and repeat it a number of times. Tiled in this case means that within the texture map are smaller defined areas or "tiles." When these types of texture maps are used in your scene and Mental Ray finds them it does not load the whole texture map into memory...Instead it only loads the tile it needs in order to render the current bucket. Then when its finished rendering that bucket it dumps the memory and loads the next tile it needs. So you have almost no Ram overhead, and it seemed in my case to actually initialize and render the scene faster. It is also possible to have these .map or .exr files store multiple resolution texture maps inside them. This way if Mental Ray knows that an object is far away it can load a lower resolution version instead of the full res one. The downside to this is that it requires a lot of hard drive space. These texture maps get huge. Mine were around 400 megs each. Another downside is that it takes some manual setup to create the tiled texture maps. For that I found some dos based executables on the OpenEXR website which allow you to convert texture maps to tiled texture maps. But its not a simple "save as" menu, you have to actually type out some basic code in a certain format. Totally worth the trouble though if you have a lot of highres maps you need to render. I found that .map files worked just fine in Max 2008, however, exr's did not work properly. The memory was not being handled right in mental ray. In max 2009 the exrs worked beautifully. FYI
In the end the project went very smoothly. The clients were great, the project delivered on time and on budget. There were hardly any long work days and nobody pulled any all nighters.
Friday, July 25, 2008
Nearly 5 years
Well...Hawx is now finished and out the door.... And so am I. After nearly 5 years at Blur I've decided to move on. I'll be heading over to Digital Domain to work in their commercials department. Its been an amazing ride at Blur. I've made lots of great friends and grown tremendously as an artist and team leader. Blur is a fantastic place to work and I'm very sad to say goodbye. I've always wanted to produce photo real renderings, and since that is a type of work that Blur rarely does, I've decided to move on. I will miss you Blur! Thanks for everything.
On a side note. Digital Domain is pretty much walking distance from Blur, and Sze (my wife) will still be working at Blur. So I'm not really leaving, just sitting further down the street. :)
On a side note. Digital Domain is pretty much walking distance from Blur, and Sze (my wife) will still be working at Blur. So I'm not really leaving, just sitting further down the street. :)
Wednesday, June 25, 2008
1st Pass of Hawx
Hawx is in full swing now. Animation is about 98% done with just minor fixes being done as we find them. Scene assembly is just past half way done and the FX artists started this week. As projects go this one is simpler than most. Half of the spot takes place in the air so we don't have to worry about shadows on the environment or in some shots not even an environment at all. Only 3 of the aerial shots ended up needing a modeled environment in the background. The rest of the aerial shots worked just fine with photographed cloud backgrounds and afterburn particles mixed together. The FX will consist of two large explosions (seen in 4 total shots) and some simpler things like vapor trails and flares. We'll have our first review of the scene assembly this Friday with the client. That's when we'll find out if we're really on the right track or not ;) .
Wednesday, May 7, 2008
HAWX begins
Section 8 is finally completely approved and out the door. So work on HAWX has officially begun. HAWX is a game all about modern air combat. This project will be a 30 second television commercial for the game. Part of the spot will take place on the ground in some war torn streets of Rio de Janiero. The rest will take place in the air over the city. I'm looking forward to this project. I have never done a project that requires me to create a CG version of a recognizable city and its landmarks. Let alone do that from the air. Should be fun and very action packed. The in-game footage we were given for reference is pretty impressive.
Tuesday, April 8, 2008
Project Challenge
With every project I work on there is always some unique challenge that has to be overcome while working on it. I thought I would start a re-occurring topic where as I finish a project I'd share what the main challenges were with it and how we over came them.
For the first post in this series I'll talk about the game trailer for "Section 8."
This project was pretty typical in most respects. It was rendered in HD at 1280x720 at 30fps. The total running time was 2 minutes 10 seconds and there were 30 shots. We had 2 character modelers, 1 rigger, 5 animators (never all at once), 3 Scene assemblers, 2 FX artists and 1 matte painter. The cinematic mainly takes place on the surface of an alien desert environment approaching sunset. Some shots at the beginning take place inside a space ship. The characters are futuristic soldiers wearing highly reflective body armor.
For this project we rendered with Mental Ray in 3ds Max 2008. This was the first project to be rendered at Blur using this combination. Understandably, many of our issues in the beginning were just learning the ins and outs of Mental Ray. Memory turned out to be our biggest challenge on this project. Memory is always an issue on every project, however, this time it really came to the forefront.
I was responsible for modeling the environment (among other things) which is full of large rock formations and was wanting to use mental ray's displacement for them. The rocks were modeled in Z-brush and displacement and normal maps were exported for them. After only putting my second rock into the scene my render crashed. I checked the RAM and was shocked to see it was well up above 3 gigs. After some experimentation it turned out that Mental Ray was not flushing the RAM it was using for the displacement after the bucket being rendered finished. Vray users (like myself) will know this as dynamic memory. Its memory that is only loaded when the bucket starts to render, and is flushed when the bucket completes allowing you to render very memory intensive scenes. I started lowering displacement quality to see how low I had to push things before I could get it to render. After a short while it was obvious that displacement was not going to work for me. I couldn't get anyways near the quality level I was hoping for. So instead I started outputting level 4 subdivided meshes from Z-brush for all my rock formations and normal maps to use for the finer details. The normal maps looked great. Almost as good as the displacement did, and because the meshes were pretty dense I was able to get a pretty decent silhouette for the rocks also. The silhouette detail is the most important part of getting the rocks to look realistic. A good shader helps too ;). So I stripped all the displacement out of my scene and was getting lighting fast renders. From that point on it was business as usual with RAM. I could just watch my RAM usage in the task manager just like I always do. Towards the end of the project though we started running into memory problems again. In order to get the level of detail we needed in the rocks we had to have millions of polys in the scene. Every shot needed its own custom optimizations just to get it to render at all. The poly count of every shot varied, but the larger shots ended up around 6 million polys.
The second challenge was the highly reflective body armor the soldiers have. We have shots of the characters running through the scene as well as crouching behind rocks as they take fire from the opposing side. The original plan was to render and HDR of the environment and use that for lighting and reflections when we did the character passes. We've done that plenty of times in the past and it works great. However, this time, because the characters were so reflective it was really obvious they weren't moving through the environment. The reflections remained very static. We thought about maybe rendering HDR sequences that tracked the motion of the characters, but then every character would need its own HDR sequence and it just would be too complicated to do it that way. So we ultimately ended up making the environment invisible to camera, but having the characters rendered with the environment in the scene. This really helped add to the realism, but was very difficult to get it to render because of the RAM usage required having the environment and characters in the scene rendering together. In the end though this was the best solution and is how it ultimately got rendered.
As projects go, this one was fairly easy. It was a small crew and most of us are veterans. The new guys on the team did a great job on this project as well.
For the first post in this series I'll talk about the game trailer for "Section 8."
This project was pretty typical in most respects. It was rendered in HD at 1280x720 at 30fps. The total running time was 2 minutes 10 seconds and there were 30 shots. We had 2 character modelers, 1 rigger, 5 animators (never all at once), 3 Scene assemblers, 2 FX artists and 1 matte painter. The cinematic mainly takes place on the surface of an alien desert environment approaching sunset. Some shots at the beginning take place inside a space ship. The characters are futuristic soldiers wearing highly reflective body armor.
For this project we rendered with Mental Ray in 3ds Max 2008. This was the first project to be rendered at Blur using this combination. Understandably, many of our issues in the beginning were just learning the ins and outs of Mental Ray. Memory turned out to be our biggest challenge on this project. Memory is always an issue on every project, however, this time it really came to the forefront.
I was responsible for modeling the environment (among other things) which is full of large rock formations and was wanting to use mental ray's displacement for them. The rocks were modeled in Z-brush and displacement and normal maps were exported for them. After only putting my second rock into the scene my render crashed. I checked the RAM and was shocked to see it was well up above 3 gigs. After some experimentation it turned out that Mental Ray was not flushing the RAM it was using for the displacement after the bucket being rendered finished. Vray users (like myself) will know this as dynamic memory. Its memory that is only loaded when the bucket starts to render, and is flushed when the bucket completes allowing you to render very memory intensive scenes. I started lowering displacement quality to see how low I had to push things before I could get it to render. After a short while it was obvious that displacement was not going to work for me. I couldn't get anyways near the quality level I was hoping for. So instead I started outputting level 4 subdivided meshes from Z-brush for all my rock formations and normal maps to use for the finer details. The normal maps looked great. Almost as good as the displacement did, and because the meshes were pretty dense I was able to get a pretty decent silhouette for the rocks also. The silhouette detail is the most important part of getting the rocks to look realistic. A good shader helps too ;). So I stripped all the displacement out of my scene and was getting lighting fast renders. From that point on it was business as usual with RAM. I could just watch my RAM usage in the task manager just like I always do. Towards the end of the project though we started running into memory problems again. In order to get the level of detail we needed in the rocks we had to have millions of polys in the scene. Every shot needed its own custom optimizations just to get it to render at all. The poly count of every shot varied, but the larger shots ended up around 6 million polys.
The second challenge was the highly reflective body armor the soldiers have. We have shots of the characters running through the scene as well as crouching behind rocks as they take fire from the opposing side. The original plan was to render and HDR of the environment and use that for lighting and reflections when we did the character passes. We've done that plenty of times in the past and it works great. However, this time, because the characters were so reflective it was really obvious they weren't moving through the environment. The reflections remained very static. We thought about maybe rendering HDR sequences that tracked the motion of the characters, but then every character would need its own HDR sequence and it just would be too complicated to do it that way. So we ultimately ended up making the environment invisible to camera, but having the characters rendered with the environment in the scene. This really helped add to the realism, but was very difficult to get it to render because of the RAM usage required having the environment and characters in the scene rendering together. In the end though this was the best solution and is how it ultimately got rendered.
As projects go, this one was fairly easy. It was a small crew and most of us are veterans. The new guys on the team did a great job on this project as well.
Subscribe to:
Posts (Atom)