For the Sky Sports “Super Sunday” ident we worked on this year (Mill article), almost every shot had some amount of speed ramping. Needless to say, this is usually where the FX TD has a minor heart attack in anticipation of the hell that he or she is about to go through. However, the flexibility of ICE in XSI now makes the process relatively easy, and this three page article will show you how to do it.

Why is speed ramping a problem?

Physics engines in 3D applications tend to do their calculations on a per frame basis and they assume that the length of time that passes in each frame (known as the simulation step in ICE) isn’t changing. It’s an important optimisation as it simplifies the problem for them.

Numerical accuracy for collisions, and forces such as damping, are highly dependent on the simulation step. If the simulation step was allowed to change on each frame, it would introduce erratic behaviour into your object or particle motion.

Another problem you’d notice is that for different speed ramps, you would get different results from the simulation. Small inaccuracies in the way the simulation is calculated give rise to larger effects later on, despite starting with the exact same initial conditions. The key point to note is that larger simulation steps are more inaccurate than smaller ones, and changing the speed ramp means that you’d be introducing those inaccuracies in different places. This isn’t much good as you might have to redo your simulation if your speed ramp ever changes (which on our Sky job, it did on a number of occasions).

Methods for dealing with speed ramping

There are three ways to deal with speed ramping at the 3D stage:

1. You add support for speed ramping into your physics engine. Actually, for particle simulations this isn’t as hard as it sounds. You just have to create your own “Simulate Particles” node. For rigid bodies… well… good luck! There’s a lot of maths involved, and it’s far from easy. Plus you’ll have to write your own collision system. (Yeah… no thanks!)
   • Pros:
     If you can get it to work, it’s a simple way of achieving the right result. You just run your simulation and you get the result.
   • Cons:
     For anything other than particle simulations in ICE, it’s not particularly viable unless you’re good at physics programming. It would introduce inaccuracies. If your speed ramp needs to change later, you’ll have to re-simulate, and there’s no guarantee you’ll get the same results.
2. You simulate and cache the simulation at the same frame rate as you’re delivering the final sequence (in our case, 25 fps). At render time, if you need to go to slow motion, you’ll have to stretch out the simulation to slow it down. This means you’ll be trying to render at non-integer frame numbers and you’ll have to interpolate the particle positions and other attributes.
   • Pros:
     It’ll be fast and you won’t have much data to cache. You’re doing the minimum amount of work needed to get the result. If the speed ramp has to change, you don’t need to re-simulate since you’ve cached out all your data.
   • Cons:
     It’s unlikely that this will look very nice if you have any collisions, as any sharp changes in velocity will look sluggish due to the interpolation. You might get away with it though, so it’s worth a try if you are up against a tight deadline.
3. You simulate and cache the simulation at the highest frame rate that you think you’ll need (in our case that was 100 fps). At render time, you’ll usually be replaying the cached simulation faster (e.g. when it’s running at 25 fps) by missing out the frames you don’t need. To guarantee smooth animation, you still need to interpolate between frames, as more often than not the dynamically changing frame rate will result in non-integer frame numbers.
   • Pros:
     Calculating at the highest frame rate means that your simulation will be super accurate. As with (2) if the speed ramp has to change, you don’t need to re-simulate since you’ve cached out all your data.
   • Cons:
     You’ll be spending a lot of time simulating and have a lot of data to cache.

What we used on Sky

The third option is nearly always the best way to go. It’s a good solution, providing you’ve got plenty of disc space, and have enough time to do the simulations.

For Sky, we animated and simulated everything at 100 fps and cached all that data to disk. (If an analogy helps, just think of it as filming live action with a high speed camera).

For each shot, we had a curve that represented the current frame to load from the disk cache. This curve was an incredibly important asset in our pipeline as it was used to synchronise multiple packages (XSI, Houdini, Maya, Massive, Cinema 4D) to render everything at precisely the same moment in time.

