I'm current working in Vancouver, Canada as an Senior FX TD for Image Engine on the film The Thing.
I've been working in the field of visual effects since 2003.
I started as a coop student in University, where I had the opportunity to do an internship at C.O.R.E. Digital Pictures in my hometown of Toronto, Canada. I went on to finish University to rejoin C.O.R.E. as a software developer for their facial aging software, APRIL. To the right, you'll see a sample aging of myself, which was used to promote the software.
Since then I've moved into visual effects and have taken my experiences abroad living, learning and working on films in different cities across the globe.
Coming from a Math and Computer Science background, I have worked in R&D writing the next set of cutting edge proprietary software, and have since moved into FX and Lighting to technically and creatively deliver shot work of the highest quality.
I enjoy being multidisciplinary and being engaged in many facets of visual effects. I look forward to new and challenging opportunities in the future.
I'm both a Canadian and Australian citizen holding valid passports from both countries.
On this site you will find links to a recent show reel as well as more information on the projects that I have worked on.
Click on the highlighted posters for more information
Towards the end of my contract at Animal Logic on Legend Of The Guardians, I was approached by Image Engine in Vancouver if I was interested in working on The Thing. Having worked briefly at Image Engine on District 9 prior to leaving for Sydney, I had a good idea about the company and after watching the original 1982 film the reboot is a prequel too, I was keen to come on aboard again, this time for a longer stint.
As this film is currently in production, I will keep my info brief, but will update onces its been released.
Towards the end of my contract at Animal Logic on Legend Of The Guardians, I was approached by Rising Sun Pictures in Adelaide if I was interested in helping out on a short contract on Green Lantern. I was originally in talks on helping out on Harry Potter and the Deathly Hallows: Part 1, but the timing wasn't right as they need people sooner and for longer. I had already booked my flights home to Canada to visit my family as well as lined up work back at Image Engine on The Thing, but they were interested in having me aboard regardless as Green Lantern, which they had just been awarded work on and needed to pick up the pace as they had a trailer delivery to work against right off the bat.
All in all, my contract could only end up being 12 days or 2 weeks and a bit, but it was an opportunity that I was keen to pursue because I've heard really good things about the company.
I like the pace of short contracts which I'de taken before at the end of production, however, I had never really done so at the start of production on a project which proved the most difficult part for me.
I was responsible for contrails for 2 types of planes in a dog fight sequence as well as prototyping ejection seat fluid effects.
I had gotten up to speed pretty quickly on the pipeline and was able to prototype a simulation rig for contrails in maya, which ended getting rendered as instanced fluids in Houdini through Mantra. I had worked out how to get the particles cached out of maya and read into Houdini for rendering and had written scripts to automate the process to the point where it was one click solution to setup a scene for contrails as well as cache out and then in Houdini I had built Digital Assets for rendering them.
With contrails in hand, I had passed on the workflow to Lighting TDs who were freeing up to get early feedback on, while I could then start tackling ejection seat fluid effects which would span across multiple shots. I prototyped my simulation using the Pyro FX toolset in Houdini and leveraged a lot of tips and tricks from the Potter FX crew to help getting going quickly.
I started mocking up a decent simulation and render from a static ejection seat and then started working with cleaned up previs animation in the shot context. To get the control I need I opted to setup my fluid container to be at the origin and local to the ejection seat and then figure out the inverse motion of the world to move through to match the actual motion in the previs. This allowed me to keep my simulation stable and controllable while still ensuring the motion would work. I had blocked out timings and setup a workflow to be able to cache out lowres, upres with renders chained to both.
For 12 days, this is pretty much all I could have ended up doing in that time, and while RSP were really happy with my work, it was difficult leaving as so much was still left to do, before these shots where any where near final assets.
Having spent over a year back in Canada, I was ready to make a move again, and being part-Australian with citizenship and a passport, it was just a matter of time before the right opportunity would take me there! That opportunity was to work for Animal Logic on Zack Snyder's Legend Of The Guardians: The Owls Of Ga'Hoole. Having worked on Watchmen, Zack Snyder's previous film, I knew that this wouldn't be your bog-standard feature animated film.
Getting to Sydney was surreal, I had been on-holiday prior to accepting the position and was in relative limbo before taking the position, but once my future was sorted, the time up until I was on the plane was a relative blur. My first days at work, were met with meeting countless familiar faces from previous studios and projects that I worked on which made it all the more welcoming!
The pace of work at the start was relatively slow, which gave me time to learn the tools and workflow while still being able to settle into the city, which was good, but I was ready for a challenge. The FX department was relatively ahead of the remaining departments which was great, but I knew that things would change once the flow of shots starting pouring through. So even during my training, I was using that time to devise reusable rigs and components that would be stable and work downstream. Animal Logic's R&D team had been building a a proprietary fluid simulation software, SNAP based on their new software platform ALF, but there wasn't a unified approach to rendering and passing off renderable caches to lighting. So using the the toolset I built a rig procedurally that could be created to render fluid caches with controls built to making lighting them as easy and as fast as possible. This involved working with R&D to get specific features implemented so that the rig could work in production.
I began applying that methodology to other parts of the fluid pipeline as well. SNAP as tool was remarkable, but it was quite difficult to access for beginners as well as cumbersome to do repetative tasks with quickly. I added additional procedural tools for building and modeling clouds, fog, mist, and other psuedo-static atmospherics. The approach was to allow artists to build components easily and those components could be made more complex by using them in conjuction with other components. I had also applied this methodology to simulation as well. So that an artist could build a fire or fluid simulation in a matter of minutes than relying on an existing rig or having to build one from scratch. As there were other artists building rigs which could be made resuable, my components would allow any existing rig to be modified easily either in new versions of rigs or in shot specific adaptations.
I took this a step further by then being able execute these tools to quickly layout a scene that would require multiple instances of a particular rig or SNAP graph in a particular shot. I also took ownership of the shelf to update and employ other time saving and easily accessible tools to submit simulations to the farm for caching.
Having come from an R&D background, "tooling" up a show came natural to me, but I had thrown off the shackles of being developer to be push my artistic and creative eye, so while I was writing tools to help myself and my fellow FXers, I ultimately wanted and had shots to do!!
Having done a lot of water prior, I was tasked with delivering 3 shots of stormy oceans. One shot in particular was an extreme closeup of our hero owl facing a wave rolling towards camera as a Guardian owl is revealed. This shot required not only extremely detailed ocean, but subsurface scattering as well as churn and spray to an extremely high level of detail due to the proximity to the camera.
There were existing tools for oceans that were already accesible. There was a Maya Deformer and PRman Shadeop that leveraged Jerry Tessendorf's FFT technique to generate detail quickly. I built a rig that would would allow me to create multiple displacement layers which I could craft using the deformers, but would ultimately end up generating at rendertime all in displacement. This was sufficient to get the ocean detail, the next step was intergrating a foam texture which involved projecting a texture from the art department that added color and additional displacement at the shader level. I leverage Surface Scattering to get the upwelling and coloration of the thinner portion of the waves. As the time of day for ths shot was predawn and overcast, I also applied subsurface scattering to the foam to get the reveal of the foam when waves were thinner! Combined with the standard shading techniques of reflections, refractions, and specularity surfacing the ocean was in good shape.
The next big challenge was to get convincing churn and spray ripping off of the peaks of the waves. We could calculate curvature at rendertime and then we could use that information to bake a point cloud which we could emit particles from which would get our emission working correctly. We also baked the velocity of the wave into the point cloud so that in simulation we feel the connection of the particles from the wave motion. As a technique this was working and sound, and I could iterate the simulation, but due to close nature of the shot to camera, it became difficult to generate enough detail in simulation and shading. I adapted the simulation to rather than emit from a point cloud, but to emit from a texture off of the deformed geometry I was using to both model the wave as well as use for collision dynamics. To do this meant we still baked a point cloud, but we then rendered the curvature in the point cloud to the uv space of the of the ocean which made texturing the curvature accurate. This meant I could then composite my animated emission texture with additional elements including the foam texture as well as other standard noise patterns. Furthermore, I then devised a way to chop up my ocean emission surface into tiles so that I could get a much higher density and tighter solve. This meant I could distribute the simulation onto multiple machines on the farm to get churn for the entire surface. This was a technique that I first explored on Watchmen which worked remarkably well, but applied to heightfield displacement. The crucial difference here is that since my ocean detail is tilable also tilable in space, i could simulate my particles on this tile, which then would allow me to place the cache in space for rendering to fill up the background and midground of my ocean with churn. Also because of the proximity to camera I could control the level of detail of the churn by having smaller tiles closer to camera and larger ones in the distance. Our churn simulations were used to emit our spray, so this piggy backed our our distributed level of detail approach for simulation and rendering to get the detail we need per shot. For certain shots, I ended up rendering the churn as streaks as well as blobbies to give it a much more dense and water like shading quality. In particular with blobbies, in order to get the surface to refract through the ocean, I precomped my ocean and then projected that as a texture through the camera onto a lower detailed version of my deformed ocean geometry so that my render was optimised for raytracing the refraction. I was also asked to add a bit of runoff of water off of the characters from their feet, which was easy enough to do and then I also used the body geometry to refract to get a get similar render quality to my churn, which worked out great!
Midway through my contract, I was asked to take on the responsibilities of a Lead, so that I could help during the big push by directing and mentoring both creatively and technically a crew of 35 FX artists to deliver the remainder of the FX work for the show. I was responsible for up to 10 artists at one time and also attended dailies and meetings with R&D, Lighting, and Compositing to handle the requirements of the tools, pipeline, scheduling and bidding of the remainder of the work.
As a lead I helped deliver cloth banners, clouds, embers, dust, debris, lowlying mist, waterfalls, rock splashes, fire, smoke, snow and various other effects across the show.
After finishing work on Surrogates, I took extended holiday and upon my return I made arrangements to move to Sydney, Australia to work for Animal Logic on their upcoming feature animated project Legend Of The Guardians. I had a little over a month to wrap up my life, but during that time I was contacted by a friend at Image Engine who was working hard at the tail end of finishing District 9 asking if I would be interested in helping out on some last minute FX work for the show.
I made my way to the studio that afternoon for an impromptu interview as well as to take a peak at the shots that I would be responsible for. The task was blood and having done similar FX before, I felt confident that I could deliver a result in the time left, which was just under 3 weeks.
The studio had a single licence of Realflow, but I wasn't even considering using it (well for the simulation at least). I knew that even in amount of time I had, I still needed to be able to iterate quickly to address notes. This kept my simulation in Maya, where I was able to build a particle rig in a half a day that could prove that I could get the simulation quality that the VFX Supervisor was after, but the challenge was getting the render quality.
Rendering as points using a shader that could fake specular highlights to give it a watery feel showed promise, but wouldn't hold up for all of the shots and the VFX Supervisor was really after a meshed surface look to get highlights connected and controllable in lighting.
Having an R&D background, specifically in building tools for fluids and liquids, I knew what was required to achieve the render quality, but it meant writing tools which at this stage of the production wasn't ideal. Fortunately, I had access to a Senior and a Junior R&D developer who could work quickly to build the necessary bits I needed while I could still iterate shot work.
We opted to go down 3 paths: rendering points as blobbies (which needed a little support to get rendering correctly), meshing in realflow (which meant being able to write to their particle format and read their mesh format for rendering), and meshing using a proprietary technique that had already been developed but hadn't been tested to this scale and needed work to get rendering with motion blur. The last two approaches meant we also needed to a new rendering path for meshes.
Rendering as blobbies didn't create smooth enough surfaces. We were able to get our particles caches into Realflow, but were unable to mesh them this way. This left us to meshing them ourselves, which thankfully worked. The downside was that this was a manual, and memory intensive process! R&D were able to step in again a write a tool that would allow me to perform the meshing on the farm, which had the add advantage of being able to perform the meshing as many machines as i would need or could access.
Simulation wise, I was having alot of fun adding blood to ripped limbs. There were really 3 separate shots I need to deliver, a quick shot of a guard getting his arm ripped off as he's thrown back, and two more of Kubis, the bad cop boss, first getting his head ripped off and then finally the remainder of his limbs. There were contiuation shots that could use the existing caches just for rendering. Since the simulation rig was pretty light and controllable, I was able to fine tune the blood emission so that it could be timed to the animation of the limbs being torn and thrown around and then taper off slowly.
In the end we used two render passes (watery points and proprietary meshed surfaces rendered separately) to give the final look.
By my last day, I had given the compositor a rendered version of every shot, my friend and lead a run down of the workflow should he need to address new notes and left documentation of the pipeline that we built as well as suggestions for the future should it live on. The first of the shots had already been properly finalled, and later on I found out that my renders were enough to get the rest of the shots finalled, which was a relief.
All in all, I have to say that for the quick turnaround required, I'm was quite happy with the result and the opportunity to be invloved in such an epic film.
After finishing work on Watchmen, and taking a bit of a holiday to recharge, I came back to Vancouver to start on Surrogates. Also based on a graphic novel, although a much more loose interpretation in the adaptation to film, I was tasked with creating liquids that would spurt out of Bruce Willis' severed Surrogate arm as he chased a bad guy through the hostile Demilitarized Zone where his A-star helicopter had crash landed.
Building upon the same toolset I wrote for water in Watchmen, I updated it to make it a bit more user friendly and scalable to working on many shots at once. While the comparative scale was much smaller compared to Watchmen, Surrogates required that the tools scale to being able use continuously across over 50 shots where fluid emission was dependent upon a digital double that would require roto animation to sit inside the plate correctly.
After an initial cleanup pass of the toolset, which was affectionately named Splash Magic, I began working on building a simulation rig in Maya.
The severed arm had 3 tubes to emit from which were equidistantly positioned around a metallic bone. I added 4 layers of control over the emission, 2 which would give a distinct periodic pulse to the emission, another which be able to hit the shot points of his actions (jumping, landing, turning quickly) and lastly another which is just an override for when Bruce is off screen or not visible, so that we can speed up / cheat the simulation where we can. There were slight random time offsets to each tube to give a bit more variation, but they were using the same animation for emission.
The simulation split into two parts: dynamic and passive fluid. Dynamic fluid dealt with fluid that was just emitted from the severed arm and passive fluid is when that fluid either collided with the ground or sides of shipping containers. Being able to split the fluids meant I could simulate them differently (passive fluid was much quicker) as well as turn off the passive fluid if its not required in a shot. Also, since the passive fluid was simulated separately, it could be used in shots for continuity easily as well as be lit, rendered and composited differently when needed (needed to give fluid that soaked into dirt versus splat onto pavement a different look).
With the simulation in good stance, I began optimising the shot setup side of things. I started by checking in the simulation rig without emission into the asset management system. I had built the rig with easy controls to add/delete emitters as well as collisions objects. I then wrote scripts that would on a per shot basis gather the camera, digital double, simulation rig, and then create the emitters that would attach the emitters to the digital double. This allowed a new shot to be setup for simulation in minutes, but I also wanted to do the same for rendering.
Similary, I wrote a script which built a render scene on a per shot basis that would gather the camera, digital double, latest fluid caches as well as the latest lookdev for them so that we could do setup for rendering a new shot in a manner of minutes allowing more time for shot specific components.
Coupled with a few more scripts to wedge simulation parameters and automate slap composites as dailies for review, we were able to hit the ground running on shots well in advance of other departments. This was a good position to be in, because we were able to flag bad tracking and roto animation as well as highlight lighting and compositing concerns early. Specifically with roto animation, we were able to identify early enough which shots would need additional preroll animation so that at the start the shots the fluids were moving correctly.
With the workflow documented, when the production push came, we were ready for it. I was able to get a few more hands into my team to divide up the shots each artist was able to iterate 2-4 shots a day, while still responsible for their other tasks. There were a few key shots I was responsible for but mainly just the one hero shot of the reveal of the severed arm spurting fluid close up and at camera. For this shot, I ran multiple layers of simulation with different densities and different collision dynamics with stump geometry to get varous amounts of fluids running off and along the stump.
Because we were so far ahead by the end, I was able to sneak fluids into shots that originally didn't require them. This included a distant shot of Bruce jumping between two shipping containers as well as the helicopter crash shots which actually show his arm being severed by the helicopter's propeller. I was also able to take holiday before the end of production as well as help out delivering heat haze elements in shots involving CG A-star helicopter and chinooks.
Whilst working away on The Chronicles Of Narnia: Prince Caspian, an opportunity came up to work on Watchmen in a brand new facility being set up in Vancouver, Canada. After moving my life from Toronto to London just a short 8 months prior I thought it would be a hard decision, but once I read the graphic novel the film was based on and the challenges I would face, there was no way I wasn't going to do it.
So I packed up my bags and moved back to Canada. Work on Watchmen had already started from London being involved in various meetings on how we would tackle various shots, the technology that would be required and setting up key infastructure to be able to run the studio very much like way London was running.
I was able to stop in Toronto to visit my friends and family before continuing onwards to Vancouver. My arrival was surreal, the studio had only had the machines put in the week before, it was a nice open space, but definitely new beginnings. My first days, were spent meeting the crew and being involved in rounds, but it wasn't long before I had crucial problems to solve.
Being one of a few of the crew who had worked in London, I was called upon from time to time to show how the pipeline worked and specifically how the tools for FX worked. One thing I really enjoyed about being in a new facility was that I was able to see how each discipline was working and it was much easier to see how the different departments were working together. I notice that Compositing was in full preperation mode processing onset reference and grading plates for all of the shots. I stepped in to help automate a lot of the workflow so that Shake scripts could be built and assembled on the fly and run across multiple shots at once.
I realised that what was really needed was a way to arbitrary submit work to farm, so I wrote a command line tool for batching work to the farm. I came to rely on this tool time and time again for the rest of the show.
I next took on the mantle of trying to render maya fluids in renderman. This task was much trickier than I anticipated and without having much time to deliver a proper tool for the show, we ended up using mentalray instead which worked out much better. However, my experience delving into maya fluids proved usefull later on in the show. For rendering a nuclear explosion we needed to use texturing to get the detail at render time to sell the shot. The problem was that the texture coordinates were stretched by the end of the simulation which was what needed to be rendered so texturing wasn't possible. I stepped in to write a tool to read the maya fluid cache, reset the texture coordinates to be sharp on a particular frame, and then write the cache back out to be replaced then rendered.
I spent a considerable amount of my time on this show developing tools for delivering CA110, otherwise known as the bubblegum or mother of all water shots! We were expected to deliver the shot with Realflow and had already acquired a savy FX TD and several licences including access to (at the time beta version of) the RFRenderKit which were their custom Renderman procedurals for meshing particles at rendertime. I initially started by writing tools to integrate the procedurals as-is into the rendering pipe. This also invloved writing the necessary reader and writer for the Realflow particle formats so that I could preview them in OpenGL as well as create accurate bounding boxes for the procedural to run inside of.
We worked closely with Next Limit giving them feedback and making suggestions for future version whilst we iterated the shot as best we could in the interim. When it became evident that this shot was going to be in the trailer, we had to increase our efforts in FX, and so we delved into using a custom maya field for simulating fluids that had been developed. This meant that we needed to be able to use maya particles and mesh them, so I wrote tools for converting caches generated in maya into realflow formats to pass along to the procedural for meshing. This was going well and I was being passed caches from several TDs to convert and get a good meshing from, which I would pass on to the lighter for the shot.
Once the lighter picked up the shot it became evident that meshing for every render wasn't going to cut it, so I developed a way to cache the meshing on the farm without the need to render at the same time as well as being able to use these caches to then render so that lighting the shot didn't require waiting for meshing. The look development at the time was very much dependent on doing everything through meshing for better or for worse, we even meshed elements for foam and developed a mechanism for flowing textures along our surfaces, which produced really interesting results. We were also relying on expensive rendering techniques like raytracing and subsurface scattering to get the look. This was pushing our memory requirements through the roof literally, and it became the highest priority to get the shot to render.
We ended up delivering a result for the trailer which on particular parts of the shot looked great but as a whole wasn't up to satifaction, so post-trailer we devised a strategy to better improve our workflow. This included ditching Realflow for simulation and improving the rendering workflow altogether. I had already started by improving the meshing steps by changing the caching system to convert to our prorietary format so that I could then preview the meshes in OpenGL. I had already made it possible to mesh outside of the renderer and i consolidated that into the tool so that the when a nice meshing was discovered it could be easy to batch that work onto the farm.
Also once the meshes were in our proprietary format I could begin to modify how they ended up getting rendered. I was able to imploy several techniques which diced up the geometry into separate pieces to render in separate procedurals as well as methods for being able to separate particles so that different meshing could be obtained for differents parts of a simulation we could identify. While in theory sounded great, as this meant we could imploy level of detail in our meshing, in practice it was difficult to obtain the right rules for isolating distinct meshable areas while still maintaining continuity.
With meshing more or less covered we moved on to tackling something we were not able to achieve fror the trailer, which was a foam, spray, and mist! We knew we wanted to be able emit particles from our meshed water surface, but were weren't sure how to get a believable and connected simulation to the scale and detail we required. After inlisting several FX TDs for support, we were able to to devise a strategey where by we dice up our meshed surface into equally sized chunks based on the bounding box of the mesh, which we could then have our particle simulation localised temporally to get much higher quality simulation by being able to push our emission to maximum number of particles per chunk. This also meant we could distribute the simulation of each chunk to separate machines on the farm, to get a much quicker iteration time. It also meant we could approve chunks of simulation at a time and then iterate the remaining components individually.
With the hero shot in hand technically and artistically, we had very little time to tackle the remaining water shot, but since they were far less technically draining I was able to deploy the same techniques for CA110 to deliver it.
This show was the most challenging show I have worked on, and considering the small but talented team and the volume and scale of the work we ended up having to deliver in a brand new facility, while exhausting and satisfying after the fact, was still a lot of fun to be apart of!!
Having come off of Silent Hill and been delving into pipeline and studio concerns in R&D since, which was interesting although not that creative, I was happy once we were awarded VFX work on The Tudors which is an HBO television series based on the life of Henry the 8th.
Having learned a lot from the good and bad of the final production push on Silent Hill, I was determined to be proactive and engaged early on The Tudors. My involvement on the show started at the very beginning as we were engaged in what the FX concerns on the show were, and were looking early on to develop techniques and workflows to make the production run as smooth as possible. My first task, was to build a camera rig for the studio, but specifically for the show. We primarily used Houdini, so I had leveraged and consolidated the previous rigs from previous shows as well as added new features that the animation lead had requested.
The next task was generally improving the overall rendering efficiency across the show. The show had a big build of environments as well as oceans wit ships and one-off particle effects here and then. We knew that our assets were static and would be placed across multiple shots across the series, so our first goal of rendering efficiency was to leverage RIB archiving, which would reduce significantly our RIB generation as well as rendering ( through using Delayed Read Archives ) only what was visible from the camera. As the build was being done in Maya and rendering was done through Houdini, the workflow was to convert the geometry and shaders from Maya to Houdini. Specifically each model was an asset, so I wrote a script which procedurally built Digital Assets, which would build controls for layout and lighting as well as leverage the efficient rendering setup automatically.
We wanted to improve the lighting workflow in a number of ways. To be able to leverage quickly complex lighting techniques like Subsurface Scattering and Ambient Occlusion, which in PRman had a numerous steps in order achieve the result, as well as to be able quickly setup a scene to render different passes. To do this we wrote Render Operator (ROP) Digital Assets that were built around PRman's RiFilters to make it easy to use it for a Lighter
My next task was revisiting a project that got me literally into doing VFX, which was Oceans. I had written plugins for Houdini, Maya and PRman that leveraged Jerry Tessendorf's technique of using FFTs to generate oceans via heightfield displacement. I revamped the set of tools to leverage the ability to apply multiple layers either as deformations or displacement as well come up with techniques to use this displacement to generate prerendered caustic patterns that could be projected onto ships.
Lastly, there were a couple of snow shots, that were required for this show that involved painful hand tracking and particle work at the final stages of production on the show. There were a few late night for those tricky shots, but otherwise the show had a ran pretty smooth otherwise, which was exactly what we had set out to do.
Silent Hill was the project that gave me my first real opportunity to work in visual effects. I had been working in Research and Development primarily developing APRIL which was facial aging software which while it had its interesting challenges had become less interesting after working on it for enough time.
I had been helping out on the pitch by modifying our proprietary cloth simulation to support self-intersections and when we were finally awarded a large portion of the show, I was able to fully transition onto it.
Initially my tasks were unrelated, I was helping out on another show Codebreakers, which involved writing sprite crowd rendering tools within Houdini to fill a stadium full of blue screen elements we shot on set.
I had also written some tools for rendering maya fluids in renderman as well as writing tools to simulate oceans.
While super excited to be doing effects I felt I wasn't really involved in Silent Hill, so I was a bit proactive and started walking around seeing what artists on the show were working on. A bulk of the work required for the show was adding falling ash and fog to most of the shots and there was also some one-off effects. I was helping out one of the artist doing the look development for the falling ash by adding workflows for particular motion as well as dealing with technical aspects of collisions and instancing. It got to the point where I wrapped these workflows into Digital Assets so that the other FX artists could easily use these tools to start or take a shot to final. I later joined the team by picking up some shots that were tricky or hadn't been started yet. To help myself out, I began writing additional tools for grouping sections of ash to be placed close to camera as well as culled around the environment.
While we were waiting for film production to wrap up so we could start working on Silent Hill, Codebreakers, which was an ESPN movie came through to fill the gap. The challenge on this show was to create and fill an old football stadium.
Due to the nature of the shots, we knew we could get away with using a sprite based solution, but we wanted to be able build a setup which was fast and easy enough to control the layout and animation of the crowd in the stadium.
I was fortunate enough to be able to go onset for shooting extras on blue screen as our crowd characters. When we got the plates back and processed them. I used the processed plates to create a berkley (non-relational) database that allowed extremely fast access to the data, which then hooked into a few custom Houdini operators so that attributes could be painted or procedurally places using other operators. This data was passed to the shader so that the appropriate sprite could be looked up at render time either in Mantra or PRMan.
Although this wasn't required for the show, we realised we could use the bounding box of the character to determine when our crowd character was standing up versus sitting down. For fun we ran a some tests of painting patterns of when the characters would stand up as well as getting them to do "the wave" procedurally!
this is the page where i post code for tools that i've been meaning to do!
this will come in 2 types: caching and simulation
caching will include realflowio, pdbio, ptcio, Houdiniio, mayaio ( in/out of Houdini and maya )
simulation will include fieldvisualiser, bubblefield, stringfield, surfacetensionfield, deepshadowcollisionfield
