When your shot breakdowns live in spreadsheets and your supervisors spend more time data wrangling than supervising, something’s broken. Jindrich Cervenka, lead developer at PFX, decided to fix it. The result? The Crossbow VFX pipeline tool: a project management and review tool aimed at automating the grind, integrating with platforms like Ftrack, and keeping productions in context, whether you’re running dailies or fighting through last-minute chaos. We asked Jindrich what Crossbow actually shoots, how it’s built, and whether it really makes life better for VFX and animation teams.

DP: What’s the story behind Crossbow and what exactly does it shoot?

Jindrich Cervenka: What exactly does it shoot? That’s the question. Let’s just say there are quite a few arrows, but what matters most is that they hit the target. The initial idea came from bidding and project planning before anything goes into production. Back then, supervisors would collect or enter shot information into spreadsheets and look up shots in the editing timeline. It was a manual, tedious process where they spent more time hunting data than actually supervising. When the edit changed, comparing everything manually became a nightmare. So the first goal was to make that process simpler, more pleasant. That first “arrow” was the project breakdown.

The second idea was about eliminating duplicated tasks across different departments and making their handoff smoother. For example, you do a shot breakdown based on an edit, probably splitting it into the shots you’ll be working on. You place markers to clarify things with the director or producers. At the same time, you start preparing an online workspace where you’ll view the shots in context and update them continuously. That means you’re effectively cutting the film twice. Online has to be frame-accurate, while the breakdown can afford a frame or two of imprecision. Different types of work, different precision and so, why even pass shots around?

Meanwhile, someone prepares artist tasks based on the breakdown by importing it into a project management system (in our case, Ftrack) or worse, recreates it manually. In online, you’re constantly checking whether the shots are trimmed properly, whether the versions are correct. Then during dailies, you’re jumping around trying to find who made which comment. It can be quite frustrating, time-consuming and error-prone with many people involved and several departments.

So Crossbow shoots arrows into systems like online, Ftrack and others and it can also receive data back from them. The goal was never to replace existing platforms, but to simplify communication, speed up workflows, improve precision, and make handoffs easier. Within the app, you’re constantly building the project and shooting arrows where needed. No need to worry about workflows or multiple logins. Fewer meetings, more clarity. You just simply shoot arrows.

DP: What kind of productions are you building this tool for?

Jindrich Cervenka: It can be used for any audiovisual work, animated projects, films, music videos, etc. It keeps you in context and helps you quickly orient yourself. The benefits really shine on bigger projects, say, 100+ shots with varying complexity.

Our primary users are supervisors, team leads and coordinators. But when I think about it, it would also make life easier for independent freelancers. The app is designed primarily for internal use, but we are discussing a version that could be released publicly.

DP: Four years of development – that’s either a well-funded software odyssey or a very committed side hustle. What’s the tech stack under the hood?

Jindrich Cervenka: Let’s say someone wanted to make their life easier. The app runs standalone on any machine with an SSD and a mid-range GPU. Everything created in the app is stored within the project and can be fired off as an arrow to third-party systems. It doesn’t rely on any other software to work.

Surprisingly, the core isn’t Python, it’s built with Electron and NodeJS. For I/O, it uses custom C++ plugins wrapping existing libraries like OpenImageIO and FFmpeg. Thanks to Electron, it’s highly modular and the UI is very responsive with virtually unlimited flexibility. It runs smoothly. Whether a new feature gets added depends on how well it fits into the ecosystem we work in. But users can also write their own custom scripts if they’re up for it.

DP: How do you actually enter a bid into Crossbow?

Jindrich Cervenka: First, I want to separate two concepts: Ballpark and Bidding. For us, these are two different terms. A ballpark estimate is based on the script and happens far in advance. Actual bidding only begins once we receive video material. Until then, everything is just an approximation and that doesn’t go into Crossbow.

The starting point is having a rough cut. Ideally, we receive EDL, XML, or OTIO files from the client – those can be imported directly. Then you start marking shots, creating assets, adding tags, writing or drawing notes, and uploading references.

There are tools for cut detection, and even AI to detect shot names if they’re burned into the video. That AI can be used during edit updates to help match finished bids with new video inputs even when clip names don’t match. You can tag shots or link them to assets and bid based on their context. Then you can do local adjustments. You can bid either in absolute mandays or per second. You can also create shot playlists and batch-edit them dynamically.

DP: What factors are considered when calculating the bid?

Jindrich Cervenka: The app doesn’t know how packed our studio schedule is. It just produces a breakdown. That breakdown gets reviewed by the Head of Studio. Booking is handled by other tools. And those people don’t need visuals, just an Excel sheet with numbers.

DP: Does Crossbow understand the production context of a show?

Jindrich Cervenka: You can change statuses and attributes of every task in the app. It can also connect to multiple systems at once. So if we’re working with two vendors, and we’ve agreed to share access to their ShotGrid or Ftrack, the integration can happen simultaneously. We can see their tasks and attributes in context with ours including comments.

For example, on a recent animated film, we had linked Ftrack instances: each studio worked on a different part of the film or exchanged animation that we rendered. Thanks to this, we could watch the entire film in the latest version from both companies without ever exchanging actual files. This was especially important for animators to stay in sync in terms of continuity and style. And it’s all on-demand. You just click “Update,” and it happens.

DP: How flexible is the final number?

Jindrich Cervenka: Great question! But no, the app doesn’t care about the client, only the project. It gives you the output and statistics. What you do with that is up to you.

DP: Will others ever get to try Crossbow?

Jindrich Cervenka: That’s currently under internal discussion. I can’t share any details yet.

DP: Walk us through a typical day in Crossbow – who logs in first and who gets to ignore it the longest?

Jindrich Cervenka: Usually, the first ones to log in are lead artists and supervisors. Crossbow often stays open all day, sometimes for several days, unless an app update forces a restart. Each user sets up their own filter, just like in Ftrack, and focuses only on what matters to them: assigned artists, specific tasks, statuses, deadlines, etc.

During active production, Crossbow primarily serves as a review tool. Supervisors can browse shots directly in the timeline, without switching between tools. For example, they can open 10 shots in a grid, play them back simultaneously, and comment either individually or in bulk. We often use it during client calls, set up a board of shots, add notes, and quickly navigate between different parts of the film.

You can time comments directly in the video and export them as clear reference frames or previews, which the client can receive almost immediately. Everything is designed for smooth, real-time information flow.

For artists, Crossbow is mainly a feedback source, they see all notes under their assigned tasks directly in Ftrack. The same goes for production: any comments or changes created in Crossbow are automatically synced to Ftrack. So the production team doesn’t even need to open Crossbow unless they want to.

But if they do, they’ll find tools that go far beyond task lists, project status reports, visualizations, aggregated stats, planning tools. Crossbow combines data, visuals and production context in one environment. It’s less about day-to-day operations and more about making production decisions and having live discussions with full visual context.

Just three years ago, before Crossbow was ready, we often spent hours on calls with directors just to clarify intentions across the film. Today, that process is much quicker and clearer because we can jump straight into scenes and shots, without long prep. Everything can be published to Ftrack right away.

It’s an incredibly flexible tool that significantly speeds up communication, decision-making, and project orientation.

DP: Real-time two-way bridge with Ftrack – so does that mean no more copy-pasting of shot status into emails?