Note that since the speed ramps gave smooth changes in frame rate, the frame numbers given by the retime curve weren’t usually integral values (e.g. 1, 2, 3, 4, etc.), but were fractional (1.4, 2.8, 4.2, 5.6, etc.). This meant that camera and object transforms, meshes, and particle attributes had to be interpolated to be properly evaluated at these fractional frame values. More on that later.

There’s one last issue you need to take into account when doing any sort of retiming of a cache. You can read about that on the next page.

The brief was pretty simple. We had to create a lightning storm over Frankfurt and show a direct strike on a bridge over the river. We were told to “Just make it look awesome!”. Sure, we can do that!

I’ll write a post soon on how we made it. But for now, here’s the finished piece, as published on YouTube:

So it turns out that one of the best things about doing a viral is that you get to see some feedback from the public in the comments they leave on YouTube. Most people spotted it as a fake, and I really don’t mind as they were quite complimentary on the whole. If we’d kept it totally within the bounds of reality the piece wouldn’t have been so effective. The point of the viral was to make sure that it got everyone’s attention.

Other people totally bought it.

“Your all f******s. Why would someone fake something like this? What’s the point? Wow I faked a lightning storm for 100,000 views? This is most likely real. But the dudes who shot this are idiots for being in the water during s lightning storm”

One guy thought it was fake and started making assertions such as:

“actually, if you look closely, you can see they are not in the water – they are driving on a road at the riverside!”.

Nope, we were definitely in a boat! I think it’s amazing what people convince themselves they’re seeing.

This made me laugh too:

“Oh my god, is this REAL?

And can Audi protect me from lightning?

PLEASE HELP!”

Finally, this one’s probably my favourite (which only makes sense if you’ve seen Total Recall):

“haha, is the governator on that boat? are they on their way to ze mines to turn on the reactor….damit cohagen you know the reactor makes air, why don’t you just turn it on? Quaid….Quaid….’start the reactor’ “

Overall the campaign was a success. At the time of writing this, the spot has had well over 288,000 hits, the vast majority of which happened in the first week of it being posted. There was a lot of press coverage too, particularly in the automotive press as you’d expect. It was all to publicise Audi’s new e-tron concept car. The e-tron has one battery, four electric motors, and an insane amount of torque which means it can go from standing to 62 mph in 4.8 seconds.

Here’s the link to Audi’s viral campaign website www.electricityuntamed.com where you can see a video of the launch, or you can go here to view a short article and Audi’s official press release about the e-tron.

You can read The Mill’s article on the job here.

In addition to “Storm Over Frankfurt”, two other virals were shot. Minimal post production was needed by The Mill except for some rig removal work. They’re great spots and very funny, so I’ve embedded them below for your convenience. Enjoy!

Back to School

There’s no doubt that leaving my job at Lionhead Studios to go to film school for a year was a risky move for me to take. It was a tactical decision to try and rebrand my career towards film and commercials work; something that I’d been trying to do for a while.

One of the other reasons that I decided to sign up for the VFX/SFX course run by the NFTS was because of the pyrotechnics module that they offered. Having grown up watching films like Raiders of the Lost Ark and being utterly consumed with fascination about the stunts and effects, I felt that this was my opportunity to satisfy that craving.

I wasn’t disappointed. Not even close.

The Setup

There were six of us on the course: Kate, Kia, Mattias, Nick, Seru, and myself. We were all from a wide range of backgrounds which made for an great mix of skills and experience. The first month on the course was spent learning about fire, explosives, rain, snow, firearms, and many other areas that an SFX technician has to have a good understanding of. The car explosion stunt was the climax to the course module.

I’m not sure where the idea came from, but I think I suggested that it would be a cool idea to blow up the car with a rocket launcher. I figured that blowing up a car without a good explanation would be a bit dull. Far better to make it look like we were hitting it with an RPG. Michael Bay eat your heart out!

