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.
Saturday, March 29, 2008
Simple scripting
Scripting in 3ds Max is maybe not for everyone, but I couldn't even begin to count the hours/weeks/months of my time that was saved by learning at least the basics. You don't have to be a scripting genius to automate some simple repetitive tasks. The "For loop" is very basic, and is also probably the most common bit of coding you'll need. Save yourself hours of work and try this.
Lets say you've modeled a bunch of vines using renderable splines (based on a true story), but after placing about 300 of them you realize you forgot to give them enough segments to look rounded. The "for loop" is here to save you. It goes like this.
---------------
for i in selection do
(
i.render_sides = 12
)
-------------------
Its that simple. But let me explain what its doing. "i" could be anything. It could be "n", "blah", "Myfirstofficialblogpost"....etc. It doesn't matter. Its a variable that you make up that will represent each object in your selection. So basically....for (every object) that is selected do...the following bit thats in parenthesis.
In this case inside the parenthesis is a line of code that will change the segments a spline to 12. Because "i" will represent every object in my selection. This script will go through each object in my selection one at a time and change the segments to 12.
Now lets take this one step further. Another really helpful bit of code to know is how to generate random values. With a slight modification you can have the above script assign a random number of segments to each spline.
-----------------------------
for i in selection do
(
X = random 3 16
i.render_sides = X
)
-----------------------------
So in the above situation all we've done is create a variable called "X" which for every object in the scene will generate a random number between 3 and 16. Then the script assigns that value to the segments parameter of one of your splines and repeats the process until it has done this to every object in your selection.
You can use the Maxscript help file to look up what a certain parameter is called, or you can open the maxscript listener and adjust the parameter you want to later script and watch what code appears in the listener. Its an easy way to get the line of code you need without having to open the help file and search for it.
Its pretty simple stuff, but its saved me countless amounts of time. Enjoy.
Lets say you've modeled a bunch of vines using renderable splines (based on a true story), but after placing about 300 of them you realize you forgot to give them enough segments to look rounded. The "for loop" is here to save you. It goes like this.
---------------
for i in selection do
(
i.render_sides = 12
)
-------------------
Its that simple. But let me explain what its doing. "i" could be anything. It could be "n", "blah", "Myfirstofficialblogpost"....etc. It doesn't matter. Its a variable that you make up that will represent each object in your selection. So basically....for (every object) that is selected do...the following bit thats in parenthesis.
In this case inside the parenthesis is a line of code that will change the segments a spline to 12. Because "i" will represent every object in my selection. This script will go through each object in my selection one at a time and change the segments to 12.
Now lets take this one step further. Another really helpful bit of code to know is how to generate random values. With a slight modification you can have the above script assign a random number of segments to each spline.
-----------------------------
for i in selection do
(
X = random 3 16
i.render_sides = X
)
-----------------------------
So in the above situation all we've done is create a variable called "X" which for every object in the scene will generate a random number between 3 and 16. Then the script assigns that value to the segments parameter of one of your splines and repeats the process until it has done this to every object in your selection.
You can use the Maxscript help file to look up what a certain parameter is called, or you can open the maxscript listener and adjust the parameter you want to later script and watch what code appears in the listener. Its an easy way to get the line of code you need without having to open the help file and search for it.
Its pretty simple stuff, but its saved me countless amounts of time. Enjoy.
Thursday, March 27, 2008
First Post!!
I've been wanting to start a blog for a while, but hadn't gotten around to it. I guess the stars aligned and it finally happened. Anyways, the idea was to have a place to just ramble out ideas and tests related to CG, compositing and photography. Maybe some experiments, tips and tricks I've come across, tutorials. Whatever seems interesting.
Subscribe to:
Posts (Atom)