Jindrich Cervenka: Exactly. Crossbow has real-time, two-way integration with Ftrack. Any change in shot status, version or task update is synced instantly, no manual copy-pasting needed.

The only exception is notes: you can have private notes inside the app, while choosing when and what to publish to artists. This way, you can refine or expand them before pushing them live. Those are published manually when the user decides.

Aside from that, everything related to tasks is synchronized – comments, statuses, asset versions, preview media, and metadata. Crossbow intentionally doesn’t handle higher-level production features, like multi-project overviews, that’s Ftrack’s job. Crossbow is focused on detailed work inside a single project.

Within a project, users can open any version of any shot or asset. In the timeline, they choose what they want displayed, the default is the latest version with an attached EXR or video preview, but all earlier versions are accessible. So work history and feedback are always easy to track.

At PFX, we version every publish, even ones not meant for review, like standalone animation caches. What gets used for previews or client deliveries is then defined by the pipeline. Crossbow isn’t a pipeline tool, it’s a visual and organizational layer on top of what the pipeline prepares.

DP: You mentioned that during dailies, people keep sending in shots until the very last minute, sometimes mid-session. That sounds… chaotic. Crossbow handles this without caching?

Jindrich Cervenka: Production can definitely get chaotic especially near deadlines. But if you know how to handle it, that chaos becomes controlled momentum.

We used to work in Resolve or Hiero, where shots had to be prepped in advance, pulled into the timeline, aligned, transformed, cached, version-checked. For larger dailies with 40–60 shots, that could mean 2–3 hours of prep the night before or even right before the session. And even then, we often screened the wrong version, or missed shots due to time pressure. I’d frequently leave dailies frustrated by what we’d just watched.

Crossbow completely automates that process. You can update the full timeline or just a selection with a single click, and the app will automatically insert the latest outputs from the relevant tasks. For example, if you’re only interested in animation, slap comps or comps, you set your filter and run the “insert latest versions” command. Crossbow finds the latest publishes for those categories and adds them to playback. In the background, it analyzes and optimizes the data. The whole process takes just a few seconds.

Technically, there’s no magic involved. Crossbow is built on reliable open-source components and merges them into a robust, responsive UI. The app’s philosophy is simple: speed and continuity without timeline limits. EXR playback is available, but we typically use high-quality H.264 previews, usually 4K at 40 Mbps. From experience, that’s good enough for 90% of production needs. The remaining 10% where pixel-perfect quality matters is handled by the QC team with differential keying.

So creative reviews run smoothly and without delay. And when quality matters, you can switch to EXR, zoom into pixel level, and adjust exposure, gamma, and more. Thanks to this, dailies are no longer “events” that require huge prep, they’ve become more dynamic and constructive.

DP: And what happens when you’re off the network – say on a train, in a client meeting or, worst case, in a hotel lobby with 1.5 Byte/s upload?

Jindrich Cervenka: Yes, Crossbow can work offline. When you’re on a decent connection, you simply run a timeline update, and the media is cached locally. You can then play it back without needing to connect to the studio infrastructure. That said, when you’re offline, you don’t have access to all versions of every task, only the ones that are already part of the timeline. And if you’re downloading previews from Ftrack, the image quality will naturally be lower. But you can still work with the full edit, make comments, and once you’re back online, you just publish your notes. It’s designed to let you stay productive even when disconnected.

DP: Let’s talk about crunch: Locked was running on tight deadlines, and yet you managed to coordinate with new departments and even a new director. Does Crossbow really help with that, or does it just make the panic more visible?

Jindrich Cervenka: Prioritization is a living process in every project, we reevaluate it every day based on the current situation and schedule. Personally, I don’t know the detailed status of what every single person is working on, that’s the coordinators’ job. And when production is running in parallel across multiple offices, the overall picture gets even more complicated.

Crossbow helps a lot in this regard, it immediately shows whether the artists on a sequence are creatively aligned, and lets you make a quick call to clarify what’s working and what isn’t. It speeds up brainstorming and decision-making, which is absolutely critical during high-pressure phases.

Example: imagine you’ve got 15 days left until the hard deadline, and 110 shots are still at 0%. You need to involve 10 compositors from two locations at once, and they’re working on similar shots within the same sequence. In that scenario, you either have a system that helps you prioritize quickly, catch issues and dependencies, or you spend the final 8 days in extreme stress, hoping things will work out, while still reviewing 80 shots and only then starting to finalize them. In that case, Crossbow wasn’t a panic amplifier, it was a stabilizer.

DP: After years of iteration do you still open Crossbow and go: “Why is that button there?”

Jindrich Cervenka: Absolutely. Even after four years, there are still a few buttons like that. And sometimes sneaky UI bugs show up, especially on displays with less than 2.5K resolution. I never really focused on visual styling or design. What mattered more to me was navigation and accessibility. The goal was for everything important to be no more than three clicks away. I was inspired by the simplicity of old-school Flame, no unnecessary layers, no visual clutter. I stuck to minimalism: tools shouldn’t get in the way, but they should always be within reach.

The hardest part? Teaching people how to use it. Although the app seems simple, it offers a lot of depth.

DP: Every project pushes the app forward. So what did “Locked” change about Crossbow and what’s coming in Crossbow 2.0?

Jindrich Cervenka: Locked showed us the need for a proper shot board, a space where notes can be pinned visually. The more diverse a project gets, the more you outgrow timelines, groups, lists, and tags. You want to lay things out in a visually meaningful way.

That project also led us to add retime functionality. I’m resisting turning this into a full-blown editing tool, but it’s slowly leaning that way. And of course, more AI-based functions are creeping in. So yes, we’re starting to see the outline of version 2.0 take shape.

DP: And finally: What’s the feature in Crossbow you personally use the most, the one you’d refuse to work without?

Jindrich Cervenka: It’s mostly about the speed you work with in the app. No lagging, absolute minimum waiting.

More from PFX

Crossbow Confidential: PFX’s Digital Dashboard Keeps ‘Locked’ Rolling

The Hungarian Dressmaker – by PFX

Zatopek | VFX Breakdown

The post Crossbow: Workflow Automation for VFX & Animation first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

We spoke with Tibor Meliš (VFX Supervisor) and Tomáš Srovnal (VFX and Post-production Producer) about recreating wartime Bratislava in pixels, managing crowds and chaos with procedural logic, lighting bus scenes with LED walls, and what happens when a cornfield refuses to catch fire at 5 AM. Spoiler: compositing wins.

DP: What was your initial reaction to being selected as Slovakia’s Oscar entry, and how did this impact your approach to the VFX work?
Tibor Meliš: I was very happy about it. This film was a very exciting journey, as the creative core of the production was in constant contact with us, which allowed us to fully express ourselves.

DP: Your team worked across multiple offices. How did you ensure consistency in visual quality and technical approach across such a distributed pipeline?
Tibor Meliš: Our main management tool is Ftrack, to which we have developed our own engine that drives the pace :) and brings logic and structure, while communicating with all the software we use in-house. Additionally, for leadership and supervision, we have our own internal software, which is a very important tool for daily reviews, giving feedback, and also for bidding – it’s really excellent. :)

(Comment: We are working with PFX on a seprate story for that tool – stay tuned!)