One thing we all learnt in that first month as trainee SFX technicians: in a low budget scenario, you literally need to beg, steal, or borrow whatever you need to get the job done. Resourcefulness can make the difference between getting the shot, or not.

The begged items came from Graham Brown in the form of fishing wire and some fireworks. Although to be honest, I didn’t need to do too much begging. Graham as usual was more than happy to help out.

In true Blue Peter style, the rocket launcher was made from a cardboard tube; this time, stolen from our communal TV room at the film school (it was in a pile of rubbish and no one was using it). I painted it green, and fixed a wall bracket to it as a makeshift sight. A bit of yellow and black tape finished it off.

To make handbrake turns easier, I rigged the steering wheel with a cylindrical door handle borrowed from a door found on the NFTS main stage. I should point out that it wasn’t from a real door, just one that was lying around previously used as part of a set on an earlier production. Before we blew the car up, I got it back and reattached it to the door the next day.

One thing I didn’t mention in the guerrilla SFX “beg, steal, or borrow” toolkit was bribing. The NFTS course managers persuaded Arri to come along with some of their high speed cameras. Not through any monetary bribing (this was low budget, don’t forget), but as a promise of some great stock footage for any of their product demos. In the end, they brought two cameras which, despite the poor light conditions, were run at 200 fps and 400 fps.

The Car

We didn’t have any sort of story line or plot as we were more interested in the SFX, but we still wanted to shoot some footage with the car. If we’d had two cars it would have been better, but again, our budget didn’t stretch that far. So we kept it simple and just used the deserted market stalls as a background for some interesting shots.

You might be surprised how tricky it is to do a handbrake turn in a Ford Escort, even in the wet. It took a bit of practice but I got there in the end. The door handle on the steering wheel helped, but I found the key was to initiate the turn, slam on the brakes to throw the weight forward, and then yank on the handbrake to throw the rear end round. The one that you see in the video nearly went 180º.

After we’d done the other shots with the car, we did a final run ending up with the handbrake turn. With the car in the final position, we set about stripping it down to remove any dangerous or unnecessary parts. High on this list was the petrol tank which was drained and removed. We were also told that the pistons for the hatchback boot can be highly dangerous in a fire and can explode violently. Apparently the fire services are quite nervous about these things going off in motorway fires!

Other things that were done: the car battery was removed, tyres were let down, brake fluids and oil were drained, and many other parts were removed. All this was to make sure that we didn’t have any unpredictable results that could be a safety hazard, and also because we didn’t want the car to burn for hours after the explosion.

In case you’re wondering, the car had been bought for about £300 specifically for us to blow it up. Coincidentally, it bore more than a striking resemblance to my own car at the time so I swapped the wheel hubcaps as they were better than mine!

Rigging the Explosives

After the car had been stripped down, we set up the charges. Unfortunately, there’s a limited amount of detail that I can go into without being a bit irresponsible by telling everyone how to blow stuff up, but suffice to say, we used several standard petrol based mortars along with a couple of charges to blow the windscreen.

All the charges had to be wired up with long lengths of electrical wire so that we could be at least 50m away when it went off. The charges were connected to a custom made detonation box belonging to Graham.

The rocket launcher (err… cardboard tube) was connected to the front of the car by the fishing wire. We sellotaped a firework rocket to a drinking straw that had the fishing wire threaded through it.

During the set up, we were all aware that it was a race against time. Being November we had a limited amount of daylight, and it was made worse by thick cloud cover and drizzling rain. Trying to film something as bright as a fiery explosion isn’t something you want to do in complete darkness, especially with high speed cameras. You’d see either the explosion or the surroundings, not both; at least not in any detail.

Bang!!

So when the time came to set everything off, we were knackered. Making sure that all the cameras were up to speed, we gave a countdown and lit the firework. It shot along the fishing line, hit the car, which blew up in a series of explosions, one of which sent the windscreen 30 feet into the air. Everything worked perfectly and at the right time; something that we were all surprised by considering the pressure we had been under and the weather conditions.

