Here’s a quick update. As part of my involvement in FOHR (webpage, facebook), I’ve developed a TechnoCrane 50. This will be used for creating the animatic of a teaser shot that’s under development.

The animation rig is based on the actual specs of the real TechnoCrane 50. It can automatically limit rotations and the extension of the arm on both velocity and acceleration.

When these limits are crossed the rig will not move any faster than is possible and the blue and green indicators (image above) turn read and show how many degrees or meters your animation is overshooting the physically possible values. Of course the indicators can be turned off as a whole or individually to remove clutter from the view port. This is also possible for the visualization of the rig itself and the animation handles.

Building in the limits functionality was a fun little project and as in many occasions, CHOPS are your friend. It basically works by first using the Slope CHOP to measure velocity or acceleration (first or second derivative using basic differentiation). Once you have the velocity or acceleration is easy to limit the values. These limited values can be turned back into positions/rotations using the Area CHOP (integration). Using the Export CHOP its easy to push the limited values back to the parameters for translation or rotation. This all works really well and fast as well .

Another functionality I built in was a subject tracking camera head. The tool has a slider that allows the animator to blend between animated camera head rotations or automatically tracking the subject.

Animation can be done in the viewport using the animation handles (see image above) or using the parameters of the tool (see image below).

The limits on the rig are all parameter based so it is possible to change the physical properties of the rig (perhaps setting lower limits to force more gentle moves).

Anyway, it was another fun little tool to build (though not as ‘glamorous’ as water tools).

Cheers,

Erik

Hi,

I’ve had some ‘short’ break before where I didn’t get to updating the blog for a few weeks or so. This time it has been months since my last update.

This doesn’t mean I haven’t been doing anything though. In fact, I’ve been really busy doing some really cool stuff.

I’ve been working on a long project (far from over yet) about which, I can’t really say much However, I can mention that one of the things, I’ve worked on is a high level Python based development toolkit for building tools in Houdini. The most visible part of that toolkit is a user interface toolkit that makes it very easy to develop complex user interfaces for HDA’s, that is heavily inspired on Apple’s Cocoa development frameworks.

This started off as a fairly lightweight wrapper around the nastiest bits of parameter interface coding in Houdini (including wrapping bugs and things I think are just weird, like multi parms and all their behavior). It quickly grew into a full fledged high level UI toolkit and extended into generic, MVC (Model View Controller) framework code (Protocols, Responders, Notifications, Delegates, DataSources, …).

Anyway, it was a cool opportunity to exercise the Python coding muscles and get deeper into Python development in Houdini than I’d ever would have otherwise. At the same time tool development will be more fun than ever using these new shiny toolkits

Another thing I worked on with an ‘extended subset’ of the ‘dog morph team‘, was providing a pile of vfx shots for: The Lost Christmas. Looking at the IMDB page, I just noticed that I haven’t even added myself to the list of vfx crew yet. We as a team added a lot of virtual ice and snow to many shots, personally, I mostly focussed on communication with our direct client: FilmGate and vfx supervision of our team.

In short plenty of cool stuff happening. In the coming period I’ll be working on my water tools again, which I’m really excited about as that’s what my Houdini adventures started with.

And with a little (well… probably better to say big pile) of luck, I’ll find some time to finalize that Tron sequence as well in the coming months, I was already quite far in getting all the technicalities to work, so really should finish it).

To wrap up… there’s also some other developments, I’m really happy with, going on about which, I really can’t talk until it goes public. Anyway, it’s good to ‘be back in the blog’, with a bit of luck I’ll be posting the last of the ‘dog morph’ posts somewhere next week.

Cheers,

Erik

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…)

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.

It’s time for another update on the explosion. It’s been silent for a while now, as I’ve been working on some other stuff while running simulations and renders in the background.

As a side note: I’m really pleased with the way HQueue is working on my little farm. It makes simulations and renders much easier to schedule and manage, so its was well worth a little investment in time to set it up. I’m thinking of writing a little post on my experiences with HQueue so far some day soon.

Anyway, on with the fragments and fluids. I’ll start with a render as usual:

View in high resolution: H264.

This is a render of the latest simulation that I have run on both the ‘faces’ and ‘energy fluid’, it also includes the ‘sparks’ particle sim. As with the previous renders, I ran the render passes through my very basic multi pass setup to tune it a little and add some glows. (more…)

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 another update on the ‘exhaust wall’ part of the ‘derezzing’ sequence. As I was getting the exhaust wall network up to a level I was satisfied with, I figured, why not make it a tool and apply it to the red bike easily. That seemed like a jolly good idea, so I quickly got to work.

First, however, let me show the results coming out of a test render of my new tool (8 times, slow motion). Note that this render focusses completely on the exhaust walls. The background is still a placeholder, so is the grid (too low res texture), and the red cycle animation definitely needs quite some animation love, especially when it hits the ground. It’s also the ‘raw’ render output, with only sRGB applied. But…. with all those disclaimers:

View in high resolution: H264.

(more…)

I just found a nice first few frames dropping out of a first test render for my new exhaust wall shader:

Note that this is straight out of the render, no comp work done it at all, not even applying the fresnel pass to tone down reflections a bit, no blurs, etc. It does nicely show of the new turbulence, reflect and refract parts of my new wall shader..

Anyway, I thought I’d share this quickly before I push a full animation through my basic comp setup in the coming days, while I finish animating and dynamics on the crash.

Cheers,

Erik

To place the cycle crash in context, I’ve started animating a short sequence (roughly based on my ‘previz‘). This is basically what leads to the cycle crashing. My son was adamant that the blue cycle be the one that snuffs it, so that’s what happens. I’ve rendered the second camera angle with the frame rate cranked up by a factor of eight. This will allow for moving in and out of slow motion during this part of the animation.

Here’s a quick flat render of the animation:

(more…)

Here’s a short update on part 2 of ‘Derezzing’ a crashing light cycle. My background render of the falling apart of the full body of the cycle (in 4 fragments) has completed and here is the result:

View in high resolution: H264.

The render crashed around frame 69 for some reason, so I restarted it from that point on, but had forgotten that I had added a ‘RDB Autofreeze’ micro solver to my dynamics setup. This is why there is a little jump in the faces lying on the ground towards the end of the animation. The cycle doesn’t completely disintegrate as the animation I had setup for this wasn’t reaching the rear end of the cycle, which is why it doesn’t completely fall apart there.

Anyway, this was done by basically turning on all fragments, so I guess I shouldn’t complain about these details. I’m really pleased by the result so far. This animation definitely nicely shows what’s happening to the fragments as they fall apart.

In the mean time, I’m animating a first go at the final animation sequence for the crash, which is progressing nicely. The basic animation path for the crashing cycle is done now, next up is creating the proper fragments, based on how the cycle hits the wall and direct each fragment into its initial path before the dynamics sim will take over. This is a bit more work than just throw the cycle into a collision object and let dynamics do all of it, but it allows me to completely control what happens during the crash and where each piece flies off to with what initial velocity.

Ok, time to get back to fracturing and animating…

Cheers,

Erik