Milk VFX’s work on Heads of State opens with a high‑octane “La Tomatina” sequence dominated by CG mayhem. VFX Supervisor David Sadler‑Coppard – IMDb | LinkedIn led his team through a shoot‑interruption due to strikes, transforming a modest placeholder‑tomato setup into an extensive, fully digital fruit fight.

DP: So, I heard there was a Food Fight at Milk VFX … 

David Sadler-Coppard: I was assigned as VFX Supervisor for Heads of State at Milk when we were first awarded the show. Initially, we were bidding on several sequences, with the La Tomatina Festival scene being relatively modest in scope. The festival is a real thing, by the way. However, after the production went on hiatus for about a year due to the strikes, we reviewed the first assemblies and quickly realised the sequence needed far more work.

We were basically briefed to replace all of the tomato ‘matts’ practical placeholder red matts used on set which didn’t really hold up in camera with CG tomatoes, tomato pulp and tomato liquid, also to add additional flying tomatoes and tomato splats and additional texture to walls/buildings as needed. While there was other work in the Tomatina sequence, the tomatoes were the star, and they had to be convincing without distracting from the action, especially since this was the film’s opening scene.

What began as a seemingly simple brief grew into a complex undertaking as post progressed, from intricate simulations and crowd integration to the careful management of ongoing feedback. We had a schedule from around July to November, which ended up extending into January. At peak I think we were around 30 artists.

DP: The Tomatina sequence is a tomato lover’s nightmare and a VFX artist’s dream (or possibly the other way around). What were your first thoughts when you saw the plates?

David Sadler-Coppard: It became clear very quickly that La Tomatina needed a lot of help from VFX. Almost every shot had either a few red matts on the ground or nothing at all and thus required tomatoes. There was also lots of stunt, rig and wire work that needed to be brought together and integrated well. For me seeing some of the wide shots with hundreds of people running around on an empty plaza and being briefed to add tomatoes underneath them.. That was quite a challenge.

DP: What were the plates from the set like? Was it at least wet and glistening, or did they just throw around some red fabric?

David Sadler-Coppard: The production was very organised and Milk was provided with plenty of shoot information such as clean plates, HDRIS, Lidar and 3D assets if applicable and anything we needed really to get things going. 

Some shots featured placeholder tomato matts on the ground, though these often caused more problems than they solved, as they tended to “slide” and interfere with shadows or contact points with the crowd. Other shots had nothing at all, while certain close-ups included a scattering of real tomatoes. In the end, we often replaced even the practical ones, as it was ultimately easier and gave us more control over consistency and integration.

A lot of the stunts and setpieces were filmed or partially filmed practically like the explosions and Milk usually just ‘enhanced’ or extended and further integrated these set pieces together. Originally the crowd work was larger in scope and we had bid to do more 3d crowd extension work but in the end we only ended up using them in a few shots, it’s just how the edit came out. They were only meant to be used to fill out the background.

DP: So, roto must have been a nightmare?

David Sadler-Coppard: Roto and paint was certainly a challenge but managed brilliantly by Ben Thomas (HOD Roto/prep –find him on LinkedIn | IMDB ). As well as all the actors and props, we also had to roto all the shadows on the ground, which we couldn’t key properly in some cases (sometimes due to the matts), to ensure seamless CG integration.

DP: Since no tomatoes were harmed in the making of this scene, you had to create them digitally. What were the big technical hurdles in making thousands of CGI tomatoes fly, splat, and interact with actors and the environment?

David Sadler-Coppard: As we had a fixed region with the Plaza we opted to create a large environment pass scattering all the pre-made CG tomato chunks, liquid and pulp everywhere. This was masterminded by the very talented Charles- Henri Vidaud, our Head of Environments (Find hiim on IMDb | LinkedIn).

It took many rounds of feedback and notes to get the overall ‘layout’ approved, essentially the coverage and boundary of the whole tomato area. Luckily shoot continuity was quite good so once all the cameras were conformed the layout was more or less in place quite quickly, although some shots had additional custom tomatoes added.  For the final section where Priyanka slides through the tomatoes on her back, we created a custom hero section with extra detail to hold up close to camera.

We also created additional texture passes across the plaza, tyre tracks, footprints, extra stains, and even a depth pass isolating the plaza’s pebble mortar, to capture the effect of tomato juice seeping into every crack and crevice. These IDs were rendered alongside the other CG passes, giving comp a safety net in case the CG alone didn’t fully achieve the desired look.

