The Lost Bus is a 2025 survival-drama directed by Paul Greengrass for Blumhouse Productions in association with Comet Pictures and Apple Original Films. The film is based on the non-fiction book Paradise: One Town’s Struggle to Survive an American Wildfire by journalist Lizzie Johnson. Set against the 2018 Camp Fire in Paradise, California, it follows a school-bus driver and a teacher who fight to guide 22 children to safety through an encroaching inferno. Combining Greengrass’s documentary-style direction with large-scale visual effects and environmental reconstruction by RISE FX, the film depicts one of the deadliest wildfires in recent history with stark realism.

Supervising the inferno: Oliver Schulz (IMDB | Linkedin) is a senior Visual Effects Supervisor at RISE FX, the Berlin-based VFX studio. Over more than a decade at RISE he has guided VFX supervision on major international productions including Fantastic Beasts: The Secrets of Dumbledore, Blue Beetle and Megalopolis, among many others.

His background spans concept art, digital matte painting and 3D environments; skills that helped him to take the creative lead on blockbuster-scale environment and FX heavy shows. In this interview he reveals how he and his team at RISE tackled the challenge of recreating a burning landscape for The Lost Bus, combining procedural geography, wind-driven vegetation, deep-rendered volumetrics, and machine-learning techniques for depth integration, to bring the inferno to life on screen.

DP: How did you get onto the Lost Bus? 

Oliver Schulz: I came on board after wrapping up on Megalopolis and jumped onto the very first meeting with Charlie Noble and Gavin Round, Production VFX Supervisor and Producer. The project was already awarded at that time so we directly started talking about the Sequences and the scope of the Rise portion of work.

Luckily or better sad tragically this was a real event so in regards of look, there were many references and documentation of this day. So our first meeting was looking through a lot of real world footage from all available sources. Charlie had been prepping reference reels from the very beginning, so we could hone in on a lot of specific ones for each portion of the work because he had references for all of them!

DP: Roughly how big was the RISE team on The Lost Bus, and how long did you spend from first build to final comp?

Oliver Schulz: We started with a very small core team in May 24 and delivered the last shots at the beginning of 25.  I think around 50-60 people worked on the show in total during the production with up- and downramping based on specific project needs like temp deliveries for example.

DP: The antagonist of the movie is the geography of a very particular area, and the fact that it is on fire – how did you make sure that it was recognizably that specific part of the world? 

Oliver Schulz: We started with real world data derived from elevation models. That gave us a pretty good grounding in reality. We got lidar scans for very specific locations like the Pulga Bridges for example which was invaluable as this is usually something one doesn’t get from any publicly available sources. We spent quite a bit of time to get us a very good foundation of all key locations, which meant that everything had a geometrical base until the very last mountain you see on the horizon.

Our Lidar Supervisor David Salamon was instrumental in setting up this base. He used some maps imagery to give a rough base color to all those individual geometries that served as a rough guide later on in layout and surfacing for distributions of materials or assets. One has to keep in mind that most data was post 2018 so for instance vegetation had to be recreated from mostly photographic references shot before the fire. We tried to stay as true as possible to real world geography, but later on of course things had to be changed for storytelling reasons. 

DP: When merging New Mexico plates into your California canyon builds, how did you maintain scale and geological continuity?

Oliver Schulz: As production did not have access or in case of some very sketchy roads didn’t shoot at the original location for safety reasons, they did some scouting through the US and chose some New Mexico locations as stand ins for some of our sequences. The most prominent was the Pulga road for sure. In the film, the first responding firefighters trying to get to the origin of the camp fire first get sight when they are on top of the Pulga Highway bridge crossing the Feather River Canyon.

Without any better option they decide their best shot is to try and get to the fire following a very narrow road on the slope of the canyon. All shots on Pulga Bridge were shot on a Studio Backlot featuring full CG Environments including the FG bridge. This narrow path however was all shot on the New Mexico location with two big fire engines driving a slightly wider road. 

In production that meant that we replaced most of the visible Environment due to a couple of reasons. First of course it needed to have the right roadwidth and the correct canyon in the background. Second we needed to have very windy vegetation everywhere. Third in case all of that worked in camera which was pretty rare we still needed to put FX Elements into every shot consisting of dust, debris, smoke and later also embers. With those guidelines in place probably 90% of the shots became full CG exteriors only keeping small bits of photography for fire engines and some road pieces.

Once all those went into layout we made sure to keep a senseful progression to those shots meaning having the firefighters travel along the road during those shots in cutorder. The topography of the shooting location though was pretty different from the storypoint progression on the pulga road, so was the framing in camera when pointing at the fire from the fire engine interiors.

That of course meant as good and real our base was, it needed to be heavily augmented to make sense with storytelling and framing choices. Most shots feature the correct BG canyon but the midground is totally made up to allow for good view to the fire origin. All of this had to be understandable even with very frenetically moving handheld cameras.

DP: Let’s talk vegetation: How much botanical creative freedom did you have? 

Oliver Schulz: Vegetation was a big part of the environment and one of the reasons for the rapid spread of the fire. All FVX vendors had to tackle it in one way or the other which meant all were contributing to the research for which plant goes where. The foundation was once again the research and material collection from Charlie and his team.

We focused on the most common species found in this region of CA and made sure the level of dryness and the distribution made sense. So in this sense there was not too much freedom here as everyone tried to make this as real as possible from this point of view. For the build we actually just used the most common ground which is Speedtree with some augmentations done in Houdini. Part of the assets were also shares from other vendors which just needed ingestion and rigging in FX.