DP: How did you structure asset creation and shot tracking to maintain efficiency while meeting the film’s tight deadlines?
Tibor Meliš: Shot and asset production ran in parallel, organized by sequences. Compositors focused on the straightforward shots with no heavy dependencies while tracking and asset teams built the necessary elements in the background. We broke down environments into modular kits—facades, props, street elements—and versioned them heavily in Ftrack. Assets were linked directly to scenes, so when an updated version was dropped in, it automatically propagated. That saved us tons of time and enabled rapid iteration across sequences.
Furthermore, as I mentioned earlier, we have our own software that allows us to track shot continuity with excellent quality and near-instant response. That means when an artist changes something for review, it appears on the timeline within a second, and we can immediately compare multiple shots or versions.

DP: PFX is known for supporting productions that utilize tax incentives. Did this play a role in The Hungarian Dressmaker?
Tomáš Srovnal: We generally support all projects regardless of size or method of financing. By providing services across six Central European countries, we help producers in situations where a project needs to be completed in a specific country due to local spend requirements. This was also the case for this film. However, since it was a Slovak production, finishing the project through our Slovak office was naturally the first preferred choice for multiple reasons.

DP: What lessons or innovations from this project will influence your future work at PFX?
Tibor Meliš: One of the most interesting challenges was working with LED walls for the bus sequence. The technology is amazing—it can create incredibly immersive lighting and reflections in-camera—but it also demands a shift in production thinking. Not every director or DOP is fully ready for that yet. It requires decisiveness, and often that’s at odds with the natural desire to leave options open for post.

We ran into that too, but we made the most of it. We used the LED walls to generate interactive reflections and flickering light across the actors’ faces. We built a forest scene in Unreal Engine and placed the LEDs at an angle, so they not only lit the scene but also complemented the greenscreens visible through the bus windows. That kind of real-time content and lighting interaction is something we’re definitely bringing forward into other projects, but we need to be weary of the potential issues. Sometimes a simple green screen is less costly and a better option, mostly when you are working with less experienced or prepared on-set teams.

Apart from that during this project, we really deepened our collaboration with the grading and mastering department. While we were finalizing VFX shots, the grading team was already progressing in parallel. We kept a tight feedback loop, sharing updates frequently to make sure the VFX work aligned with the DOP’s vision and the overall tone of the grade. To make the process smoother, we developed custom scripts for DaVinci Resolve that automatically synced in the latest VFX versions and allowed for batch uploading of EXRs directly to the Barrandov office. We also tested a color pipeline to synchronize our Resolve workflow with their Baselight environment, which helped maintain consistency across departments and avoid surprises in the final master.

DP: Recreating 1940s Bratislava required detailed architecture and period accuracy. How did your team approach building the digital environments, and what were the key steps in your pipeline?
Tibor Meliš: The first step was detailed research. The director already had a large collection of references from archives, covering buildings, houses, and streets. Biskupice was particularly specific because several nationalities lived there, something many Slovaks today can’t even imagine. It was a village near Bratislava (today it’s part of the city) right on the Hungarian border, so naturally there were strong Hungarian and German influences.

We created around ten types of house assets with porches (“gánok”) and carefully studied the environment, as the porches were built mainly to shade from the sun, depending on the sun’s trajectory. Since the porches were a key visual element we wanted to emphasize, we had to adapt the lighting conditions to place them correctly relative to the camera.

The material was shot after sunset, which gave a very soft light, so the cinematographer had to lower the aperture, creating a shallow depth of field. We simulated clouds to pass the sunlight intermittently, keeping the protagonist in the shade while illuminating the houses in the background as if during daytime.

In compositing, we animated the cloud movement using P_noise to make the transition between sunlit and shaded areas feel natural. This approach also helped us highlight the Church of St. Nicholas in the distance, a landmark important to Biskupice. When viewers watch the shot, their gaze naturally moves from the actress’s face toward the brightest point – the church.

DP: Crowd simulation was a significant part of the project. Which tools or techniques did you use for this, and how did you manage the interactions between digital extras and the environment?
Tibor Meliš: Crowds are one of our long-term trademarks. Thanks to previous projects, we already had a pretty extensive internal library of Houdini-based 3D agents from this exact historical period—and already animated. So for The Hungarian Dressmaker, we just adapted and extended them to fit the new sequences. That saved us a lot of time on both modeling and rigging.

DP: The fire sequence features a long, intricate shot. Could you walk us through the preparation process for this sequence, from previsualization to final compositing?
Tibor Meliš: I would start with the production plan: we intended to create a real, controlled fire that would cover a significant part of the frame. We also had the SFX team ready to create fire elements in the third plane to help us integrate everything later.

When working with fire in a realistic film, I always try to create an atmosphere on set with smoke and strong flickering light sources that we can later match in post-production. This scene was truly massive, and since it was meant to be filmed in a single take, it became even more challenging. Unfortunately, the plan to set the cornfield ablaze in the background failed. The sequence was shot around 5 AM as the sun was rising, so we had to capture what we could, and the rest was left for post-production.

DP: The fire sequence was one of the most challenging. How did your pipeline handle simulations for such long shots, and what solutions were critical for maintaining realism without compromising render times?
Tibor Meliš: We initially planned for a lot of FX team support for this shot.
When I got the first rough cut, I started developing a preliminary lookdev myself, focusing on the timing and creating the best reference for the FX team using ActionVFX footage. Since the scene’s dramaturgy involved the fire gradually growing while the camera interacted with it, this approach seemed the quickest.

After the first version, I was surprised at how well it worked. I requested an additional burning tree asset in the background from the FX team because many objects felt too static, and with so much heat buildup, there should have been turbulence affecting twigs and grass. In Nuke, I projected the cornfield and added multiple light sources parented to the light intensity of the VFX footage, integrating them into the scene. The beauty of the shot is that when you look at such a strong light source, you must also feel it in the camera — most objects were slightly desaturated and softened, and the added mist between the actors provided great integration. In the end, a significant part of the scene was built through compositing.

DP: Do you have any recommendations for VFX artists preparing similar large-scale fire scenes?
Tibor Meliš: Definitely create smoke on set and shine light through it to achieve that strong luminous component. This will make it easier for the camera to capture the atmosphere and will greatly assist in post-production, whether for masking or optical effects.

Always think ahead – you can easily blend the luminous layer later based on your CG or footage fire. Lighting on set is absolutely crucial. Nowadays, creating fire digitally isn’t difficult, but making it match real set lighting perfectly – that’s the real challenge.

DP: What role did procedural workflows play in creating wear, grime, and historical imperfections in the digital assets?
Tibor Meliš: Procedural workflows played a key role in depicting wear, dirt, and imperfections in digital assets, especially in shader creation. They enabled the automated generation of realistic effects such as chipped edges, scratches, dust, and patina, giving objects an aged and well-used appearance.

This approach significantly accelerated and streamlined the texturing process and the creation of variations, while ensuring consistency and a sufficient level of detail. The workflow involved the use of various types of noise patterns and the consideration of convex and concave shapes of the assets, which allowed for the combination and layering of materials to achieve the desired look.

DP: How did you balance “dirty realism” – the lived-in look of the city – with the polished historical aesthetics required by the story?
Tibor Meliš: On Ventúrska Street, there’s a moment when someone in a CG building gently opens a window, creating a glare into the camera. These are the little moments that bring a space to life. And if you noticed, I intentionally wrote “someone” to further enhance that feeling of life. In reality, it was just the animated window. :)