With regard to the simulations it was quite time consuming. Obviously we could not matchmove every single foot in every shot so we had to pick the ‘best’ ones that we felt would help sell interactions the best. The tomato layout area was then isolated around those feet and passed to FX where just that patch was simulated and then pass back and merged with the lighting scene. 

For hero simulations like people sliding around in the tomatoes we did full body tracking not just for the sim but also for shadow casting back onto the tomatoes. Getting that interaction working  really helped sell the CG for me and our HOD Andres Tollar oversaw all that team and their work.

The flying tomatoes consisted of simulated chunks and liquid that was randomly emitting across the whole plaza and could be enabled or disabled depending on the notes as the directive was usually to just add into the background of shot for extra chaos as needed. The shot specifically where Priyanka slides and comes to a stop in the tomato goo took about 40 versions to get just the right consistency and behaviour approved.

DP: And why were no real tomatoes used in that scene? They could have collected the pulp and put it in barrels labelled “Artisanal Ketchup”—the hipsters would buy that…

David Sadler-Coppard: As with these large vfx tasks we started simple and just grew it organically.  We thought we might be able to tackle the ground tomatoes with a procedural setup which looked good but was not very directable. We ended up creating several tomato chunks of different sizes and scattering them with some logic to that as well as a general ‘pulpy’ layer which was essentially large patches of displaced geo, randomly scattered around to fill out the square.

The advantage of this is we had lots of flexibility to move things around and generate IDs for comp, but it was very heavy to work with. We also used the lidar to hold out sections of the tomatoes to help them feel more embedded into the ground.

From there it was really nailing down the shading of everything. We did lots of work on the ‘wetness’  and spent a long time really pushing the liquid feel as much as we could not just in the lighting but well into the compositing as well. Specifically in comp, our Lead Emily Vaillincourt (find her on IMDb | LinkedIn) built a whole fake reflection system using the data passes and roto to help create the wet feeling as it was a common note and a tricky one to address.

The client was also keen on having tomatoes smushed into the cracks and gathering in corners and this is where the texture passes in comp really helped as the CG didn’t always fit exactly.

We did pick several ‘key’ shots across all the different angles and lighting conditions and worked these up first to try and find the look the director was happy with. We did have some issues getting a consistent look across all the shots, as not only did the lighting change quite significantly, we would receive quite specific notes on singular shots, and had to constantly extrapolate them across the sequence.

Creatively we found that if we had enough variation and breakup across the shots especially the wide shots within the lighting then the shots usually looked successful. We did research on the actual Tomatina Festival and the whole plaza quickly turns into a very uniform pulp which, if we had recreated perfectly, probably wouldn’t have looked as interesting compared to what we ended up with. So I suppose there was a small element of stylisation to our tomatina. 

DP: There are a lot of people in that square. How did you handle the crowds? 

David Sadler-Coppard: Honestly, the CG crowd component was significantly reduced in the final film so there isn’t a huge amount to talk about. Production did manage to shoot with a very large amount of SA’s and several larger shots used tiled plates or element plates to help fill out the square. O

ur biggest crowd shot was the drone shot showing the entire square and festival from the air and that used a crowd system within houdini using animated caches, some made in house and some using stock animations, with some logic on the layout and animations themselves. We had to match the overall density and look for the crowd with surrounding real plates so that was a little tough. 

DP: Any unexpected “aha!” moments?

David Sadler-Coppard: We had several concepts for key shots in the film that were approved on the first or second pass, which was a pleasant surprise — normally there’s a lot more back-and-forth. I suppose we got a bit lucky!

One memorable moment came when we delivered a nearly final version of a huge, complex building destruction shot, fire, smoke, the works. That’s when the VFX Supervisor told us it needed to be in HFR, meaning we had to re-simulate all the fire and smoke. The team had to find a way to preserve the overall fire composition while adjusting the frame rate, and they pulled it off brilliantly.

It wasn’t exactly an “aha” moment, but getting our first big tomato shots approved was a real relief. That was when we knew our quality level was locked in, and the finish line was in sight.

We faced plenty of technical challenges internally, though most were to do with pipeline and rendering,  not the most glamorous side of VFX. Working with heavy deep passes and at native 4K anamorphic meant we had to be extremely optimised and rely on well-structured templates in comp to keep things running smoothly.

DP: About that scene in the safe house: How many iterations on the exploding door/Claymore?