DP: You mentioned building a hierarchical “ecosystem” in Houdini. How modular was this system, and how much hand-authoring did artists still need to do per shot?

Oliver Schulz: This was something we actually invested a bit of time in at the very beginning and was overseen by CG Supervisor David Schulz and Layout Lead Mareike Loges / Senior Layout Artist Björn Markgraf. The core idea is nothing new and hierarchical just means that you start from the biggest Elements in your kit and than go smaller and smaller based on the previous distribution of Elements. First step is to either scatter or handplace big trees for example, following this you end up with a certain distribution. 

Based on this the system places smaller entities like younger trees or seedlings and smaller shrubs and bushes around or between the big trees. This distribution is based on simple rules like distance or terrain steepness. In case of the Pulga road we divided it up in two categories: mountains and roads. Both had similar procedures. We would always start with the rough blocking geometries matching either scan data, elevation data or sometimes just made up. From there we would generate the base coverage of rock cliffs which would hold out trees mostly in those areas. Following this we created the trees and bigger vegetation which would determine the ground coverage of rocks vs more pepply ground.

Roads were pretty similar but less complex as they mostly feature small stones. Again here we used some manually created maps to drive the distribution of small vs bigger pebbles that mostly accumulate on the side for example.

The toolset itself worked pretty well and as it was applicable as a template we could have a fully laid out shot in a day. Shot specific adjustments were applied on almost every shot though, mostly for continuity, visibility or art direction purpose. 

DP: Vegetation, environment, and FX were all dependent on one another. How did you keep versioning sane between departments?