We had spent a lot of time carefully laying out and labelling the numerous cables that were used to set off the explosions. Since we had limited resources, many of the cables were made up of two smaller ones, so we had to make sure that all connections were working. I think we checked everything at least twice. Graham’s firing box had a special mode for testing connections by sending a low powered current down the cable and through the charge. It wouldn’t be enough to detonate the explosive, but enough to be able to check the continuity of the circuit. We would still treat it as a live firing though… just in case.

Safety First

There are lots of precautions one takes when working with explosives. While I said that I wouldn’t go into any details on how to make something go bang, I think it’s safe enough to discuss some of the safety measures we took.

You have to be very aware of what everyone is doing, especially when you are connecting the charges to the lines. For example, it’s all too easy to leave the battery connected to the firing box with the key in the on position. While that wouldn’t detonate the charge (you’d still need to press the right button), it’s not a situation you want to be in. The standard Health and Safety strategy is that it’s everyone’s responsibility to look out for each other, and to make sure that these slip ups don’t happen. It’s all about minimising risk.

Generally you don’t want to be wearing anything that has a tendency to create static electricity. It is possible (although unlikely) that static can generate enough power to set off a charge. Synthetic materials are well known for being good sources, so they should be avoided.

This one’s important (and you’ll recognise this if you’ve ever bought fireworks). Never return to a charge if it doesn’t go off. There’s a procedure to follow in this situation. Generally the safest thing to do with a dud is to place another charge next to it, and detonate one using the other. We were shown a video of what can happen if you try to take shortcuts. I believe the poor chap lost hearing in one ear and part of a finger.

The best way to make sure a charge is safe is to twist the two connections together. It makes sure that there’s no potential difference between the wires so it’s impossible for the charge to be set off by a voltage. Most pyro charges are supplied in this configuration. Of course, there’s no guarantee that you won’t set them off with excessive or prolonged exposure to heat or some type of chemical agent, so you still need to take care.

Other Considerations

Whenever you do any sort of pyrotechnics work, it’s nearly always a good idea to let the local emergency services know in advance. With an explosion as large as the one we did, it would be pretty likely that someone would call the fire brigade – which they did. About ten minutes after we ignited our Ford Escort bonfire the fire services turned up, blue lights flashing.

If we hadn’t spoken to them first, they would have charged us a call out fee. They were a great bunch of guys though, and were probably happy for the break in their routine. The NFTS also did a leaflet drop in the area a few days before so that local residents wouldn’t be alarmed.

Graham Brown was our pyrotechnics tutor and supervisor. He worked for many years at the BBC providing special effects work for a huge number of different shows. When he’s not tutoring at the school, he still does work on a freelance basis for shows like Waking The Dead (which I was lucky enough to assist him with on three occasions – more in a future post). I’d like to take this opportunity to thank him for all his enthusiasm, dedication, and hard work, and for such an amazing experience that I’ll never forget.

Thanks should also go to John Rowe and Sarah Hayward, the course directors, who worked tirelessly to make sure our time at the school was chock filled with fun things like this to do. And finally a big shout out to the other guys on the course – those were good times eh!

Rear, left to right:
John Seru, Kate Walshe, Mattias Engstrom,
Nick Preston, Kia Coates, Andy Nicholas.

Front:
Graham Brown

(And then we had to clear up the mess)

The Video

Here’s the final cut with a wee bit of compositing to make it look like the car was still moving when we blew it up.

The Add SOP on the left uses a multiparm to get a list of point positions from the user, while the Object Merge SOP shown on the right uses a multiparm to merge geometry from multiple sources at once.

This simple tutorial will show you how to use multiparms in expressions and your own tools.

Introduction