David Sadler-Coppard: We were given an offline temp for the beat of the exploded safehouse door. The concept made sense in principle, but it got me thinking about how to make it work in reality. We explored a range of angles and animation tests with our animation team and client editorial, fine-tuning timings and composition until we had approval.

It wasn’t immediately clear whether the corridor needed to be built in CG, but it became obvious once we considered the specific lenses and angles the client wanted — it just wasn’t feasible to shoot practically. The exact moment when the claymore is triggered took some back-and-forth. In the end, we decided to create a proximity sensor in our CG claymore, complete with a blinking light, to guide the audience through the action.

The final version ended up quite different from v1. Initially, we worked over the supplied plates, which featured simpler camera moves. The door animation itself remained largely the same, but the cameras evolved into something far more dynamic.

DP: And, after running that through sim: Would that actually work? Or is it complete Hollywood Physics?

David Sadler-Coppard: It was a combination of research and references. The client had mentioned the Matrix elevator fire shot which was a good reference and we started with that. Essentially the explosions were all smoke simulations with a fire shader applied to them which gave us these nice undulating rolling fire shapes. We didn’t have any practical fire in camera in any shots so we were free to design it as needed.

During the initial explosion simulations, it quickly became clear they needed a fair amount of direction in terms of scale and timing to keep the action readable. The client was also keen to make them all feel very “dirty”, full of texture and detail,  even though, in reality, the blast would probably just blow out the sensor completely.

And as for the flying door… I’m almost certain it would never bounce back and forth so cleanly, but that’s Hollywood for you. We did experiment with it ricocheting around the corridor or shattering into dented fragments with a lot more impact, but it never quite looked right, and the director wasn’t a fan of those versions anyway.

DP: The shot with the two characters in the VERY small lift: Was that the easiest shot ever? Or am I missing something?

David Sadler-Coppard: This was one of the first shots we started on, and, as often happens, it became one of the last to final. The client had a clear vision for a dynamic raking light-and-shadow effect playing across the wall behind the characters, so we built the entire environment in CG to give full control. We carefully layered in details,  mortar, texture, even cobwebs, to give the space a gritty, lived-in feel.

Later, we explored adding subtle camera shake and sway to enhance the sense of atmosphere and movement. After refining it together through multiple iterations, we reached a version everyone loved, approved towards the end of the show.

DP: And, of all the 239 shots – what is your personal favourite shot?

David Sadler-Coppard: I’m incredibly proud of all the Tomatina work, and of the entire team who brought it to life. It was an emotional journey with plenty of late nights, but seeing it come together was worth every moment. Let’s just say I’ll never look at a bottle of Heinz quite the same way again.

DP: And finally, what’s next for you and the Milk team? Are you staying out of food fights for a while?

David Sadler-Coppard: Milk has several exciting projects coming up and I am nearly wrapped on The Witcher Season 4 myself. It’s an exciting, if slightly nerve-wracking time in the industry right now, but working with a talented, passionate, artistic team on such a tough but rewarding job reminds you why you love VFX in the first place. 

The post Tomato Warfare: Milk VFX on Heads of State first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

With over two decades of experience spanning Hollywood blockbusters, Netflix series, one of the editing teams favourite animated movies, and award-winning game animations, co-owners Jonas Ussing and Stine Sørensen have established a reputation for delivering top-tier visual storytelling.

Official Website: spaceoffice.dk | LinkedIn: Space Office VFX | YouTube Channel: Space Office VFX

Jonas Ussing: An Emmy-nominated VFX supervisor, Jonas brings a wealth of knowledge and expertise to the studio. Also, he worked on the brilliant “Cowboys vs. Aliens”
Stine Sørensen: An experienced feature film animator, Stine’s creative vision and animation skills have been instrumental in shaping movies like the evergreen “Ronald the Barbarian“

DP: How did you get involved in this project?
Stine Sørensen: We have several great projects for Flashbulb Games behind us, so when they continue to return to us for new game trailers, we’re already in. This time we were especially excited because the setting was sci-fi and spaceships, a genre very dear to our hearts.
The story was fleshed out roughly by Flashbulb, and they knew it would need to explain how the player ends up precisely where he does at the beginning of the game, because the trailer would also function as the game’s opening cinematic.
Our first step was to take their rough idea and focus entirely on the story and character. They had a lot of exposition they wanted to cover in very little time, so we needed a lot of quick shots that would quickly explain in simple images what was going on.
During the iterations of the story reel, we would sometimes stray too far away from the game’s core concepts, and Flashbulb would guide us back, to make sure the trailer experience wasn’t too far removed from the gaming experience.