DP: The film integrates subtle details like flags, uniforms, and street decor. How were these assets designed and implemented into the final shots?
Tibor Meliš: These kinds of details—like flags, signs, posters, or other ambient decor—are crucial for immersion. We knew this period would require a lot of specific details, like the banners carried by groups of people on the street. We carefully selected what reflected the society at that time and used it as inspiration for asset creation. For example, in the opening scene on Ventúrska Street, the hustle and bustle are enhanced by a parade of children pushing baby carriages, which is also edited within the shot.

When looking down either end of the street, we had to work with the crowd to make sure it wasn’t too aggressive but complemented the parade atmosphere. Most of them were Houdini-based procedural elements that helped break the static feel of the scenes, creating natural motion and realism.

DP: Achieving historical authenticity often means working with incomplete or limited references. Do you have any tips for sourcing high-quality references for similar historical projects?
Tibor Meliš: Definitely consult the city library of the relevant city. We relied heavily on archival materials!

The Hungarian Dressmaker

Director: Iveta Grofova
Producer: Zuzana Mistríková, Ondřej Trojan
DOP: Martin Strba

PFX Team
VFX Supervisor: Tibor Meliš
VFX and Post-production Producer: Tomáš Srovnal
Grading: Tomáš Chudomel

About PFX
PFX is a full-service post-production studio operating across the Czech Republic, Slovakia, Poland, and Germany. With over 250 talented artists, they provided services to film, TV, animation, and commercial creators for well over a decade.

PFX.tv

instagram.com/pfxcompany/
facebook.com/PFXcompany/
x.com/pfxcompany
youtube.com/pfx
linkedin.com/pfx-company/
vimeo.com/pfxcompany/

The post The Hungarian Dressmaker – by PFX 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.

If you ask around, there are very few who are really completely in the cloud – and one who is here in Munich is Mihai Satmarean. He earned his VFX spurs at Trixter as Head of IT and has also worked at Dassault Systems Mindware and DevOps. You can find an up-to-date overview of his projects here: is.gd/mihai_imdb or for more information visit candr.me.

DP: Hello Mihai! Why did you develop C&R.me?
Mihai Satmarean: It was an idea I had been toying with since my early days in the studios, given the inflexibility of local data centres and many other limitations. I had been studying parallel computing and trying to understand networking and storage in a hybrid cloud/on-premises environment. And Corona accelerated all that and even made the pure cloud approach the number one priority.
I was very inspired by the technology of Bernie Kimbacher, who has published some tutorials together with AWS. The main proponent of the idea in practice was a former Trixter colleague called Adrian Corsei, who was Head of Studio at Orca at the time of the discussion and called me at some point asking about the possibility of creating a complete virtual studio.

I saw the opportunity to bring together all the previous work and ideas into a functioning PoC. So we put our heads together virtually, and within no time we had something running on AWS. It was all remote and asynchronous. Eight months later, we met in person for the first time.

There has been a trend for some time now to move as much infrastructure as possible to the cloud, especially if there is not much hardware “on-prem”. Mainly for reasons of flexibility, scalability and to avoid large upfront investments. Building infrastructure in the cloud makes it possible to link costs directly to projects and to scale the infrastructure with the project(s) with minimal upfront investment. Corona, working from home and supply chain issues have accelerated this idea, but I wouldn’t say they are the main reasons or drivers.

DP: What would that look like for an artist?
Mihai Satmarean: We can now offer better workstations – with C&R.me (The Configuration and Resources Management Engine), artists can set up their own workstations using the project management tool. It’s very different – instead of IT provisioning, configuring and handing over workstations, we now have a ‘black box API endpoint’ with coded provisioning instructions. Through some pipeline magic, our project management software, FTrack, can request workstations and return the details to the user. Teradici’s PCoIP protocol is used to connect to the remote (cloud) workstation’s screen(s). And for the artist, this means that they get an interface and “activate” a workstation and the rest is done automatically.

Artists have a local client for the protocol and can securely connect to the workstation’s PCOIP agent. The main difference for the artist is that they connect to the workstation via a remote desktop client such as Teradici rather than directly. This means that the quality of the connection, such as latency and bandwidth, has a big impact on the artist’s overall experience. This is of course easier to manage in an office environment than when the artist is working from home, but overall it gives the artist great freedom as they can access the same infrastructure both in the office and at home. In addition, the artist has full control over their machine(s) and can create, delete, wake up, shut down/restart or even switch between different machines depending on what they need them for.

DP: Has this actually been implemented or is it still in the planning phase?
Mihai Satmarean: No planning – we’re in the middle of it. It looks like this – I’ll take the last project with the Spanish Orca Studios. We started as an experiment, designed our API and built some infrastructure – amazingly, we soon had a proof of concept and launched a project. Then another and another, and we realised that we had a working design because the scalability of artists is infinite. I think we can now take on projects of any size.

There’s still a lot to do in terms of refactoring pieces of code, concepts, etc., but I think we now have an infrastructure as a service. Of course, that’s not all, we still need pipelines, artists, supervisors and other people, but the way it works today, it’s mainly DevOps and Infrastructure as Code – and with that we actually offer Infrastructure as a Service.

DP: …and someone has already done that?
Mihai Satmarean: Yes, of course. We had three projects where we did exactly that – of course in individual implementations, with Orca Studios, Nexodus and Skylite Films. For example, on “Women King”(is.gd/woman_king), Nexodus used our toolset to integrate more than 30 artists into their pipeline, all of whom were distributed – there was no central office. Another project called “Santo” by Orca Studios(is.gd/santo_orca) was realised in Spain with artists from all over Europe working on a TV series about a mysterious drug dealer. We also did other things with Orca, like “The Good Nurse”.

DP: What were the pipelines in these projects?
Mihai Satmarean: Tools were common programmes like Nuke, Maya and so on. So far we only had cloud-native studios, so not much other infrastructure. But we are currently working on a project where we connect to a small server for licences and other services.

DP: How long did the set-up time take for each project?
Mihai Satmarean: Depending on the complexity of the studio and the scope of their work, our PoC project took about half a year until we had something concrete. Currently, we could get a medium-sized studio on board as a proof of concept in less than a month.

DP: Can’t people just rent a cloud instance themselves?
Mihai Satmarean: The cloud providers are not made for “consumers” (or artists), but mainly for application and infrastructure developers. Theoretically, you can do everything yourself, but as with any DIY project, it depends on your skill level. With some of the tools we’ve developed, it’s much cheaper and quicker to involve us – or any other cloud IT expert – than to retrain yourself or your artists. We now have a combined expertise of over 100 years in IT and VFX. In other words, longer than IT has been around.

DP: If it’s a product – even a service – does it have a price?
Mihai Satmarean: We started it about two years ago, with four people working on it at least one day a week, until it became a full-time job from the first projects. As with any cloud project, the infrastructure costs are quite low at the beginning, as practically only the development costs need to be covered. Cloud providers also offer cost savings or “credits” for cloud migrations, etc. With this type of project, the costs increase with the size of the project (artists, farm, data, etc.). However, since every project is different, I can’t give a specific price for this – it depends on what you’re looking for.