Multiparms are Houdini’s way of getting a list of items from the user. They comprise of a single parameter that stores the number of entries in the list, and a list of parameters numbered sequentially that make up those entries.

Something which is particularly useful is that each entry doesn’t have to be made up of just one parameter. Houdini lets you store multiple parameters in each entry. In effect, you can think of each one being like a record in a database. Each one can contain a number of fields in which you can store information.

In this tutorial, I’ll only be looking at a multiparm that contains single parameter entries.

Initial Setup

To start, make a Geometry object, call it “geo_boxes”, and press Enter to jump inside.

Inside, create a Box SOP, and a Copy Sop with their default parameters, and connect them as shown.

Sticking to the Houdini convention that most people use; add a Null Sop called “OUT” and set its display flag.

On the next page, we’ll create the multiparm.

Last week I was sent to VFX supervise a night shoot in Germany (details of which will have to wait for a future post), so I thought it would be useful to have some LED trackers in my toolkit. All the components can be bought online from www.maplin.co.uk or by visiting one of their stores. Here’s a list of parts you’ll need:

(You can choose which color LEDs to use)

Of course, when I got to the shoot, I didn’t need them (why does that always happen!). Anyway, here’s the video:

I shot this on my Canon 5D Mk II with the 24-70mm f/2.8 L USM lens. I wanted to try out a bit of video and thought it would be a good test. I’m really pleased with the quality, but getting focus is a major pain in the backside.

Also, is it me or does the video look like it’s sped up slightly? I guess it might be to do with the 5D shooting at 30fps – maybe there’s some sort of frame dropping down conversion by Vimeo that’s making it look like that. I’ll look into it, but add a comment if you happen to know anything.

And finally…

Until now, my impression of “Twittering” has been that it’s an egocentric past-time for people who should probably go out and get a life. (A perfect fit, you might say for someone in CG and who has their website named after them). But you know what? It’s actually quite a lot of fun and potentially useful.

It seems that people are tending to use it, less to document the minutiae of their dull existence (although inevitably there will always be a few), but more about letting people know about little snippets of information, cool resources, organising social events, and as a replacement for messaging services.

So what will I twitter? My intentions are to post any random snippets that I don’t think are suitable for posting on this blog, and to chat with like-minded folk. If that sounds like your cup of tea, then you’re welcome to join me.

It is possible to use all sorts of methods to create plotted animation curves (like, for example, the Trail SOP), but the aim is to create a curve that will respond to any future changes in the object’s animation. Additionally, I also want to be able to specify the amount of detail in the curve. To finish the tutorial, I’ll show you how to turn the curve into a Houdini Digital Asset (HDA) so that you can easily reuse it in your own scenes.

The CHOP network

In Houdini, CHOPs allow us to look at animation data across the entire time range of the scene, and process it in many different ways. CHOPs can offer unique solutions to problems that would otherwise be very difficult to solve.

So to start, add a Null object and animate it any way you like. Call it “animatedNull”. Note that in the image to the left, I’ve added a particle trail so you can see where I’ve animated it.

Add a new Sub Network node next to the Null node and call it “AnimationCurve” and press Enter to go inside. Press Tab again and create a CHOP Network node and rename it to “chop_GetAnim”.

Go Inside the new CHOP Network and create a Fetch CHOP called “fetch_Anim”. Change your main window to Motion View. In the Fetch CHOPs Node parameter, select the animated null that you created (which should be /obj/animatedNull), and in the Channels parameter, enter:


t[xyz]
 


Finally, add a Null CHOP and feed the output of the Fetch CHOP into it. Rename the Null to “OUT”, and enable the display flag for the new node.

Press h in the main viewport to frame the curves so that you see something similar to that shown in the image below.

The CHOP network and imported animation curves

The Fetch CHOP also has a parameter called Sample Rate which can be found on the node’s Channel tab. Changing its value changes the number of points (known as samples in CHOPs) that make up the animation curves in the viewport. If you press d in the viewport, you will toggle the display of dots that show the curve samples. Keep the Sample Rate set to default for the moment.