DP: Can you give us an overview of the team that worked on this?
Stine Sørensen: Our team was a mix of in-house talent and specialized freelancers, which allowed us to remain agile. We handled storyboarding, layout, animation and shot assembly/rendering internally while bringing in additional expertise for easily outsourceable tasks like character modelling, rigging and hard surface asset creation. Working as a boutique studio meant we could make fast creative decisions, avoiding the slow turnaround times that can come with larger teams. 
We use Ftrack to handle all artists, shots and tasks, as well as upload turntables, renders and storyreel as review sessions for the client.

DP: How long did the whole process take from pitch to final delivery?
Jonas Ussing: We only had four months from start till deadline, so we had to hit the ground running and immediately started assembling an animated storyboard on a timeline. Nailing a tight storyboard that hits every beat you need is crucial in animation, because this is literally the movie itself you’re creating, and if there are story problems here they won’t be solved by great animation or effects farther down the pipeline, so you really can’t allow animation to start before the story reel is perfect.

Stine Sørensen: To finish in four months, we needed to keep things moving in parallel, so we started up on assets while storyboarding – this is always risky because as long as the individual story beats are being discussed, anything might go, so we don’t know for sure which assets will be needed.

The one asset we were certain would be in the final film was the hero Trailmaker, so we had one modeller up-ressing his hard-surface props while another completely redid the organic modelling, updating him to look like a character in a big studio animation feature film, while keeping him “on model” with the game. For instance it’s unclear in the game exactly how human-like the facial features of the Trailmakers are up-close, so there was some look development in cooperation with Flashbulb.

“Pioneers” is not a new game, it’s an update for “Trailmakers” which has been out for 7 years, and it has a remarkably large fanbase who know every little detail of the characters and the props, which we don’t, so it was extremely important that our hi-res assets not deviate too far from the game’s aesthetics, and we were constantly getting feedback from the game’s art director, making sure we always stayed on track.

DP: What kind of assets did Flashbulb Games provide, and in what formats?
Jonas Ussing: With a finished Trailmaker model, we updated the in-game texture to a hi-res PBR material, and had a few versions of a turntable before the model was approved, and it could move on to rigging. 
However, while all this took place, we started 3D blocking using the in-game character and other assets lifted directly from the game. 
Several spaceships were custom built for the trailer at in-game detail level by Flashbulb, and sent to our hard-surface modeller for up-ressing, while unique environments such as the space station exterior were almost completely rebuilt.

We have a custom set of Star Wars type greeblies that our space station modeller used for kitbashing the exterior surface. It’s no secret that Star Wars is the hallmark of movie spaceships, and inspired by the star destroyers in Rogue One, we even applied a bit of V-Ray sub surface scattering to the space station to mimic the look of small-scale polystyrene used for spaceship miniatures.

Flashbulb gave us some interior sci fi assets to get the hangar set up and running, but we added so many custom assets it’s almost entirely built from scratch.

DP: From storyboard to final previz—how did you iterate?
Jonas Ussing: We focused our storyboard drawings on clearly and simply representing camera angles, motion and story beats, as opposed to maybe more time consuming “pretty storyboards”. This way, we could shoot out dozens of panels per day, and every week upload several completely new versions of the story reel on Ftrack for client feedback, including new ideas or requests from the client, ironing out things that needed to work better, and sometimes omitting shots that were redundant or just getting in the way of storytelling.
Because cinematic decisions like blocking, camera angles and camera lenses are already taken into account in our storyboards, translating each panel to 3D is fairly straightforward, and creating a complete 3D blocking for approval is super fast.

DP: Moving from previz to rendering—what challenges did you face using both 3ds Max and Maya?
Stine Sørensen: Once approved, animation is cached as alembic and brought into a 3ds Max/V-ray render scene, where we can also load cached Tyflow or Chaos Phoenix simulations.
It’s essential for a small studio that per-shot handling is reduced to the absolute minimum, so we can’t afford rendering everything separately per shot, so having all animation caches render in the same pass as Tyflow environments, destruction and Phoenix fire elements is great for us.

Jonas Ussing: We have followed Tyflow since before its official releases and it’s absolutely the go-to tool for all things related to destruction and complex particle work in 3ds Max, not to mention its frequent updates and new features, such as the landscape generator, which generates hi-res, textured landscapes with erosion simulation in mere minutes, and they run realtime in the viewport so they can be a part of the early playblasts instead of a low-poly placeholder.

