In this project, I had the pleasure to contribute dust effects. This is something, I’d wanted to do since I watched breakdowns of loads of dust fx for ‘Prince of Persia’. So, I was really happy when Marijn asked me to work on this shot. As a refresher, I’ve included the final graded shot below:

View in full resolution: H264. (more…)

I (ed: Richard Levene) am a lighting and rendering artist and have been working at a cg visualisation and retouching studio in London called Recom Farmhouse (http://www.recomfarmhouse.com) for almost 4 years. Many of our jobs have been for car clients and I have produced many car renders over the years. Guess this is why my friend Marijn (vfx sup.) thought of me when it came to thinking who could do the car for this shot

I was tasked with animating, bit of modelling, shading, lighting and rendering the car for this shot. Have to admit that animation is not something I have done a lot of. At work we tend to produce still images and we have done very few animations, the odd car turntable but never a moving car. Thankfully the car was only required to move in one direction so I knew it would not be too tricky, but I was concerned with how easily/quickly I could animate/keyframe the fine details of the car like tyres reacting to the terrain and the subtle car body movement that add to believability.

First thing I did was import the matchmoved data into a new Maya scene (Maya 2011 x64 Subscription Advantage Pack) to make sure there were no problems. I always work in ‘cm’ units so had to make sure the track was coming in at the right scale. The tracking units were in meters so I grouped the camera and ground plane geometry provided by Marco and scaled it by 100 units. I applied the image sequence of the plate to the imageplane and everything lined up perfectly. Then imported the model of the car to check the scaling of the car to the plate looked correct. Which it did.

The release of Subscription Advantage Pack for Maya 2011 meant I was able to try out a new plugin shipped with the update. Craft Director Studio. I had seen a video demonstration of the plugin on the Autodesk Youtube channel (http://www.youtube.com/watch?v=0KqLe66uFG8) at the point of the release and thought that this would be the perfect opportunity to test it out and it could be the solution to my animation fears.

The plugin comes with a few free pre rigged vehicles that you can control and parent your models too. You are then able to control your car and drive it around using your keyboard or joystick/pad directly in your Maya scene! You have controls to adjust the suspension and weight of the car, as well as the it’s acceleration, top speed, maximum steering angle and braking force. Check out the link above for a look at it in action (skip to time 1:04).

The model of the car I had was very dense so in order to get good real time feedback while controlling the car, I created a very rough proxy version and parented that to the dummy rigged vehicle instead. The parenting requires you to have your model grouped in the same way the plugins rigged vehicle comes. Groups for each wheel and body.

The best part of this plugin is that your vehicle will respect the ground plane. So if you have a very bumpy ground the car will react to it and follow the geometry.

So I subdivided my ground plane geometry quite a bit and used the Sculpt geometry tool to pull and push bumps into the road to mimic the bumpy desert ground. Very very quick and roughly.

I was now ready to record my car animation. I only had to drive the car forward in one direction so not much work or control was needed. After the first playback I could see the ground was too bumpy and it needed to be toned down. I adjusted that and was happy with the result, so I baked out the simulation to keyframes. With this I was then able to manipulate the animation curves to control the speed of the car and positioning to meet the directors in and out points.

I then parented my full res car geometry into the vehicle rig groups and I had my full res car animated Here is the approved playblast:

With this animation signed off, I sent over both the proxy and the full res geometry car animation scene to Erik for him to use for the cloud simulation and dust interaction renders.

Prior to starting on this shot, I had just completed a job using Vray on a project at work. I was very new to the renderer and thought this would be another good opportunity to learn it even more. I have always been a mental ray user but for the particular job at work, we needed the ability to interactively light our car with geometry mesh lights and the custom geometry light shaders that are available for mental ray do not play nicely with IPR. Vray RT and geometry mesh lights proved to be a winning combination. The Vray plugin for maya is very well integrated and it is very easy to use compared to mental ray in Maya. (Will leave this for another blog post)

With the car being black, you can only really light such a car with reflections so the hdr was very important for this. The hdr was supplied to me by Marijn, taken from on set while filming. It was not from the same location as the backplate sequence, but it was in the desert, so you would never know. However the time of day the hdr was shot at was slightly different, also the colour balance of the hdr compared to the plate was drastically different.

In order for the car to sit nicely in the plate some Photoshoping was necessary to get the hdr to match the backplate better. I very crudely replaced the sky and made the sun a lot higher as well as grading the ground.

I had reference images of the real car on set so was able to get a better idea of how it needed to look. I started to apply some shaders the main shaders such as the car paint, glass, black plastic, rubber, chrome etc as well as creating a tyre shader and texture to make it look like the tyres had been driving in the sand. Some quick UVing of the tyres was necessary for this.

Here is an early test with low sampling.

A few tweaks and I was ready to setup up for final rendering.

We had worked out in previs that the car would become visible through the dust cloud at around frame 35, however to be safe I setup the renders to start from frame 25.

I split up the car into 3 elements. The car body, wheels and shadow. The reason for separating the wheels from the car was due to motion blur. We knew we would want the car motioned blurred but I was unsure at how long it would take to render both the car and the wheels motioned blurred in the same scene. We worked out we could get away with motion blurring the car body in post using a motion vector pass (velocity pass) from Vray but the wheels would need true 3d motion blur. So splitting them up was the best option.

Various render elements were created along with the beauty to give Linus more control in comp, but I think as we had such little time he only really used the beauty pass of the car body and wheels. Lots of masks were rendered as well for all the various materials.

Review

I was really happy with the quality of the car. Looking back there are a few things I would change regarding the car. I would add more motion blur to the wheels. Unfortunately there was not much time for rendering so I kept the motion blur quite minimal to assure all passes were rendered in time. I would also tweak the car animation slightly. Near the end of the shot the car body jutters quite a bit (only a few frames) but this would not really happen on a car like this. The suspension would smooth it out. But think I am just nit picking

Overall I think the final shot looks amazing. I thought it was going to be really hard to marry all the effects together, but Erik and Linus did an incredible  job. Not only was this shot great, but every shot that was completed for this project looked brilliant. Huge credit to everyone that worked on this project and it was a pleasure working with everyone.

Erik is letting me, Marijn Eken, write a guest post on his blog to introduce a series of posts about a music video we collaborated on.The music video was for the official song of the 2011 Asian Cup, by Jay Sean. You can see the completed video here.

Jay Sean feat. Karl Wolf – Yalla Asia ft. Radhika Vekaria.

For this project I was the visual effects supervisor, overseeing the whole production from concept to delivery and also doing the color grading. I was also on set for the filming, which took place in Doha, Qatar. It was shot on the Red One camera, which gave us the nice option to send around trimmed R3D files to the artists. We used ShotRunner to communicate among the group of 8 people that worked together over the internet.

There are over 100 vfx shots in the video, of which 64 green screen shots and we completed the work in essentially two weeks time. But, for this series we’ll focus on one shot that was a particular challenge.

The client’s idea was to have a pack of dogs run through the desert and turn into a car. They suggested a morph, but I couldn’t see how four dogs morphing into a car would look good. So I opted for having a dust cloud form from the dogs and kind of conceal what actually happened and have the car appear from the cloud. Here is the finished shot.

View in full resolution: H264.

The first challenge was how we would shoot this. Doing this in two passes (one with the dogs, one with the car), would require some kind of motion control to get the same camera move twice, which was not an option. So I quickly realized we would have to do the car in CG. The only real elements would be the desert and the dogs.

I had planned to use golf balls to aid the match-moving. But the reality of the shoot proved I couldn’t use them. The dogs were going to chase after a gazelle. Yes, a real live gazelle. So this made it quite impossible to plan out a route in advance. Luckily the desert floor was hard and cracked, which gave us some features and I just had to hope we could track it later.

We ended up getting very little usable footage. The part we picked had only one dog in it, but we needed four. So we ended up duplicating the dog in the final shot. Linus Hofmann did that and will elaborate on this in a later post.

The footage was particularly shaky, so we needed stabilization. We didn’t want to run it through some stabilizer and then track it, because that would probably make the match-moving harder and less accurate. Marco de Goeij tracked the original shot and provided me with a solid track. What we then did, was use a 3D method for stabilizing, rather than a 2D warp. Since the desert is essentially flat, I created a simple piece of geometry inside Nuke to match that and projected the original plate from the tracked camera onto that surface. I then duplicated the camera and filtered it’s path to create a much smoother camera path and rotation. Looking through this smooth moving camera, we got our stabilized shot. This was the camera that was passed to the others to create all the CG elements from. See the difference between the original and stabilized shots here.

View in full resolution: H264.

It was a bit of a challenge to work out how we were going to have all the elements for the shot come together, as multiple people at different locations and with different software were involved. Richard Levene would render out the CG car in Maya and hand over the animated car model to Erik, so he could use it as a hold out for the dust simulation in Houdini. Linus Hofmann had the job of bringing it all together in the compositing in Nuke, which required a fair bit of tweaking to get just right.

It was a challenging but ultimately fun project to collaborate on. The quality of the end result amazed the client, which is alway nice to hear.

Now the exhaust wall stuff is done and made into a tool, attention has shifted back to the explosion animation and simulation. By now all the major systems for animating and hand-over to simulation are in place.

Let me start by showing you a test animation for that I’ve rendered out. I did a very quick multi-pass comp on the render to attenuate reflections a bit and add some glows. The animation is rendered at 8 times slow motion.

View in high resolution: H264.

(more…)

Here’s part 2 about my ‘derezzing’ cycle animation. I’ve now more or less finished the setup for ‘disintegrating’ individual fragments that will explode of the cycle when it crashes into the exhaust wall of its opponent.

After some basic cleaning up of my script, I thought, “let me do a multi fragment test and see what happens…”. This reminded me of how awesome the procedural nature of Houdini truly is! I added another fracture plane to my breaker and held my breath while I ran a simulation of the cycle without any animation, just sitting there in 4 fragments and let the Tron universe do its thing

The following image is the result that I found when rendering frame 23 once I stopped the sim there…:

I was rather blown away by this, I must admit, even though that may sound really narcissistic (lets just call it lasting boyish love of all things shiny and glowy). The only thing I did to the render coming out of Mantra was throw it into the comp I had already prepaired for a rerender of my original test animation which follows below (which is nothing more than a slightly rebalanced throw-together of the render passes). Note that the blue glowing particle stuff coming from between the fragments is not yet the explosion of fluid as seen in the real Tron Legacy shots. This will be a separate fluid sim.

Anyway, as mentioned above, I rerendered the first test animation through the current setup. You can see it below:

View in high resolution: H264.

The next steps involve quite a bit of keyframe animation of the cycle hitting the wall and the initial movement of the fragments before they are handed over to a dynamic sim. While working on that, I’ll run a render of the full cycle disintegrating in the mean time on my ‘farm’ (as in the single frame above), I just want to see it moving .

Until the next post…

Cheers,

Erik

Here’s part II of ‘Rezzing’ a light cycle. In the previous post, I discussed the fx animation part of this effect. In this second part, I want to get into the shading, rendering and compositing.

As in Part I, I’d like to start with showing a breakdown version of the close up rezzing animation:

View in full resolution: H264.

(more…)

Shading time… After a few ‘false starts’ it is time to go through the shading side of the wave system.

Before I get into the shader itself, I thought I’d be a good idea to quickly recap how the UV’s of the wave are integrated into the UV space of the ocean surface. Luckily, I have already posted those details on this here: Another refactoring.

(more…)

Just before I leave home for VFX 2009 in Amsterdam, I found that the render faery had fixed me a nice animation render (or at least most of it) so I thought I could spare some coffee time to post a little update. I did’t have time to look at a little shadowing problem I found later in the animation, but I think that’s easily fixed in the comp.

Whitewater render

Cheers,

Erik

I had a sneaking suspicion this morning that I had made some mistakes in my previous post on ‘Shades of white water’ and quickly found I indeed had. I mentioned ‘Illuminate loop’ multiple times where it (obviously) should have been ‘Illuminance’. The Illuminate Loop is the partner in crime of the Illuminance loop (the one I used). It’s Illuminance’s counter part and lives inside Light Shaders. Sorry for this mess-up.

To make up for the mistakes I thought I’d upload an OTL that contains the single light version of the Illuminance Loop that I used to separate the results for each light Ok, to be honest I was going to upload this one anyway.. but it sounds nice In fact, I think its important to share stuff like this as a payback for learning a lot of stuff from other people all the time.

DEFSingleLightIlluminance.otl

You can place it inside a surface shader. You have to pass in the name of the light you want it to work with. In addition you can toggle ‘backlighting’ on/off. The results are the specular, diffuse and shadow components for the specified light.

Cheers,

Erik

Today was another shader day. I didn’t like the control I had over the particles of the lip spray. From within Houdini it takes a lot longer to tune the look of them and as I was already setting up multi-pass I though it was a good time to completely rebuild a new white water shader. One that would give me ultimate control in the comp in near real time after a Houdini render.

So what I wanted to do was isolate the diffuse, specular and shadow in separate passes per light. This would normally result in six 32bit float RGB passes in my EXR output, which would be quite a lot of data. I remembered however, that I read in the Sony Imageworks Sigraph paper that they rendered the particle passes of the three lights they used into the R, G and B channels of a single pass. This would nicely reduce the amount of data to three RGB passes. This means that you lose the color information for the passes but that’s easily added back in the comp. And by also using the alpha channel the amount of lights can easily be increased to four if need be, but I guess if Surf’s Up only required 3 lights for the whitewater, it will probably be enough for my purposes as well.

All this only left the question of how to achieve this. The basic shader I until now used for the particles doesn’t provide output for individual lights so I couldn’t really use that one. In the great Renderman course I followed at fxphd I had seen how to roll your own diffuse and specular shaders. This involves using an ‘illuminance’ loop which iterates over each light in the scene that can see the currently shaded micropolygon and calculates either a diffuse function or specular function for each light and sums up all the values. So it was clear this would be the starting point of my new shader. The big difference is that I want to have the values of my three lights individually so I can put them in the R, G and B channel. After looking at the Mantra documentation on its implementation of the illuminance look (I love how similar Renderman and Mantra are) I found that you can specify a light mask as a parameter of the loop, so this was the solution for my specific requirement. I ended up using three Illuminance ‘loops’ that each iterate over only one specific light and return the diffuse, specular and shadow values for that specific light. Within each loop I ended up implementing the low-level diffuse and specular functions myself as the build-in ‘lambertian’ and ‘specular’ functions in Mantra are based on their own illuminance loops and its not allowed to have nested illuminance loops. Luckily the expressions for a simple diffuse and specular are fairly simple and straight forward.

There was one additional feature I wanted my new shader to have and that is to optionally allow for backlit translucent spray from the light representing the sun in my scenes. For this I ended up allowing implementing a simple trick which allowed the ‘sun’ light source to illuminate the back side of particles (from the light source point of view) as if it were actually the front side.

Adding a separate shadow pass is constructed by using the ‘shadow’ function which returns the light color after shadowing. I subtracted this from the unshadowed light color which results in an image representing the amount of shadow.

So this concluded the ‘inside’ of my ‘illuminance loop’. The picture below shows my VEX network.

The ‘outside’ of the shader takes care of putting the values per light in the different color channels for the diffuse, specular and shadow passes. In order to be able to render out the beauty pass (or the normal result of the shader in the overall render) the shader adds up the diffuse, specular and shadow passes from the three lights like a ‘normal’ shader would, multiplied by the colors and intensities. The shadow passes took a little extra work as I want the ‘shadow intensity’ on the lights in my scene to not influence the shadow passes while they do influence the beauty pass. So for the shadow passes I multiplied the results with 1 divided by the intensity from the light which brings the ‘intensity’ of the shadow pass back up to 1. Lastly, I added a switch for enabling/disabling the backlighting option for the sun light source.

The picture below shows the VEX network for the outside part of the shader:

The image below shows the resulting set of render passes. Note the colors of the lip spray passes which are the result of having the intensities of the different lights in the RGB channels. Also note that there is only a red component for the specular pass… this is caused by the fact that I didn’t have enough day left to add the specular component to all three lights

Anyway, I had a great day full of the utmost nerdy shader development fun

Now I’m getting ready for the big white water explosion particle system! I’m looking forward to that one.

Cheers,

Erik