Oliver Schulz:  That was a big topic indeed and it only is possible with two things: a rigorous approval system and a good pipeline that helps you track those approved layouts. We rely on our usd pipeline to do exactly that for us, it makes it somewhat easy (Im sure layout and production will hit me for this) to track department versioning. For each layout update we`d always get automatic QC renders that run through our inhouse “slapstick” system which is our inhouse auto comp engine.

When Layout would do a specific change it would publish this either on a shot or on an Sequence/Environment level. This will trigger a QC render from the shotcam of the affected shots. Once the rendering is done it will have a postjob that combines it with the prepped plate in nuke and runs another renderjob that will give you the layout reviewable which is than checked and can be approved and pushed into the pipeline from RV. This Layout than becomes available to the FX department which would run all needed simulations and hand off another QC reviewable for approval. Without those systems in place it would have been a nightmare to stay on top of all these versions!

DP: You said the layout department drove wind direction and strength instead of FX. How did that change your creative workflow?

Oliver Schulz: Yes that was indeed true and one of our early conversations we had internally to determine the approach all Environment builds would share. It was a practical decision based on two factors: We would simulate all vegetation on the asset level in different windspeeds for efficiency reasons and we wanted to keep iteration loops to a minimum.

This meant that I wanted to look at layout versions with moving vegetation as the strong directional wind would make it necessary to consider this already while layouting trees. As the direction is clearly visible you cant rely on spinning a tree 360 deg free in Y to create variations as the direction is “baked” in, so you need to see it moving in order to determine if an environment looks good!

The second reason is that FX needed to take care of vegetation simulation only once and when approved never needed to come back. This system worked really well and was accessible to the layout artists down to the single blade of grass, meaning one could really art direct where and how much specific things should move.

DP: You divided smoke into “hero” and “residual” categories. How did you manage density and readability without losing visual clarity?

Oliver Schulz: These two categories were simply based on the fact that we needed to deal with smoke in almost every shot. The ever present residual smoke needed to inherit a direction, needed to be art directable and also needed to render as fast as possible. Its pretty much the equivalent of atmospheric perspective in a wildfire scenario. Our Fx Supervisor Akin Göcmenli came up with a system of instanced presimulated caches that sometimes could consist of thousands of individual ones.

We started by doing simulations of smoke with a constant wind direction and speed that had a hidden source of emission and diffused pretty soon. That gave us a very soft falloff to the edges of the simulation grid which made these simulations perfect to overlap and look as one big single instance of smoke. On top due to those aspects it was quite easy to remove single containers and punch holes into the wall of smoke for visibility. We also invested a bit of time to develop shaders and render efficiencies to cut down on notoriously long volumetric rendertimes for this element.

Hero smoke was the category which either had a visible emission source in frame or simply had a hero storytelling element. These were usually shot or sequence simulations as they were mostly much denser and most of the time also much closer to camera. We also spend a good amount of time matching shading and simulation to real world references.  The secret to readability also lies in relentless QCing of outputs to make sure once you kickoff the expensive lighting renders, you are as certain as possible all elements are going to work. 

DP: The ember work looks incredibly detailed. How did you simulate believable motion in strong winds without visible repetition or looping patterns?

Oliver Schulz: Embers were a big part of the equations so by now you might guess…. Yes we spend a bit of time in asset prep to build some solid foundations. The first thing is of course the driving factor for all fx aspect: the wind.

FX developed hero wind forces that we used to simulate all elements with. A good amount of chaos and variance is key to not run into issues with readable patterns in any simulation. Another factor is collision. Embers will behave a certain way when they collide and thats what we tried to replicate. Also the ground plays a big role especially with the heavier emberclumps that slide over it.

Reality is unbeaten when it comes to little quirks and anomalies especially for something as complex as this. As no one is able to have a ground as detailed as the real world we also sometimes had a collision geometry that had slightly more displacement in order to have more detailed collisions happening. 

DP: Lighting and volumetrics are natural enemies. How did you maintain physically plausible lighting through that much smoke and fire?

Oliver Schulz: That was one of the biggest questions going into this project, considering that what was shot on set sometimes had very little to do with what ended up on screen, especially in terms of atmospherics. The best base for something to look real is to match the real thing. We did so in our asset phase and made sure our shaders and lightrigs were physically plausible, especially the ones only used to develop assets. 

We would match greyballs and reference macbeth charts in order to make sure scene lighting was correct in terms of lightbalancing. Then from there we developed shaders for all aspects.One of the most common issues I see is that volume and surface renders aren’t lookdeved in conjunction. What you end up having to do is to grade surface and volume render differently. This leads to very unrealistic renders very fast because there is no ground truth you can come back to.

We tried to make sure all our shaders worked with each other to have exactly this common base. Also when dealing with dozens of light sources and those issues on top that’s definitely a position you don’t want to be in when time is running…. All volumetrics do have very different properties to them where one of the biggest is how they scatter light. Back to front scattering can take a volume from being ultrabright to consuming all lighting energy and being pitchblack. So once you matched the real thing, use those tools wisely to deviate from there and support the story. 

We tried to always start with a balancing pass usually done still in lighting. This goes to comp as the foundation to do all the finetuning with. Still there was a lot of tuning left for comp and also we needed to break reality more than once to make sure that what you wanted to read in a frame remained readable when tons of smoke and fire went in front. Sometimes we needed to go as far as use the deep data to pull things in and out of the smoke to make them visible. Still the most valuable tool you have is the artist’s eye to determine the sweet spot of good vs real.

DP: You mentioned deep rendering bottlenecks, like OIIO running out of patience with too many AoVs. What exactly went wrong first?

Oliver Schulz: Haha yes that was one of the issues that came when switching to full deep with our renders. That means you have each component of each lightgroup rendered with deep data to put it back together in comp. That resulted in a lot of channels that apparently were too much for OIIO to handle. Thank god that was fixed otherwise I wouldn’t write this story now ;)

DP: Rendering holdouts took up to an hour per frame. Did you develop any automation or optimisation to make deep rendering less painful?

Oliver Schulz: Indeed rendering times for deep holdouts were quite painful and nothing to speed up really. With so many volumetric elements you need to deep hold out everything with everything to make sure its accurate. If you multiply this with the number of separate elements rendered and with the amount of light Aovs times the amount of components you end up with a staggering number of renders.

Plus in the end you need to denoise all frames so the best solution was try to plan out delivery dates as good as possible to have time for all those thousands prerenders to run on the farm. Still our compositing Supervisor Oliver Hohn and Lead Nicolas Burgers had some longer evenings ensuring all renders were there the next morning to be picked up by the compositing Artists.

DP: You used machine-learning depth generators to create deep data from plates. What tools powered that, and how reliable were the results?

Oliver Schulz: We started testing tools quite early in anticipation of very challenging compositing work. DepthAnything v2 was what we ended up using as a default prerender pass. The results were a mixed bag considering the wide range of plates we worked with, although it proved to be valuable to have. Comp remapped the relative value output of the depth passes to absolute values from deep data with help of lidarscans or renders and was able to create some good integration especially with more wispy type of smoke.

For denser smoke and more accurate holdouts especially for actors we still needed to rely on a lot of manual roto for good integration. The AI passes proved to be pretty successful though for fast temp work as you get something going in no time. Issues were mostly the missing good temporal stability and also the lack of precision. 

 DP: Before deploying new tech like ML depth generators or procedural ecosystems, how do you test them safely inside production?

Oliver Schulz: We implemented those during production directly on our project infrastructure, so developed, tested and used simultaneously. 

DP: Were there any spectacular ML depth map failures, like smoke reading as solid or background cliffs collapsing?

Oliver Schulz: Depth popping or lost shapes were the most common ones. But as none of these passes were used without correction in comp I’m sure I haven’t seen all of them!

DP: With so many volumetric layers, how did compositors manage complexity without drowning in passes?

Oliver Schulz: We have standard workflows for loading CG renders into nuke which do provide a basic level of organization. However the more elements you have the bigger the compscripts and we had some good ones for sure!

DP: Fire colouration is tricky. Did you use any spectral rendering or rely purely on LUTs to match on-set lighting and heat distortion?

Oliver Schulz: That is very true.. Luckily production tried to shoot everything with a practical fire which provided a good level of references in camera. If you than try to render as physically plausible as possible and have something in frame that you can match exposure to you are already halfway there. We didn’t use any spectral rendering here and rendered everything through Houdinis Karma in RGB.

DP: You switched to full motion-blur sampling for embers instead of faked streaks. How much did that impact render time, and was it worth it?

Oliver Schulz: Oh that was worth every minute of rendertime.. Real Motionblur for an element which is mainly visible in motionblur is a good investment. Plus the rendertimes weren’t actually that bad and took only a couple of minutes as you are not dealing with an expensive shading as well. The biggest benefit is getting nice curved and very interesting blurs especially with collisions.  The trick actually is to only invest time where its needed and render other elements with less costly settings. Deep compositing allows for it as you are not bound to any holdouts and you can combine differently rendered motion blur without any problems.

DP: How crucial was RiseFlow for distributing simulations and maintaining consistency across all sequences?

Oliver Schulz: We started implementing RiseFlow at the very beginning once we had our initial workflow for distributing elements figured out. The development was done by our Head of Pipeline Paul Schweizer and the implementation on the show was spearheaded by Jonas Sorgenfrei.

It actually is a very versatile framework that we use for a variety of tasks here at Rise. Its a modular node based System that can take arbitrary inputs and execute them in a chained workflow. FX built templates for various scenarios that got exposed variables like wind direction, speed, inputs for collision geometry etc. These could than be varied per shot and sent to the farm for execution. Once all those Sims were done, QC renders were submitted to the Farm and when completed, auto comped in Slapstick.

That meant that one artist could do changes on a big number of shots by adjusting the template and than resimming and rendering them over night. All render elements were deepcomped with our deep plate workflow and reviewed the next morning. This allowed for rapid adjustments and turnarounds which was a very crucial aspect of this fast paced production. 

DP: How did RiseFlow and Slapstick communicate between departments for reviews and dailies?

Oliver Schulz: RiseFlow and Slapstick are two different things really. The point where they communicate is that Riseflow might trigger a farmjob where Slapstick is hooked in as a post process that gets triggered after completion of the render. Slapstick again is a modular node based system implemented in Nuke that allows for a generalized template to be created. These inputs could take for instance all general elements that comp might use to layer a shot like mainplates, rotos, colorcorrections, lensdistortions etc and comp them together. We use Slapstick in all departments to create automatic reviewables for assetbuild like turntables with reference images, lighting slaps,fx slaps and so on.

DP: You’ve called The Lost Bus the toughest matchmove job you’ve ever seen. How did you solve the handheld, wet, low-light camera challenge?

Oliver Schulz: That was a tough one indeed. To solve this it really just comes down to the excellence of all individual artists that created those matchmoves. So there is no magic recipe to get through so many challenging matchmoves…

DP: Greengrass loves long, continuous takes. How did you manage to iterate and render efficiently on such heavy, unbroken shots?

Oliver Schulz: I guess it is really to choose your battles wisely… Invest into a good foundation early on and make sure to be as precise as possible in prep phase. Once the show is running and you are in full delivery mode there is no time to go back and redevelop anything.

Render optimization as much as possible and then relying on everything that was set up in the beginning is key to not have to think about accuracy anymore when you are trying to finish the shots. We did this and it really paid off, though having a couple of long shots with lots of elements to render we never ran into the issue of having to fear a render didn’t get finished in time.

There were some challenging shots for all departments involved but again the prep phase paid off and we managed to deliver everything in time. It’s really a Situation in which the Production team led by Michelle Cullen and Production Manager Androniki Nikolaou outdid themselves by planning and scheduling every milestone in production to make sure we had what we needed to finish shots in time. Of course that also means adjusting and revising this schedule each and every day based on client comments and changes.. It’s a tough job to make sure the whole production runs like a well oiled machine!

DP: Deep compositing only works if all layers align perfectly in space. Did you use diagnostic tools or pure visual QC to verify deep accuracy?

Oliver Schulz: The good thing about deep is that it’s pretty accurate as long as the sampling increments in depth are small enough for certain elements. It’s a game of keeping error thresholds low enough so you don’t pick them up actually. The balancing is precision versus filesize. Surface renders aren’t an issue really as you are dealing with front and backsides of hard surface objects really.

The fun starts with volumetric elements and this is where you need to tweak the settings a bit to make sure you don’t end up having 5GB per frame in volumetric renders. Still frames could grow to well over 1GB on bigger shots with all elements included, so we needed to do some rough calculations beforehand to make sure we weren’t running out of allocated serverspace.

DP: How did you maintain consistency for fire behaviour across sequences? Was there a single reference look, or did it evolve shot by shot?

Oliver Schulz: One of the big topics obviously here as the quality of the fire not only needed to remain consistent but also serve the story in how it behaves. When you look at fires in reality they all have very different qualities to them depending on a ton of external factors like what is burning, where it burns, what is the actual heat it produces and what is the influence of the wind and so on. So yes it’s crucial to pick a reference and not try to incorporate them all. The initial tactic we used was to create asset based fires with all components.

The two types that production defined as assets were “spotfires” and “forestfires”. Pretty generalized in description though mostly divided up by scale. So we took those two types into asset development and created a little scene with them. Forestfire in the background and spotfires in the foreground. This scene actually was the same one we used to lookdev all assets in. So we had a common ground for all assets really and the fx ones were not different.

We picked a general reference we felt was working well for each category and supplemented that with references that production had shot on set. The shot element though were mostly run by gas so wouldnt really emit any smoke but were a general ref in terms of breakup and edge qualities. Also those would come in native resolution where most of the actual refs are cellphone captures of much poorer quality.

So with all those references in place we started matching the fires again in different windspeeds. We tried to also implement all little details especially on the bigger forest fire like flambursts on dry wood, falling burning pieces of wood etc. Once fire was in place we hooked it up with all secondary elements like smoke and embers. We had already pretty robust setups developed for each of them individually so we could already build on a solid foundation using those as a base.

Once this little scene was successfully approved by production to go into shots we splitted out the individual components as assets again. These had all elements attached like smoke emission, ember emission, lots of different masks for heat distortion and were ready to be dropped into shots.

Using this technique we had a very solid foundation of very similar looking and behaving fires. Of course for hero shots we would need to resim those, but with setups in place and our template system it was mostly straightforward. Of course there are shots that need to tell a certain story like a fire coming right at you towards camera. Solving a problem like reading a perspective of a selfilluminating matter coming right towards camera is a different beast though you can’t prep for! This just takes a lot of creativity and trial and error to get right…

DP: What’s the single biggest creative takeaway from The Lost Bus you’d carry into your next show?

Oliver Schulz:  Don’t try to put out all the fires at once….

DP: Which shot makes you proudest or gives you flashbacks?

Oliver Schulz: Oh there are so many good ones really, honestly when I was watching all shots in a row I was so happy about the overall level of quality the team achieved in every aspect. So hard to pick singles but the Embercam full CG shots looked amazing on the big screen and were pretty spectacular… but getting them to the state we delivered them in was quite a journey…

DP: Finally, if you had to redo The Lost Bus from scratch, what would you rebuild first? Vegetation tools, compositing templates, or your caffeine reserves?

Oliver Schulz: Myself :)

The post Rendering the Inferno at RiseFX: The Lost Bus first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

As with most science fiction films, “Oblivion” also required a lot of VFX work. Pixomondo and Digital Domain were responsible for the film’s digital eye candy. VFX supervisors Thilo Ewers from Pixomondo and Paul Lambert from Digital Domain explain how to create a huge ice canyon, 3D Tom Cruise models and a space station, among other things.

The plot of the film, in which Tom Cruise plays the superhuman in a post-apocalyptic world, can – in keeping with the film’s title – be forgotten. Visually, however, “Oblivion” is an extremely impressive film. Another positive aspect: the film has been released exclusively in 2D, which is unusual and courageous for an action blockbuster at the moment. The Blu-ray and DVD release is on 15 August – and you can win two BDs and two film posters in the reader survey in this issue of DP.

The VFX supervisors Eric Barba from Digital Domain and Bjørn Mayer from Pixomondo split the total of around 800 VFX shots between the two companies so that no scenes were edited together, only assets had to be exchanged. For example, Pixomondo created the 3D bubbleship and the ice canyon, while Digital Domain created the combat drones and the “TET” space station. The film was directed by Joseph Kosinski, who had already worked with Barba on “Tron: Legacy”. Among other things, the environments are crucial for the realistic look of the film. The film team shot many scenes not in green screen, but in the impressive landscape of Iceland. In addition, almost all of the film’s backdrops were recreated in real life, so that the digital elements in the film do not stand out excessively, but could be integrated almost seamlessly into the live action scenes. Over two-thirds of the film was shot at Celtic Studios in Baton Rouge, Louisiana, where the futuristic Skytower, the Bubbleship and the 2,800 square metre New York Library set were located. This set provided the VFX team with an ideal reference for the reconstruction of the 3D models using Lidar scans and HDRs. Tom Cruise was even allowed to take the motorbike that was constructed for “Oblivion” home with him after filming as a present for his 50th birthday. The Skytower was an important location, as around half of the film takes place there. Kosinski decided against using green screens in front of the windows in order to create a realistic atmosphere in this building of the future, designed with lots of glass and steel and located in the middle of the clouds. Instead, he used front projection technology with 13 metre high and 152 metre long screens and 21 projectors. The hi-res footage for the projection consisted of dramatic sky shots with variations in the time of day and weather. Bjørn Mayer and his team filmed these for almost a week on the Haleakala volcano in Hawaii using a rig with three Red Epics strapped to it. The real-life lighting setting was not only extremely helpful for the VFX team during the shoot in post, it also created a realistic atmosphere for the film team and the actors.

DP: Hello Thilo, how big was the Pixomondo team for “Oblivion” and which scenes did you work on in Stuttgart?

Thilo Ewers: A total of 231 people worked on 456 VFX shots, mainly in Los Angeles, Stuttgart and Beijing. In Stuttgart we had 144 shots and, as we are a well-rehearsed team here, Bjørn entrusted us with the most demanding scenes, such as the ice canyon with 100 shots and the drone attack in front of Raven Rock. We also did the hydrorigs, huge futuristic oil rigs that pump out water, and complex cockpit scenes.

DP: How were the assets swapped with DD?

Thilo Ewers: DD uses Maya, we use 3ds Max, so both companies have their own special pipeline. So that the other studio knows what to do with the respective asset, a kind of rule book was drawn up beforehand to define how data is to be saved and named. We also sent the rig files, as we each rigged the models ourselves. Which is quick to do once the creative work is done.

DP: Which database do you use?

Thilo Ewers: We use Shotgun because it works very well globally. We have programmed our own extensions to the software for the project, otherwise you would quickly lose track of the many individual parts.

DP: How did the real Bubbleship help you to recreate the 3D model?

Thilo Ewers: We had a high-resolution lidar scan of the ship itself and the cockpit as well as the designer’s CAD model, which was extremely helpful. Thanks to the CAD model, we discovered that there were other things planned that could not be realised in the replica of the bubbleship. There was also a separate mock-up shoot with the bubbleship, in which the actors were moved according to the flight movements.

DP: What tools did you use for the 3D bubbleship?

Thilo Ewers: We modelled and rigged with 3ds Max and textured with Mari. In Stuttgart, we set up our Mari pipeline especially for the project and expanded the tool for our purposes. We’ve been using Mari for two years now and everyone has learnt to love it.

DP: How was the lighting for the 3D bubbleship realised?

Thilo Ewers: There were two shot categories: Firstly, the flying ship in backplates from the Iceland shoot. We used HDRs from the respective shoots for the lighting. On the other hand, there were land scenes where we had to blend the 3D model into the real ship, which was a little more complicated in some cases. We also used HDRs for this. As we had recreated the ship precisely thanks to the lidar scans from the set, it usually matched the real ship well. We edited four of these landing shots.

DP: The brief was: “The landing platform shouldn’t have a Transformers look.” What means did you use to realise this?

Thilo Ewers: The production designer made a significant contribution to this. It was important to the director that the platform had a futuristic, straightforward and cool design that still had to look realistic. He was an architect himself and has a great penchant for functional design. In “Transformers”, the design is detailed and therefore appears rather overloaded at times.

DP: What was it like for you to work with the Skytower filming material using the front projection technique?

Thilo Ewers: Super. It worked so well that none of us could have imagined it beforehand. Almost everything you see in the final film was exactly the same during the shoot. That was a huge time and money saver. Creating the different sky clips beforehand was much more effective than having to matchmove everything and add the reflectors afterwards.

DP: Let’s move on to your biggest challenge in the film, the ice canyon. How did you go about it?

Thilo Ewers: Yes, that was something … At the beginning of the process, the question was: Will the canyon be made of ice or stone? And at first we just asked ourselves: What would be worse for us? Towards the end of the shoot, in July, the director decided in favour of the ice version. Bjørn took pictures of glacier formations that the director found interesting. After filming was completed, the Previz studio Third Floor created a post-viz based on our concepts to determine the speed of the animation and the camera work. But apart from this intermediate phase of development, the film was created entirely by Pixomondo. And despite the post-viz, we still had to design things like the floor completely ourselves when modelling.

DP: How did you go about the modelling?

Thilo Ewers: First of all, we thought about whether we should create the canyon in one big piece that we drive through or whether we should build it from individual parts. To do this, we created a kind of map for all the scenes, on which we saw who was flying where and how at what time – and realised that we were passing the same places several times. That’s why we opted for the modular solution and created around 150 individual parts for twelve categories, such as “overhangs” or “arches”, with different texture variations. The individual parts were around 30 to 60 metres high and 20 to 30 metres wide, fully modelled and textured and therefore extremely large with around eight million polygons per piece.

DP: That sounds like a lot of hard work ..

Thilo Ewers: Of course, it wasn’t possible to create 150 ice cream pieces individually. We would have gone mad and it would have cost far too much. So we initially populated the categories with relatively simple basic shapes that we built using the Postviz. In the first step, the artists created and animated the shots with these low-res objects, which were also the basis for the texturing.

DP: How did you then use procedural animation?

Thilo Ewers: Parallel to these processes, we created the procedurals with the low-res ice pieces in Houdini. When the animation artists were finished, we replaced the low-res pieces with the more detailed and textured hi-res pieces. Once everything was programmed in Houdini, we were able to turn a low-res part into a hi-res part within ten minutes and change the properties via self-programmed containers in Houdini. We didn’t solve everything using procedural processes, but also placed stones by hand so that we had an influence on the animation. We wanted the canyon to look modelled and not like a procedural. When the canyon was assembled with the floor in high quality, we ended up with up to 300 million polygons.

DP: How did you deal with this immense number of polygons?

Thilo Ewers: With V-Ray Proxy. We never saw the canyon in 3ds Max. And on the hardware side with normal 8-core and 12-core workstations.

DP: What physical laws were used for the procedural animation?

Thilo Ewers: We racked our brains over this for a long time and at some point realised what else makes ice besides shading. It can have pretty much any appearance, but it often has this flow and a layered quality. With Houdini, we were able to change the direction of the flow and the entire piece of ice was adjusted in all its procedural parameters. Funnily enough, we put hair on the surface to visualise the flow. We brushed it so that we could see how the ice would flow.

DP: How long have you been using Houdini?

Thilo Ewers: Since “Hugo Cabret”, so about two years. But here in Stuttgart we used it really intensively for the first time for “Oblivion”. We first had to integrate Houdini into our pipeline and build sync tools to keep Houdini and 3ds Max on the same level. Before Houdini, we used 3ds Max for procedural processes. But large quantities are simply more convenient and faster to handle in Houdini.

DP: How long was the ice canyon scene and how many shots did it have?

Thilo Ewers: The scene in the film was about 3.5 minutes long and had 89 shots.

DP: What new projects does Pixomondo have?

Thilo Ewers: We are currently working on the children’s film “Pettersson and Findus”, the cinema adaptation of the bestseller “The Medicus” by Noah Gordon and the children’s book adaptation “Doctor Proctor’s Fart Powder” by the successful Norwegian crime writer Jo Nesbø. Other commissions include the Fox TV show “Sleepy Hollow” and 3D motion ride films for the Chinese theme park Wanda.

DP: Hi Paul, what were VFX supervisor Eric Barba’s tasks on the project and yours as second supervisor?

Paul Lambert: Eric Barba has worked with Joe Kosinski for many years and was on set. My role was to supervise all the DD departments, including problem solving, so that everything could be delivered on time. I was also on set once for a camera test. I did colour checks and made sure that the look of all the cameras used was consistent.

DP: Which cameras were used for “Oblivion”?

Paul Lambert: “Oblivion” was shot with the Sony F65, which was brand new at the time. “After Earth” and “Oblivion” were the first projects ever to use the F65 camera. The production team used the Red Epic and the on-set team worked with the Canon 5D Mark III, 5D Mark II and 1ds Mark III cameras for the references.

DP: How big was the DD team for the film and how many shots did you have?

Paul Lambert: The DD team was 100 people in total and it was all done in Venice. We worked on 370 shots for “Oblivion”.

DP: With the different tools that DD and Pixomondo use, were there any problems with exchanging models?

Paul Lambert: Both companies use V-Ray for rendering. However, as Pixomondo works with 3ds Max and we work with Maya, we were able to share models, but not the exact shaders. That’s why we had a copy of 3ds Max at DD, which we used to view the Pixomondo models and then recreated them in Maya. Once you understand the look, it’s not difficult to recreate. What also helped a lot were the masses of references from the set that were available to both companies.

DP: What tools did you use to realistically integrate the digital elements of the film into the live action scenes?

Paul Lambert: This was possible thanks to the good reference base with the real models in the respective lighting situations. This allows us to concentrate more on the details and achieve a believable look. With a poor asset, more time is spent on pure integration.

DP: Were there any elements in “Oblivion” that DD created with procedural processes in Houdini?

Paul Lambert: Yes, we created all the classic Houdini scenes such as storms, explosions and smoke using our in-house tools such as the Storm Renderer and Houdini. These tools really help to fine-tune the effects.

DP: How long has DD been using Houdini?

Paul Lambert: Longer than I’ve been working at DD and I’ve been here ten years.

DP: Did DD write extra scripts for the project?

Paul Lambert: We have written some scripts, for example for dealing with Deep Shadows and other little things. But there are fewer and fewer projects that we have to script, because our pipeline now has a good basis so that we can work efficiently.

DP: Is it easy to find Houdini artists?

Paul Lambert: At the moment, yes – but it is becoming increasingly difficult. We currently have a good core group of eight Houdini artists at DD.

DP: For which shots did DD recreate Tom Cruise in 3D?

Paul Lambert: We recreated Tom Cruise for the scene where he fights his clone. For these scenes, he fought with a stunt double in both positions in front of a green screen, and we then rotoscoped the double out afterwards. However, there were some scenes where we had to completely replace Tom Cruise’s face. For such cases, we use a technique that we originally developed for the film “The Curious Case of Benjamin Button”. It was then used in films such as “Tron: Legacy” and “The Girl with the Dragon Tattoo”.

DP: What does this technique consist of?

Paul Lambert: We designed shapes in Maya with different facial expressions that we put on characters. But the core of this work is capture data. We take each actor to the Institute for Creative Technology in Los Angeles, which is run by Paul Debevec. He’s very well known in the industry for image-based lighting. There we place the actors in a dome with a special lighting setup. The actor’s face is captured very quickly with every light on it. The sampled light values provide a geometry of the light structure that can be imported into the CGI scenes. With this data from the light stage, we can make the CG version of the actor’s face look like the real thing.

We took hundreds of HDR photos of Tom Cruise in the dome, so we had a perfect reference for every conceivable lighting condition. The Oblivion scenes with Tom Cruise were a little easier than past film work because he doesn’t speak in the scenes.

DP: Was Tom Cruise also completely scanned for the scenes?

Paul Lambert: Yes, a full body scan was made of him in the suit. We also shot props such as his suit and helmet individually with different lights.

DP: What was the most complicated scene for you on the project?

Paul Lambert: That was the final scene with the TET space station. As soon as we saw the concept, we realised that it was going to be very complicated. The space station was around 100 kilometres long and extremely detailed. And modelling and texturing an asset on this scale was very complicated, but we still managed to pull it off.

DP: How did you become a supervisor?

Paul Lambert: I’ve been with DD for ten years, before that I worked as a CG artist in the UK for eight years. I’m currently still working in California, but the tax incentives in Canada have really hurt the Californian VFX industry. And at the moment, companies are looking at the tax incentives and going there. I think that’s why I’ll be moving to Vancouver sooner or later.

DP: What school did you go to?

Paul Lambert: When I started in the VFX industry 18 years ago, there were no schools for this field. It happened more by accident. Initially I studied engineering at college, but it wasn’t right for me. Then I went to art school and graduated. In the meantime, I worked as a courier in London for a while and one of our clients was in the film business. I talked to the film team a lot and was able to work there a bit. I thought to myself that this job is both technical and artistic. It suits me perfectly. I wouldn’t want to do anything else.

The post A memorable VFX project first appeared on DIGITAL PRODUCTION and was written by Mirja Fürst.

This article by Mirja Fürst originally appeared in DP 02 : 2013.

We spoke to Florian Gellinger, one of the VFX supervisors and founder of Rise | Visual Effects Studios, about the elaborate work “Cloud Atlas” and his workflow.

DP: What was it like for you to work on “Cloud Atlas”?

Florian Gellinger: Overall, it has to be said that the work was very relaxed despite the complexity and the amount of shots. We were the first VFX company on board and were therefore able to plan our personnel and technical requirements well in advance.

Accordingly, we are very happy to have proved that good preparation pays off not only in terms of the quality of the visible results. It was a really great time for everyone.

DP: How did you come up with the “Cloud Atlas” project?

Florian Gellinger: We worked with Dan Glass, the senior VFX supervisor of “Cloud Atlas”, back in 2008. Back then for the film “Ninja Assassin”. Since then, I’ve met up with him in Los Angeles and at the FMX in Stuttgart. When he set up shop in Berlin for “Cloud Atlas”, he called us. We provided him with some of our 3D artists and workstations for the pre-viz phase, scanned various locations and sets with our LIDAR scanner and when the shoot started, I supported Stephane Ceretti, the second VFX supervisor, on the set of the Tom Tykwer Unit with set supervision.

DP: Did you only work on shots for Tom Tykwer’s sequences – or also for the Wachowski siblings?

Florian Gellinger: We mainly worked on Tom Tykwer’s sequences. For example, we were the main vendor for the Luisa Rey episode in 1973 San Francisco. We created a nuclear power plant on an island for day shots as well as for twilight and night shots, including the bridge that connected the island to the mainland. We exploded an aeroplane and pushed a CG VW Beetle off the bridge. We also created a CG environment for dry-for-wet underwater shots. And finally, we transformed day and night shots of Glasgow and Düsseldorf into the San Francisco of the 70s. We also did some cleanups, sky comps and set extensions for some shots of the 1936 episode in Cambridge. For the Wachowski siblings we created some thunderstorm shots for the 1849 South Pacific sequence as well as a bionic CG eye patch for a doctor in Neo Seoul 2144 and set a SatComCenter on a mountain in post-apocalyptic Hawaii 2346.

DP: How many shots were there in total?

Florian Gellinger: We worked on 106 shots in total, spread over five of the six episodes in “Cloud Atlas”.

DP: Did you receive previews or a storyboard?

Florian Gellinger: We received the editing references for the respective shots. On the one hand, these were layouts from the production company’s in-house artists, the previews that our artists created with the directors or images from the art department for the SatComCenter, for example. On the other hand, sometimes it was simply the pre-graded source plates.

DP: How long did the work take, how many people at Rise | Visual Effects Studios were involved?

Florian Gellinger: We started with the pre-viz in July 2011 before the shoot, and then we were on set from time to time during the shoot to scan the locations or supervise. Parallel to the shoot, some of our artists were already creating the postviz. The actual editing of the shots started at the beginning of 2012 and continued into the summer. In total, over 40 people were involved in the project at times.

DP: How did you divide up the work in the team?

Florian Gellinger: There was a lead compositor for each sequence (nuclear power plant by day/night, car crash, “Glasgow to San Francisco” remodelling), who had his own small team. In 3D there was a lead artist who was mainly responsible for the explosion and bubbles in Houdini. Together with our Lead Pipeline TD, he integrated Houdini into our pipeline. There were also a few independent artists for the other 3D tasks.

DP: What tools did you use?

Florian Gellinger: We used Nuke 6.3 for compositing. We have customised it a little with our in-house tools so that some of the work is easier. For the 3D work, we use Maya and Houdini, which have also been enhanced with some custom tools. We use Faro Scene software to process our LIDAR scans and Geomagic Wrap to mesh and prepare the point clouds.

DP: Did you have to expand your in-house risebase database in any way or write new scripts for the project?

Florian Gellinger: “Cloud Atlas” was our first project in which Houdini was used. Accordingly, it first had to be integrated into our pipeline. Some special delivery functions were added to our in-house risebase database to simplify data exchange with the customer.

DP: How did you send the data to the directors for viewing?

Florian Gellinger: We uploaded HD QuickTimes to a server at regular intervals, from which both the directors and the editing room could download the data.

DP: How was the collaboration with the other VFX studios? Or was there no overlap in the work?

Florian Gellinger: We supplied a model of our VW Beetle to Industrial Light & Magic (ILM), which appears in the background during the chase with the skiff bike in Neo Seoul. We also rendered the SatComCenter for Method, who then placed it very small on the mountain from a distance.

We also provided the LIDAR scans for all the companies involved in the film. This means that every set and every vehicle was delivered as a 3D model to the companies that processed the corresponding shots.

DP: How did you like the finished film? Do you think that despite the large number of VFX studios involved, it was possible to achieve a homogeneous look for the effects?

Florian Gellinger: We organised our own small company premiere as a thank you to the whole team for their great work and to show our work to friends and customers. I think the look is very homogeneous.

This was also achieved by allocating the effects to the different VFX houses on a sequence-by-sequence basis as far as possible, so that there was a main vendor for each sequence who was responsible for creating a uniform look for their shots.

DP: Which shot in the film are you particularly happy with?

Florian Gellinger: We are actually very happy with all the shots because they all have their own special features. Be it the particularly unobtrusive integration of the San Francisco set extensions or more spectacular shots such as the aeroplane explosion or the car crash with the realistic air bubbles and cracks under water. We also like the SatComCentre on the mountain.

DP: What would you do differently in the workflow – with the knowledge you have now?

Florian Gellinger: Based on our experience with the numerous LIDAR scans and texture photos, we have developed a new workflow that allows us to light our 3D scene much faster and more efficiently and also to react much more flexibly to different lighting situations in the same set. There will also be an article on this in the next issue.

The post Interview zu Cloud Atlas first appeared on DIGITAL PRODUCTION and was written by Mirja Fürst.

Dan Levitan

If you want to know how VFX supervisor Dan Levitan managed to turn Los Angeles into Sodom and Gomorrah for the post-apocalyptic Covid film Songbird, you’ll love the VFX breakdown below.

You can find out what Dan shoots outside of post-apocalyptic everyday life on his homepage.

SONGBIRD VFX REEL

 

The post Songbird | VFX-Breakdown first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

Seth Maury about Mulan

Listen to Seth Maury, Visual FX Supervisor on Disney’s major production Mulan, chat about the challenges facing Imageworks? Then tap the play button below. If you’re less interested in what Seth Maury has to say, perhaps you’re more interested in Alita: Battle Angel, The Twilight Zone, Amazon’s Utopia, Ratched or Snowpiercer? No? Then shoo, shoo, away with you.

Mulan – VFX by Imageworks – Earth and Snow

The post Mulan | VFX-Breakdown first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.