DP: What was your experience rendering with Chaos Cloud, and how did you approach final image quality?
Jonas Ussing: Cloud rendering is essential for a small studio like ours to render high quality frames and deliver on time, particularly when the schedule is as tight as this and all rendering will be done in the last few weeks.
When you upload a shot to Chaos Cloud, the first thing that happens is essentially the same as when you render locally – every frame is converted to Chaos’ proprietary Vray Scene format, completely stripping the scene of any plugins or software specifics, reducing it to only what Vray needs to know to render the frame, and this stack of V-ray scenes is then uploaded to their render farm. This means there is a significant per-frame per-vertex cost in creating and uploading these scenes, which for a heavy shot might take much longer than actually rendering it!

The process is optimized by Chaos as much as possible, so for instance an asset of non-deforming geometry such as a spaceship only needs to have the geometry uploaded once per shot, not per frame, and then the subsequent per-frame transformations will be applied server-side. But a geometry-deforming animation, such as a cached character or a destruction simulation, is entirely uploaded per-vertex per-frame, which can be really time consuming. We therefore lean towards optimizing polygon count and work instead with the V-Ray materials to add the subtle details.
Chaos Cloud also identifies Phoenix cache files, so if you repeatedly submit a shot with the same 300gb Phoenix explosion, it will only be uploaded the first time, and subsequently be identified as already existing server side, saving you hours of upload time.
For the first upload of a shot, we initially select very low render settings, which produces a shot that, while too noisy for final delivery, is good enough for comments on look and lighting, and even some compositing.

Rather than use the typical AOV render passes for compositing (reflection, specular, lighting etc) we almost exclusively use Lightmix – which splits up every light source into its own element. This element then includes all light contributions from that light source, including GI, SSS, reflections, specular, etc.
Basically this means we treat the scene more like photography than an artificial computer rendering – we simply trust the approved assets to look as intended, and instead use the V-Ray Lightmix passes in Nuke to tweak each light source individually – a character might be rendered with a key light, a fill light and a rim light, and by adjusting these in compositing we can art direct or completely re-invent the shot in minutes.

Light sources are named from a naming convention, and our Nuke template is set up to receive these, so the shot is immediately “done” in a default version upon opening the Nuke script for the first time, and things like lens distortion, chromatic aberration, light source glow and flares are all set up in a default version that usually needs no tweaking. If the shot calls for an animated light source like the flickering light from the tesla coil on the Trailmaker’s “maker gun”, we will render this as a constant light source, and animate its intensity in Nuke.

We use ACES colorspace for compositing – not so much because we need the colorspace to match across multiple inputs and outputs, as is really its main purpose, but simply because it produces a filmic color response with a celluloid-like “shoulder”. This means that flares, engine glow, lamps, sparks and highlights, all essential components of science fiction, immediately look like James Cameron filmed them on 35mm, with a nice soft rolloff, instead of us having to worry about softclipping or highlight tweaking.

We also render motion blur and depth of field directly in 3D, as opposed to using motion vectors and depth passes to do it in compositing, which means we don’t have to worry about the usual compositing artifacts with edges, transparent materials, reflections, shadows etc.

Once the look of a shot is approved, all we have to do to get the final hi-res version is to duplicate the job on Chaos Cloud and increase the render settings. The shot will then be finished in a few hours, in perfect high resolution and quality, ready to download and replace the old render in compositing, and inserted in the main timeline.

DP: What was your approach to character animation and rigging, given the mix of in-game and cinematic assets?
Stine Sørensen: When we received the Trailmaker character from Flashbulb it was only rigged with bones and no controls. As the gamer spends most of the time building vehicles or riding in said vehicles there are very few character animations needed in the game and therefore Flashbulb had opted to just code the run cycles and a few movements. We had one of our go-to freelancers rig the character from scratch. He has built his own rigging system for 3D Studio Max and we are very familiar with his rigs.

For this project we also needed facial animation so I drew different facial expressions to give our rigger an idea of what was needed. He created about 20 different morph targets that combined could give us the necessary expressions. 

We only had one character rigged but we did some variations in textures and some morph targets to change the body size to make the background characters.