DP: Assuming we bring C&R.me into a project – how long does it take before I can start working?
Mihai Satmarean: In our previous projects, we had a big migration that took about 2 months – today it would take a couple of weeks for a new start of a “Cr&Me-based studio”, not more. There are certain things that play a role – the current infrastructure in the studio, the complexity of the pipeline and where storage and libraries and licences are managed.

DP: Let’s talk about licences: What can I use besides Blender? Where will the licence servers be located and how will they communicate with the infrastructure?
Mihai Satmarean: Licences are still difficult to manage – like in traditional studios. AWS has done some good things there by making their tools available already licensed – which means Deadline is there. We run Mari, Substance, Nuke, Maya, 3DEqualiser, Houdini etc. more or less without any problems. But beware: some tools require a physical machine as a licence server, and apart from that we’ve only had problems with some Adobe products (if I remember correctly). But, from a bird’s eye view, it’s still difficult – there are regional restrictions, so the easiest way for the studio is to buy the licences – this works for rented licences too. Medium and larger studios usually already have these.

Some tools try to find the physical machine or its hardware – and that obviously doesn’t work. I don’t want to say what the problems are because the engineers have promised to fix it! But these are “man-made limitations”, not fundamental problems.

If you are a smaller studio, you may need to speak to your preferred reseller, for example Dve As(www.dveas.de) who can help you get things rolling because with most professional software suites, simply clicking the ‘buy’ button on the webshop is not enough. Another point – with the geographical restrictions – is to run certain parts via VPNs, and some tools are even “computer-bound” – in which case the artist has to do some administrative work if a change of computer is required.

DP: What are other restrictions?
Mihai Satmarean: Not many – we have frameworks to connect to other specialised cloud services. We even already have one, but we can’t talk about it publicly (yet). Over the last year we have met various providers of VFX-specific cloud tools – it depends on the type of tool/service and its maturity, but in most cases there is not much difference to on-premise installation. If specific hardware is required that comes with the service and the cloud provider does not have a solution for it, then of course not.

DP: What is needed in terms of preparation?
Mihai Satmarean: We currently rely on the Teradici PcOIP protocol, which was recently acquired by HP and renamed “HP Anywhere”, for which there are thin clients and zero clients. So far, out of 100 artists, only 2 have complained about slowness and it wasn’t even the bandwidth but the local LAN. For the artist it takes a minute to “switch on the machine” and then he or she can connect to any prepared, already running or “on demand” machine.

DP: Let’s be honest: cloud infrastructure depends on the ISP – does that even work in Germany?
Mihai Satmarean: The artist needs a decent connection, but nothing excessive and you shouldn’t be too far away from the infrastructure. Working on a thin client with a 14.4 modem from a suburb of Passau on a server in Calcutta is not so convenient – but would theoretically even be feasible (laughs).

Working on remote machines takes some time to get used to (some can handle it quickly and some just don’t like the idea and hold back). Also, some tasks require a better setup than others (modelling vs animation vs texturing etc).

Actual bandwidth also depends on screen size, for example. To give you a figure: Two 4K screens require more than one screen, and the “lowest” speed for working efficiently with two screens would be about a 1 Mbit connection. That seems low, but remember: Teradici compresses the images and only sends “updates” – for the most part. So you can get away with a lower connection. But faster is always better!

DP: But then you can’t quickly transfer the material from your computer to the cloud?
Mihai Satmarean: Your compositors deliver new film material? (Laughs) Storage is exclusively in the cloud, where we maintain two copies in different regions to back up and optimise delivery. This is because it can take more than a week to copy everything to a new region with VFX data volumes. With this approach, we could switch the entire production to another region almost instantly. And the artists hardly upload anything after the ingestion process.

DP: If this works, could you increase production more or less indefinitely?
Mihai Satmarean: Yes, you can add new artists and studios in a matter of minutes – for example, if you want to work in Nuke, you can bring a compositing specialist into the project with just a few clicks – the infrastructure behind it scales “with you”. What you don’t need costs nothing, and virtual machines are always available. And if they are not used, the virtual machines are just configuration files on a computer. For “networked productions” – as is often the case with European films – I think this is a great opportunity to reduce costs and invest the money in the most important thing – the artists.

DP: And what are the next things that will be developed for C&R.me?
Mihai Satmarean: There are a few things on the agenda – Windows machines are difficult to automate (but this is getting better with recent updates), but most of the artist machines are already running on Linux – Centos, RockyLinux, Ubuntu etc. These are easy to automate and set up. These are easy to automate and set up. GPU compute time is still relatively expensive in the cloud – not compared to buying the hardware of course, but still a factor.
When we talk about the price of hardware: Different regions don’t always have the same types and quantities of machines as well as differences in pricing. This all plays a role in choosing a region.

Think about it: It’s easy to create your own “private cloud” if you already have a data centre – either your own hardware as a private cloud that you can use like a public cloud – e.g. your “core” artist machines that always need to be running, and only during peak productions do you expand to the public cloud providers – with the ability to connect individual artists or departments at any time. I’ve seen this being useful for episodic productions and TV series. And so we are currently working on the possibility of enabling multi-cloud pivoting, i.e. switching from one cloud provider to another.

This is linked to “hybrid deployments” – you can use your on-premise hardware as a private cloud – and when production requires it, connect it to the public clouds such as AWS or Azure. We work with other cloud providers specialising in VFX – soon we’ll be able to name them (laughs). This way, you have your “baseline” and can ramp up or down as needed.

DP: And if I want to have this toolset for my own production?
Mihai Satmarean: Well, you would email me at contact@skylitetek.com – and we’ll find something interesting!

The post C&R.me – post-production in the cloud first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

We talk to Jonas Kluger, the developer who, after studying design with a focus on film and animation at the Technical University in Nuremberg, first completed an internship at Trixter. His career then began as a VFX editor at Mackevision in Stuttgart. Over the years, his career has taken him to various VFX studios, including Marvel’s “The Avengers”, “Rogue One: A Star Wars Story”, “Transformers: The Last Knight” and several seasons of “Game of Thrones”. His team even won an Emmy for the latter! He is also a board member of the Visual Effects Society (VES) of the German Section.

DP: Let’s start from the beginning: As a compositor and VFXer, what happened when you developed software just like that?
Jonas Kluger: I discovered the need for VFX asset library software early on. It was often one of my tasks to tag new elements and sort them in a meaningful way. With a focus on the technical side and a passion for the creative, I have always been a fan of smart and simple workflows supported by useful tools.

It took 3 years, a short career change into software development and countless hours of perfecting the software with many beta testers around the world to finally present my own VFX asset library software: Das Element.

DP: What is Das Element anyway?
Jonas Kluger: In a nutshell, Das Element is an asset management software. It allows you to organize and sort videos, images and image sequences based on a VFX pipeline. Organize all your assets in a logical order and quickly find what you are looking for.
You can imagine it like this: You have a lot of images, video clips or other media files. You want to organize them all in a folder structure and then be able to find them easily and clearly using keywords and categories. Proxy formats are created for this purpose for a quick preview.

Related elements are collected in so-called libraries. You can create as many of these as you like. This allows you to create a global library for the entire studio or manage elements within specific projects. Many different types of VFX elements can be sorted. These can be Practical Elements, textures, reference images, PDFs, clips from the Internet or images from the Matte Painting Department. Whatever the user wants.