On the next page, you will use this value to control the resolution of your curve.

If you’ve ever watched The Wire then this is essential viewing. If you haven’t seen it, watch this interview (link below), and then go and buy the boxed set. You won’t regret it.

 

 

David Simon used to be a reporter for the Baltimore Sun for twelve years before turning to screenwriting and producing for The Wire. He has some fascinating insights into what he thinks is wrong with the modern world.

These links to the interview will open in a new window:
Video 1
Video 2

New to Houdini 10 are Motion Effects. If you haven’t come across them yet, just right click on any parameter and have a look inside the “Motion Effects” sub-menu. It offers you a list of choices on how to post-process any animation that you already have assigned to the parameter.

If you want to try it out, just add a null at object level and animate it’s position to do something funky. Now right click on the main Translate parameter (so that you’re indicating all three tx, ty, and tz channels) and select Spring from the Motion Effects sub-menu. You should see your null springing about all over your viewport. If not, try turning your damping to zero and play around with the spring constant.

The Motion Effects menu is just a simplified way of exposing some of the CHOP functionality to your animations. It’s a great way of experimenting with animations to see what it can add. Of course, they only offer fairly simple operations, but are a great way of learning what CHOPs has to offer.

Using the Motion Effects menu for your own tools

As it happens, the menu for Motion Effects also happens to provide a particularly handy hook into the user interface for a TD to exploit. If you investigate the documentation, you’ll find that the menu is entirely driven by an XML file. What the help file neglects to mention however, is that you don’t have to modify the original XML file provided by the default installation. You can also create your own in your user directory. This is great, as it means that you can customise the menu to your own requirements, or just use it to develop in before publishing to your colleagues.

As part of a current project, I needed to export individual animation curves from XSI to Houdini. As with most technical challenges, there’s always more than one way to skin a cat. In my particular case, I happened to have a Python class that would take a selection of XSI animation curves and export them into a *.clip format that can be read directly by a Houdini File CHOP.

With the XSI export already taken care of, I needed a tidy solution to import the curve into Houdini. The Motion Effects menu seemed to be an ideal route.

The handy thing about Motion Effects scripting is that a lot of the contextual information is provided to you. You get told which parameter has been selected as well as which modifier keys were pressed. Essentially, if you ever want something to happen based on the selection of a parameter, then hijacking the Motion Effects menu is a pretty good way to go.

The XML file shown at the bottom of this article takes the following steps:

1. Obtain reference to parameter, the parameter’s node, and it’s parent. (The variable kwargs is a dictionary provided by the script host for retrieving context information. See the documentation for more info.)
2. Ask the user for the filename to a *.clip or *.bclip file to load
3. Create a CHOP network node and add the following CHOP nodes: File, Delete, Rename
4. Set parameter values on the CHOP nodes to do the following:
   • Delete all but the first channel
   • Rename the first channel to the same name as the parameter that the user selected
   • Set the export path to path of the parameter’s node
5. Make the connections between the nodes
6. Set the export flag on the final node in the CHOP network

In less than 20 lines of code, we’ve created a very convenient tool for importing *.clip files.

It would be a simple job to expand on this script to do something a little more intelligent with the CHOP network. For example, it would be possible to analyse the names of the imported clip channels for things like “posx”, “posy”, and “posz” and to apply them to the correct “tx”, “ty”, “tz” channels in Houdini. In my particular situation however, the current functionality is convenient enough for my purposes. At the very least, it provides a handy way of setting up the basic network to handle the *.clip file import.

Installing the XML file

Installing this new menu item couldn’t be much easier. Just copy the above XML and paste it into a new text file called MotionEffectsMenu.xml, then save this file into your user/houdini10.0/ directory. It is possible to add your definition to the installation XML file, but it’s not recommended for obvious reasons.