For animation we use SmartRef which is an external plug-in system for 3D Studio Max that makes it possible to reference objects into a scene similar to how Maya’s reference system works. If it were not for this plug-in it would be virtually impossible for us to have an animation pipeline with multiple shots and assets as 3ds Max’s own Xref system can’t be used for animating objects that have been referenced into the scene. Over all 3ds Max is not ideal for character animation as it is very hard to find any plug-ins for saving poses and animation and the curve editor hasn’t been updated for at least 15 years. But on this  project we deemed it feasible because only half the shot contains character animation and the shots would be assembled in 3ds Max anyways for lighting in Vray and destruction with Tyflow. Thus we could cut out a whole part of the pipeline compared to if we had animated the shots in Maya and cached them out to transfer to Max. 

DP: What’s your most memorable shot from this trailer?
Stine: I’m a character animator through and through so any scene where I can convey a feeling or work with facial expressions is always the most fun for me. The character design from the game has just two black dots for eyes so that didn’t leave much to work with. But I do think that with the morph targets we did for the facial rigging we ended up with something quite decent. If I have to choose a shot it would probably be the very first shot of the Trailmaker where he is looking out of the window with awe at the Space Station.

Jonas: There are so many little moments and details to choose from, but if I were to choose any one frame to print in poster resolution and hang on the wall, it would be the establishing shot of the Space Station. Star Wars is the very DNA of why I do what I do and I just love the look and feel of that greeblie filled massive space station with a detailed texture and space lighting.

DP: What was the biggest lesson learned from this project?
Stine Sørensen: Finding riggers and animators for 3ds Max is very difficult, and the animation tools in Max are hopelessly outdated and under-maintained, and since we bring in Alembic caches in the render scene anyway, our next project will likely be animated in Maya. We have done this on an earlier project, and the process was very smooth.

DP: What’s next for Space Office?
Stine Sørensen: We also do visual effects for live-action and television, but this is typically a handful of sequences on a film where we are very far removed from the storytelling process – and while this can be a lot of fun, creating entire game trailers from storyboarding to final frames is a whole new level, and this is absolutely what we’re looking to focus on.

The post Trailmakers from Denmark! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Subtitle Translation

Another feature in the Premiere Pro beta is Subtitle Translation. When I recorded this interview with Anton Knoblach, I did not know that the whole Digital Production would change to English in 2025 (Nobody knew that at the time, or if so, Bela didn’t tell me!)). But with the help of this new feature I could easily translate my German subtitles to English. That worked pretty good and there were only a few words to fix in the text panel. But I also wanted an english voiceover. So I exported the english subtitles and opened them in elevenlabs. After generating the english voiceover, I imported the audio files in Premiere. After some timing adjustments I and lowering the german original voice, I had an english version with even german and english subtitles side by side. I must admit that the english voice does not sound so great, but it does the job. Other voices would have been available…

The feature supports native translation of subtitles into 17 languages, making it easier to create localized versions of projects. This significantly reduces the reliance on manual translations, which often slow down workflows and add to production costs. For more details on the Premiere Pro beta and its features, visit Adobe’s official page here.

Although the voice recordings of the DJI wireles microphones were already pretty good, I enhanced them with the Adobe Podcast online enhancement tool. That reduced the tradefair-showfloor-background noise a lot. Tip: To avoid audio artefacts and a “unnatural” sound, I usually put the amount on or around 80 % – your result may vary, but give it a try!

The post IBC 2024 Adobe AI News with Anton Knoblach first appeared on DIGITAL PRODUCTION and was written by Nils Calles.

---

World VFX Day 2024 streams live from Megalis VFX studio in Tokyo this Friday (4 PM JST) and Sunday (10 AM PST), offering over 20 hours of talks, interviews, and project showcases. The event covers a wide range of VFX topics, from technical discussions to creative insights, available in live-stream format. Attendees should join throughout the day to catch key moments, and follow the LinkedIn event pages for updates.

For those looking to participate, it’s recommended to join the live stream throughout the day to ensure not missing any key moments. Even if you’re only able to listen passively, there’s something to catch from this extended program. Keep an eye on the LinkedIn event pages for the latest updates, and make sure you’re signed up to stay informed.

Price Information: The event is free to attend online, but registration is required. Please check the official event page for further details.

Fact Check: As with any live event, please note that schedules and content are subject to change. Ensure you’re staying updated via the event’s LinkedIn page for the latest information.

One other thing: If you are in Munich on Friday: The VFX Crowd is meeting at Astor Film Lounge on December 6th, 7pm.

The post World VFX Day 2024: Live Event Details and Highlights first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