The software consists of three parts: the Gallery View, the Ingest View and the Configuration. The Gallery View allows you to search for and find assets. This is where artists will spend most of their time.
The Ingest View is used to select new elements to be added to the library. The software supports the user enormously in tagging the elements quickly and easily and adding categories. The better the elements are tagged, the faster you can find what you are looking for.
The third part consists of the configuration. With the default setting, you get a great structured folder structure, naming convention and the appropriate transcoding processes. You don’t have to worry about this, it happens automatically. However, if you have special requirements and want more freedom in this process, you can make your own settings. You don’t have to use the default. The software is cross-platform compatible and therefore runs on Windows, Linux and Mac OS operating systems. For example, it is no problem if you use Linux for compositing, while the matte painting department prefers Windows and Production Mac OS.

An important feature of the software is that it works completely offline, bucking the trend towards cloud solutions. A security feature of many studios is that only selected computers are allowed to use internet access. Artists rarely have the opportunity to upload or download data to servers. Das Element therefore operates offline, which has a very positive effect on performance. Another argument in favour of this is the reduced Internet traffic. This saves a lot of CO2 emissions and is good for the environment. Many people do not realize how much energy is consumed every time a website is accessed.

DP: So it manages assets – but in theory I can also do that with folders and a file manager, can’t I?
Jonas Kluger: The big advantage that is immediately apparent when using the software is that the user immediately gets a visual overview of all available elements without having to click through folder structures on the file system. Preview formats (proxies) are generated for each element entered, allowing the content to be analysed much more quickly without having to open individual files, which are often several gigabytes in size.

It is certainly not uncommon for individuals to use a folder structure and, through habit, find their way around it over time. However, as soon as a second person joins in, it becomes difficult. A lot of time is wasted on familiarization and searching. Not an ideal situation. With a folder-only system, there is a great risk that assets will not be sorted, but simply downloaded and unzipped. Elements that would actually belong in the same category can be found in different folders. Freelancers who are new to a studio then have to ask where to find which element. This means that at least two people are involved in a search. When ingesting new elements, Das Element indicates if an element already exists. This avoids duplication.

DP: And which tools in a VFX pipeline does it talk to?
Jonas Kluger: The nice thing about element is that you can actually use it with any software. It is a stand-alone software. No plug-ins are required to work with other applications.

On the one hand, you want to search your library and import the elements found into other software. To do this, you mark the selected elements in Das Element and can now drag and drop them into the desired application. The path to the main element is always used in the background. It does not really matter whether the path is an image sequence or perhaps a project file. The software with which you want to use Das Element will recognize this.

Of course, every software has different requirements, but this has also been taken into account. Let me give you an example using image sequences: In Nuke, I can drag and drop in the selected element and the image sequence will be imported. In Flame, however, a very special formatting of this path is necessary: (filename.[1001-1002].exr). This can be set in Das Element so that it fulfils the correct requirements in this case.

The second situation is the process of entering the elements into the library software and depends heavily on the respective needs of the user. These can include anything. A simple copy from A to B, a “leave my files where they are” to complex processes such as transcoding processes on the render farm to convert everything into an OpenEXR sequence with ACEScg Colourspace using Nuke, to then sync this with another location and its server and then perhaps create an entry in FTrack or Autodesk Shotgrid (formerly Shotgun).
If you need an even more extensive configuration, you can hook into certain places in the software at any time with your own scripts (so-called hooks). This makes it possible to use the respective API of another product. This allows you to create very powerful setups.

DP: What was it about the usual asset managers that bothered you so much that you developed your own?
Jonas Kluger: Anyone who has ever looked for library software for VFX will have realised that unfortunately there is no perfect solution for the requirements of the industry. Most of them can’t handle image sequences or the OpenEXR file format.

I have often seen in various VFX studios that software developed for another industry has been adapted to the VFX workflow by hook or by crook. Countless compromises were made in the process. Alternatively, larger studios have started to build their own solutions. These are very specifically adapted to their own needs and could possibly be optimized, because in my experience they often lack the resources to employ someone full-time.
I also didn’t quite like the license model of some asset managers. Either everything is in the cloud, which is not feasible in film and advertising production for data protection reasons, or you had to install a licence manually (node-locked) on each computer. This can be super annoying if you constantly have to worry about which version is installed on which computer. That’s why it was very important to me to use a similar license model to other VFX applications. You use a license server and only floating licenses, so it doesn’t matter which computer I’m on. I can open the element anywhere. This reduces the workload for IT enormously. An RLM server is used in the background, which has now become the industry standard.

It is also important to have an open system. You should have access to all data at all times. There are no proprietary formats or encrypted databases. All assets are available at all times, and the information in the database and configuration files is also created in common formats. This ensures that you still have access to the data, even if the license expires. As a technically experienced person, you can easily open the config files with a text editor, make changes and integrate them into a version management system such as Git or Perforce.

I have gone to great lengths to make the configuration of the folder structures and the transcoding task simple and visually appealing. On the one hand, it’s really fun to create your paths with Das Element’s Path Builder, and on the other, it takes a lot of work out of using the predefined structure and only having to overwrite values for the proxy formats, for example, in individual places. Other applications often make this process too technical and time-consuming. My approach is simple and intuitive with a fun factor.

DP: And all of this is already available?
Jonas Kluger: Yes, exactly. With the help of the dynamic and visually appealing user interface and the gallery view, you can search for tags, categories or their synonyms and then simply drag and drop the elements found into the compositing software.
All elements are first added to the library using the ingest view. The auto-tagging function can be used here to automatically analyse image content and set tags.
With the out-of-the-box setting of the folder structure and proxy formats, you can set up a new library with just a few clicks. Many small details have been taken into consideration, e.g. the fact that preview images are always generated with a meaningful thumbnail or that the complete data can be moved to a new server at a later date.

You can configure the paths and transcoding processes at any time to customise everything to your own requirements. This also makes it possible to outsource the computationally intensive processes to a render farm. Any number of libraries can be created, either to organise a specific project or to share elements across different locations. The software works as a cross-platform and can be used on Linux, Windows and Mac OS operating systems.

There are a series of video tutorials on YouTube to help you get started with element and quickly learn and find your way around the software. They can also provide an insight into previously unused features.

DP: What can it do so far?
Jonas Kluger: With many filter options such as resolution or media format, you can quickly find what you are looking for. However, the software goes one step further. For each element there is information such as the original colour space and also the original path where the file was once located when it was added to the library.

I would like to mention a few less obvious features that have proved to be important over many years of working with asset libraries. A lot of emphasis is placed on productive day-to-day work. For each library, a field called “Library Root” is used to define where the actual data is located. The big advantage of this is that you can move the entire folder, e.g. to a new network storage location if you purchase a new server or want to copy the elements to another company location. A simple adjustment of this root directory is sufficient and all data is directly re-linked and found. This scenario happens more often than you might think, which is why element can handle it. In addition, a library can be used with different operating systems, as only the root path needs to be adapted.
The predefined naming convention and folder structure is a compromise between readability for the user on the file system and a long-lasting structure that allows you to change the category of an element at a later date without causing problems. There is nothing more annoying than opening old project files only to realize that a file no longer exists and you first have to find out where this file is now located or whether it has been renamed. With Das Element, a lot is solved via the database. This avoids such problems.