In the case of Linux, this is done by the Linux Foundation. Some VFX-relevant open-source projects, such as OpenEXR or OpenVDB, are now under the umbrella of the Academy Software Foundation (ASWF), which in turn is under the umbrella of the Linux Foundation.

Anyone working with VFX will inevitably also directly or indirectly use open-source technologies, such as OpenEXR for exchanging images with high bit depth in the scene-referenced colour space, OpenColorIO for colour management, or OpenImageIO for reading and writing numerous image formats. These components are usually invisible to the user as parts of larger software, such as The Foundry Nuke, Autodesk Maya, or Blender. Although these open-source projects are used by many companies, the development of the projects was mostly in the hands of individual companies. For example, OpenEXR was under the control of Industrial Light & Magic (ILM), Open Shading Language (OSL) was managed by Sony Pictures Imageworks, and OpenVDB was overseen by DreamWorks.

A Question of Trust

This situation was unsatisfactory for other market participants, as they did not trust each other. This is also one of the reasons why all these projects are open-source and subject to extremely permissive licenses. Disney, for instance, would never use proprietary software from DreamWorks, but it would use OpenVDB as open-source software under the Mozilla Public License. However, trust would be further strengthened if the projects were managed by a neutral third party. This would also address the issue of projects becoming orphaned when a central developer changes jobs.

Enter the ASWF

The Academy Software Foundation (ASWF) has taken on this role, and under the auspices of the experienced Linux Foundation, it has successfully persuaded competitors such as NVIDIA and AMD, DreamWorks and Weta Digital, as well as The Foundry and Adobe, to work together. Jean-Francois Panisset explains how this was achieved in an interview.

DP: I‘m here at FMX with Jean-Francois Panisset (is.gd/jean_francois_panisset) from the Academy Software Foundation (ASWF). It‘s basically an umbrella foundation for a lot of open source projects that are currently used in visual effects. But why do you need an umbrella foundation for those projects at all?
Jean-Francois Panisset: Many foundational projects, like OpenEXR, OpenColorIO, and OpenVDB, were originally developed by major visual effects studios and later open-sourced. OpenEXR, for example, was open-sourced around 2003, and for a while, everything worked well — other studios could download the software, and vendors could integrate it into their products.
However, as time went on, the original creators moved on to new roles, left their companies, or even left the industry entirely. This led to a lack of active maintenance, and these projects began to stagnate. Bug reports went unaddressed, pull requests weren’t reviewed or merged, and in some cases, the projects couldn’t even be built anymore due to a lack of automated CI builds. It became an industry-wide problem. Recognizing this issue, discussions began on how to maintain these projects long-term and create a sustainable ecosystem. CTOs from major studios and software companies held meetings, conducted surveys, and explored solutions with organizations experienced in setting up foundations.
The Linux Foundation emerged as the best fit, having successfully created similar initiatives, like the Automotive Linux Foundation, which brought together competing car manufacturers to collaborate. This led to the decision to establish the Academy Software Foundation (ASWF) as a sub-foundation of the Linux Foundation, providing a structured environment for professional open-source development, ensuring projects wouldn’t collapse when individual contributors moved on.
Since its formation, the ASWF has expanded from the original three projects to 14, all of which are now active and well-maintained. One key advantage of the foundation is its legal framework, which allows competing companies to collaborate on these projects without concerns about antitrust issues. This neutral, legally protected space enables a higher level of cooperation than a three friends developing together – competing companies need to have a neutral space to collaborate.

DP: How do you support developers looking to contribute?
Jean-Francois Panisset: The ASWF offers a range of resources to support project development. We provide collaboration tools like a paid Slack instance, Zoom, and scheduling platforms to keep teams connected. Our GitHub organization is at the enterprise level, giving projects higher build-time limits, and we also have technical support through the Linux Foundation’s release engineering team for any GitHub issues.
We cover paid infrastructure like Docker Hub to avoid throttling on container pulls and offer more powerful build systems for projects that need extra memory or CPU, like OpenVDB. Projects with GPU-enabled test suites can also access paid GPU runners, which aren‘t available for free on GitHub. While development still follows the open-source model, working publicly on GitHub, these resources help avoid roadblocks and make the process smoother. The way you develop software within ASWF is really still the open source way – you get access to all these extra features that just facilitate the development process and mean you don‘t get blocked because “oh we don‘t have access to this”.

DP: Let‘s say I found a bug in one of your projects and I want to file a report or maybe I even have a fix. Usually it can be quite daunting to approach a project. I think you have some on-boarding process?
Jean-Francois Panisset: It varies by project, but most follow a standard process since they’re all GitHub-based. If you find a bug, the first step is to create a GitHub issue. All projects monitor these, and their technical steering committees review and prioritize new issues. If you also know how to fix it, submitting a pull request (PR) is encouraged. Some projects require signing a Contributor License Agreement (CLA), which assigns ownership of the code to the project, preventing IP disputes. The Linux Foundation provides an easy process for this. Individual developers sign an ICLA, while companies can sign a corporate CLA, allowing their employees to contribute without additional approvals. Though it may seem like legal paperwork, it can simplify contributions, especially from large organizations.
Other projects have a simpler process, requiring a Developer Certificate of Origin (DCO), where you certify that you wrote the code. Before submitting a PR, it‘s always good to engage with the project to confirm how they‘d like it implemented. Even if a PR needs adjustments, the steering committees ensure that issues and contributions are addressed.

DP: What if we’ve made a larger change, like customizing a library, and want to start small before submitting the bigger contribution?
Jean-Francois Panisset: The concept of a “good first issue” is key to project maturity. Projects are encouraged to flag these issues to attract new developers. While some projects require domain-specific knowledge—like contributing to OpenColorIO’s colour transform engine, which is suited for colour scientists—there are still many contributions that don‘t require specialized expertise. By tagging beginner-friendly tasks, newcomers can browse the backlog, find something they can tackle, and submit a pull request.
Last year, we introduced “Dev Days,” a 48-hour event, similar to a hackathon, where developers can get real-time help with setting up their environment or validating their approach. It’s a great way to onboard new contributors. Facilities are also participating by encouraging their engineers to work on open-source projects. This helps studios prevent knowledge loss — especially when only one developer knows certain systems like OpenEXR — by getting more developers familiar with key projects.
There‘s a tool called Clotributor, developed by the Cloud Native Computing Foundation (CNCF), that aggregates “good first issues” across multiple projects. You can search for projects you‘re interested in, and it will suggest issues flagged for beginners. It‘s not limited to ASWF; several foundations use it. Some projects have received PRs from developers outside their field who found the issues interesting. It‘s in every project‘s best interest to attract new contributors, even if it‘s just for a one-off fix — you‘re still better off than before.

DP: The list of projects on your umbrella is pretty impressive and every artist in the industry is using them actively. What‘s the rationale for the organizations behind the projects to open source their technology in the first place?
Jean-Francois Panisset: So, obviously, I don‘t speak for any of those organizations, but there‘s multiple motivations. The first one is: don‘t underestimate people wanting to do the right thing, and realizing that in our industry being able to collaborate is important. Maybe there‘s that, but also almost a business reason, because today there‘s very few projects that are done at only one facility. So, if I as a facility have this great proprietary data format that no one else know, that‘s not really helpful. How am I going to exchange data with other facilities? So open sourcing my component and “hoping” it becomes the de facto industry standard is great because I don‘t have to rewrite all my internal software.
Also, I don‘t have to carry a hundred percent of the burden of maintaining that software, because other facilities have an incentive to help develop and maintain that software. That‘s partly why the list of projects in ASWF are interchange formats – which are handling how you move data around between projects and departments and facilities and vendors. There‘s also the idea that I would love software vendors to support that format – and the way to do that is to make sure that my format becomes a de facto standard and the implementation becomes the de facto implementation.

Also if they can easily adopt the implementation into their software, it becomes more likely – who wants extra work, right? And in turn this would attract and retain software development talent – which is always a challenge and providing the opportunity for your engineers to not just “work internally” but also to contribute to a greater community will demonstrate their value to the community. And that‘s good for the company in the long term, because you‘ll have happier engineers who will be more productive.

Because, as an engineer, if you‘re exposed to not just the way things are done in your company but the way things are done elsewhere,you learn more and you become better at what you do. Open Sourcing as a way to make your engineers more productive and attract talent. I wouldn’t want to work where all the work is just internal – and with an Open Source Development, you will show the fact that you‘re not just a great studio that makes great visual effects, but you also have a great technical culture. There‘s no better way to advertise to professionals that than through open sourcing some of your internal technologies.

The post How to Persuade Competing VFX Studios to Cooperate first appeared on DIGITAL PRODUCTION and was written by Gottfried Hofmann.