In addition, when new elements are added, it is also directly documented when which files with which tags were added. This is a simple CSV file that is saved with each ingest. On the one hand, this makes it possible to restore the status of the list at ingest with all tags and categories at any time. On the other hand, this is a good way to directly perform a batch import of many files. This history of imports is important for larger productions such as Fox Studios or Disney, which require such documentation. This kills several birds with one stone.

The software makes it possible to work with Python hook files. This means that tags are generated directly from the file name, metadata or other sources when importing elements. These can be specific keywords in the folder structure or file names, which are then generated directly during ingest.

DP: Can it be placed as a layer over existing structures?
Jonas Kluger: Absolutely! If there is an existing structure, it can be used without any problems. The naming convention, folder structure and all transcoding tasks are freely configurable. Scripts or other pipeline connections can also be adopted and reused. Existing tags and categories can also be imported.

For example, a VFX studio from Canada had already created an existing library including a category hierarchy tree in the XNView software. With a small script, all tags and the hierarchy tree could be customised directly. This made the move to element very smooth. The batch import was made possible with the aforementioned CSV files.

The minimum basic requirement of the software is that there are thumbnails for each element. All information is stored in a database so that you can work more effectively. For videos and image sequences, it is recommended to render a filmstrip. The entire clip is reduced to a length of around 24 frames. If you move the mouse over the preview, you can get a quick impression of the content of the sequence. This scrubbing feature is very helpful in the gallery view. That’s all you need.

DP: What exactly happens when new elements are added?
Jonas Kluger: A central function of the software is the ingesting of new elements. With the ingest view, you can easily add new elements to the already explained folder structure. With its extensive yet user-friendly user interface, element offers maximum control for tagging files.

Firstly, all elements are simply dragged and dropped into the ingest view of the software. A preview is created in each case so that you are visually supported during the subsequent tagging process. You assign a category to each element and can then assign tags as required.
Each new element goes through a series of transcoding steps that generate different preview formats. The software offers useful presets for thumbnail and proxy videos as well as film strips.

Existing in-house scripts can be used by running a custom command as a transcoding task. This means that you can also send everything to the render farm as a nuke job. The software offers various example scripts and you can download the latest version from a Git repository.

DP: What can be imported? And how much of it?
Jonas Kluger: The current main focus of Das Element on VFX and animation elements. This also covers a large proportion of the elements that can be obtained from various resources, whether from the customer or from a web shop.

The software processes various image formats and codecs. Whether videos from a DJI drone, clips from YouTube, Photoshop files, PDFs, HDRs or JPEG, TIFF, EXR or DPX sequences. All this and much more is possible. If you have older files such as Cineon (CIN), you can also manage them. The handling of camera raw formats such as ArriRaw and REDRaw is still limited at the moment. I would generally recommend developing and converting the files using the camera manufacturer’s software before adding them to a library. As soon as an EXR sequence has been rendered, for example, Das Element can then handle it perfectly.

How many elements can be imported depends entirely on the storage space on the company’s server. For the productive operation of larger libraries (I am talking about a few thousand elements here), it is recommended to use the PostGres database. This allows you to make several thousand requests per second. The database should therefore not be a bottleneck.

Due to the way the software is optimized in the background, a request is made to the database once at startup to get the information, whereupon everything is cached locally by the user as long as the software is open. This increases performance enormously when working, as information does not have to be constantly queried via the network. All that is loaded from the server are the thumbnails and any other proxy files. These are very small and allow you to work smoothly. If additional files are to be copied, this can be automated with a separate script.

DP: Can Das Element handle other sources (Studio Three location via network or a Dropbox folder in the middle of nowhere)?
Jonas Kluger: The software can handle this perfectly. A distinction is made internally between the high-res data and the preview files and metadata stored in the database. The database must be accessible for all participants. Where the preview files are located is not important for the software as long as the path is stored in the database. Whether the preview files are located on the server, in a shared folder that is automatically synchronized via the cloud (Dropbox, Google Drive or Microsoft OneDrive) or on a web server is simply a question of personal configuration.
One use case for the current home office situation is that an artist has a compressed library at home with only proxy files and a local database file or a database within the company that can be accessed via VPN.

Using the preview files, you can search through the elements and even try out proxy videos in the compositing software. The high-resolution data can then be requested from the company using the name of an element.

Alternatively, Das Elements can be stored on the company’s internal web server and users can access the thumbnails. In this way, the information can also be shared with multiple locations. If the high-res data is not available at one location, you can create a transcoding task that synchronizes everything to that location.

DP: And where do I define tags?
Jonas Kluger: Tags can be created at will, either when ingesting or editing an existing element. As soon as you start typing in the tags input field, all similar existing tags appear. There is an option to take an existing value or create a new tag. This prevents duplication of tags and unnecessary cluttering of the system.
Categories can also be added or customized as required, as can synonyms. For tags that are likely to occur frequently, it is worth creating a separate category or using it as a synonym for an existing category.

How the tags are used can be determined very individually by a company. For example, it can be a project name or manufacturer of elements, but also a descriptive text such as “original plate” or “keyed element”. The design is completely free and left to the company or user. The only important thing is that an artist ultimately finds what they are looking for.

DP: To what extent are the tags customizable? Or can I customize the tags from other sources (spelling lists, metadata, etc.)?
Jonas Kluger: It is possible to have tags filled with a Python hook file directly when loading files into the ingest list. The file receives all paths that have been dragged and dropped onto the software, for example. You have the option of extracting information from the metadata of a file and, for example, generating a new tag with the focal length for this element. If a tag does not yet exist in the database, it is created automatically.

A fully functioning proof of concept was even created for a film team. The VFX team had the requirement to sort all elements for VFX directly on the film set after the shooting day. They proceeded as follows: There were different photo cameras for HDR shots, reference material or turntables of assets. The respective memory cards were copied to a predefined folder structure on a local network storage device on set. This was simply quicker and could be done by many people at the same time. The whole folder from one tag was then dragged onto Das Element, and the tags were all automatically created from the folder names. Now you just had to click on “Ingest” to create the thumbnails and enter all the information into the database.

The big advantage is that you can search for an asset name at any time and instantly find what was ever shot for that asset, regardless of the day of the shoot. If it is important which day the material was shot, this could be easily filtered out by adding the date.

DP: But how can I make sure that the artists find what they are looking for and don’t have to spend a long time searching for the right day?
Jonas Kluger: The software comes with a well thought-out arrangement of categories in a hierarchical structure. A lot of time, energy and brainpower has gone into this. Users benefit from this well thought-out system.

Let’s take a look at an example of a torch element. As everyone probably has a rough idea of what element they are looking for, you can simply select the main category. In our case, “Fire”. The search can now be further refined using the hierarchy view. You might next select the “Flames” category, where you can directly see which elements are available in the respective subcategories. The search then continues to the “Torch” category, and here you will find what you are looking for without even knowing which tags were used during the search process.

The beauty of the VFX industry is that we come together from all parts of the world. With that in mind, Das Element focuses on finding a common vocabulary that unites all of our languages. The software uses descriptions and synonyms for each category from publicly available sources.

Wikidata IDs play an important role here. Behind every Wikipedia page is a specific Wikidata entry. The advantages of using data from this publicly accessible knowledge base are descriptive texts, synonyms and translations in different languages.
Since each category can be linked to an exact Wikidata page, we can standardize a common understanding and vocabulary of what a particular category is called. No matter where you come from or what language you speak, this approach should make it easier to find the perfect element.

For example, the categories “fume” (smoke) and “wisp of smoke” (cigarette smoke) are often confused. This is where the machine learning model helps, because it can analys exactly how these two categories differ visually.

DP: But I can then use the tags in the search, or can you find more uses for them?
Jonas Kluger: You have to differentiate between categories, tags and a third type, the wildcards. The idea of tags is that you can use them in numerous ways to describe an element as precisely as possible. Categories, on the other hand, are there to give a name to a specific grouping of elements. A category is therefore something more permanent.

For example, you can include the category name or a category ID in the file or folder name in order to recognize exactly what it is on the file system. Whether an element can be seen on the left or right of the image is more likely to be clarified via a tag. If the image is mirrored or rotated in the software, this parameter would otherwise no longer be correct if it had been written in the file name.
The third type, wildcards, are placeholders for parameters that are dependent on the individual elements. The software analyses each element carefully before it is entered. Values such as the resolution or file format, the first and last frame for image sequences and the codec or frame rate for videos are entered. These are also values that can be used to describe the element.

They can be filtered in the gallery view, for example to search for the minimum length of an element. These element-dependent parameters can be used in the settings and the naming convention to act as a kind of placeholder. They are also called wildcards.
As we only know the resolution of an element when we ingest it, we need these placeholders to define our folder name structure in advance. The actual parameters only become known during ingestion, the wildcard is resolved and replaced with the correct values. This is how the final file path is created.

As a user, I have access to a wide variety of values here, which can be helpful. If you want to execute a user-defined command line command, these wildcards are extremely helpful and can be used to pass on various values to other scripts or programs.

DP: So Das Element sorts all my Studio assets and makes them searchable with tags. But how does it decide which keyword is suitable for which file?
Jonas Kluger: The data can be analyzed by users using auto tagging before it is ingested in order to find the best possible tags and tag them automatically. This works with a machine learning model from Das Element that has been specially trained with thousands of VFX elements.
Most services on the market that offer AI use a model type in the background that is based on a very specific data set of images. This is usually the ImageNet Challenge; a collection of countless images divided into 1,000 categories. This is a benchmark training set that can be used to compare how well a type of neural network performs. The advantage lies in the large number of categories with everyday objects, animals or similar. However, if you search for a specific word, e.g. “fire”, you only get a few suitable categories, such as fire grate for a fireplace or campfire, a fire boat or fire engine and the fire salamander. Of course, this is not particularly helpful for professional work with visual effects.

That’s why I decided to create my own training data set. I have been continuously expanding this collection for 3 years now. I have bought all kinds of element libraries that can be found on the Internet and feed them into the training set. One major difficulty, however, is finding enough data points, i.e. images or videos. For the search terms “fire”, “flame” etc. you get countless material. For footage of nuclear explosions on a black background or VFX portal effects, it is more difficult to find enough different image material. For classification with machine learning, you need a different and varied selection for a category so that you can easily differentiate it from an obvious other category.
If I can’t find enough elements for a category on the Internet, then I take a few photos of glowing coals at a family barbecue, or if I notice a container on the street with rubble and debris that are nicely arranged from the perspective of a VFX artist, I take out my mobile phone to constantly expand the data set. All images and videos are sorted and tagged by hand to achieve the best possible result. A machine learning model, a convolutional neural network, is then trained and passed to the users of the software.

As soon as elements are added to the library, a second machine learning model is trained in the background. This model is based on existing elements in the library. The more elements are added, the better it gets. In the ingest view, you receive suggestions as to which category it could probably be. The idea is to develop an independent model that can be trained on any category as long as there are enough training samples. As the library grows, the model becomes more accurate.

DP: And if I have assets that are not recognizable in your sorting?
Jonas Kluger: The auto-tagging feature can be a great help with many elements. However, I still recommend a manual check to add further keywords that the model does not yet recognize, for example, and to add further characteristics such as speed or size. These characteristics can be rather subjective under certain circumstances.

The technology used for machine learning models is comparatively new, although the theory behind it has been around for a very long time. It can happen that the model either does not recognize a category and therefore does not enter a value, or it mistakenly thinks that it is some random other category. In this case, however, the user quickly realises that the tag supplied makes no sense and removes it. Of course, you can always edit the existing library in the gallery view if you notice something that is incorrectly tagged during a search.
It is recommended that you always briefly double-check each element, regardless of auto-tagging. Every element should be tagged correctly at least once before it is added to the library. After all, that’s what the input process is for.

DP: Where will Das Element go from here?
Jonas Kluger: In order to make the software even more accessible from the outside, a Python API is to be added. This has been put on the back burner for various reasons. I am curious to see how the whole topic of Python 3 will develop in the VFX industry.

There are also plans to set up a marketplace where you can search not only your own elements, but also all libraries from element providers on the Internet. This makes it possible to buy individual elements, add them automatically and thus expand your own library with elements that are needed for the current task.

A web view of the software is also conceivable for the future, so that you can log in via a browser. Perhaps even a cloud solution for freelancers so that they always have online access to all the references they have ever collected.

DP: What other features are available?
Jonas Kluger: We are planning some tidying up in the background, a kind of spring-cleaning for the software. Stability is much more important to me than lots of new features that don’t really work. A library is a long-lasting thing that should exist and function for years. When I talk to users, they often still have files from the last millennium in PAL that are still in use.
One particular innovation that is on the immediate to-do list is an improvement to the rating and voting system for elements, which analyses the most popular elements in the background. In addition, the option is to be created to rate elements of poor quality so that they slide further into the background. A few users have requested this change and I would like to fulfil this request.

A playlist system will be introduced to strengthen team collaboration. This means that a team lead can put together a collection of suitable elements in advance and distribute them to all artists in a kind of playlist. This means that not everyone has to search through various libraries individually, but already has, for example, the top 20 fire elements that are suitable for a sequence or setting. The playlist system can save an enormous amount of time and promotes collaboration within the team.
Other file formats such as project files or setups for Nuke or After Effects will also be supported. These can also be very helpful if you want to reuse a rain or noise setup several times. The project file is ingested into the library and a preview image can then be added so that you can see at a glance what is happening in this script.

DP: What other new features are planned in the long term?
Jonas Kluger: A lot is planned and conceivable for the future. However, the community is an important decision-maker. Nobody can say which requirements are particularly important better than those who use the software on a daily basis and thus recognize and pass on useful suggestions for improvement in the course of their work. After all, the software was (or is) programmed for specific users and not for someone who has thought about something in a quiet room but can’t relate it to reality. I welcome creative suggestions and an open dialogue. OCIO (OpenColorIO) is to be integrated for better colour management.

DP: Where can you get Das Element if you want to try it out?
Jonas Kluger: If you want to find out more about Das Element and see it in action, you can make an appointment for a live demo at any time via the website. To do this, you select an available date and time from a calendar. You will then receive a confirmation email and a Zoom link.
I personally take a lot of time to present the software during the appointment and discuss all questions and use cases. If you want to try out the software straight away, you will find an e-mail address on the website where you can request a 30-day trial version. The trial version offers the full scope, you can test the software extensively and learn to love it. If you have any other questions or suggestions, please do not hesitate to contact me. I am very interested in optimizing Das Element for everyone.

The post Element-ary Asset Management first appeared on DIGITAL PRODUCTION and was written by Jonas Kluger.