Creatures made of tree branches and roots seem to have a firm place in the history of
VFX. Just think of Treebeard in The Lord of the Rings, Guillermo del Toro’s Pinoccio, Groot or the creature in Seven Minutes Past Midnight. In this tradition we created woodland – an animated short film that we produced under the direction of Prof. Jürgen Schopper in the VFX programme at the HFF. Even though our forest creature may look rather frail next to many of his wooden colleagues, he more than makes up for it with his musical talent.

In search of ideas

Even before active story development began in October 2023, our team had come together. Woodland is the result of the creative work of Jim Obmann, Emil Pogolski and Vanessa Chu. We wanted to create a film in a fantastic, surreal environment, far removed from the world we know. For months we played through different scenarios, wrote countless script drafts and created concepts of fantasy creatures and environments. Our ideas took us from the deep sea to the highest mountain peaks, caves, abandoned cities and desert planets. In these Lived whales, golems, basilisks and other fantasy creatures – including a “moon calf”, which played the leading role. Among these figures was a rough sketch of a gnarled forest creature playing a flute… However, in view of the countless options, we didn’t immediately recognise the potential of this character.

Although the settings and characters of our designs were very different, there were fortunately
also many similarities: Survival in a desolate world, a melancholic, sometimes gloomy mood, the contrast of light and shadow, the magical effect of the music – all of these elements appeared again and again. In the end, we were able to agree on a final film plot that united these motifs. The old forest creature reappeared as the main character. In months of work
Woodland took shape in this way: The story of a wooden creature, who, as the protector of nature, must save his forest from endless darkness. His only hope: a fragile flower flute. For only the music of this flute can dispel the clouds that block out the life-giving sunlight.

From text to image

It all began with a spontaneous pencil sketch. The bent, asymmetrical posture of the drawn figure, as well as her melancholy expression. Numerous digital drawings followed, which refined the design more precisely. The aim was to develop a clear design language without sacrificing seemingly natural elements. The aim was to find a balance between heaviness and fragility. This is why the final Concept Pieces of bark layered like scales on the head and torso alternate with flexible root strands that form the creature’s arms, neck and stomach.

Vanessa Chu and Jim Obmann designed the concept of the “flower flute” according to a similar principle: the wafer-thin petals are arranged in a spiral around the stem which functions as a sound box. In order to play the flute, the petals have to be pressed shut so that the knotholes in the stem of the flute are covered – similar to the keys of a clarinet. This allowed us to combine an interesting design with functionality.

Storyboard & previsualisation

Prof Michael Coldewey and Dr Rodolfo Anes Silveira supported us in creating the storyboard. We created pencil drawings for each shot, which we cut out and rearranged again and again. This gave us the opportunity to play with different editing variations. We drew the final version digitally. Here we fine-tuned the Composition and an initial colour script that would later help us with the lighting.

Before we started with the 3D previs, we decided to take an additional step as preparation: we filmed a “real film version” in the Ebersberg forest. Our storyboard served as a template. By filming with a real camera, we got a very good idea of which pans and movements were realistic. In doing so we moved more in the direction of more static camera work, away from the often unrealistic possibilities of a 3D camera. This calmer concept lent more authenticity and clarity to the story. Storyboard and live-action film together created a stable basis for the 3D previs. A rough animation of the character and the first sound concept soon made it possible to assess the overall effect of our film and to make final changes to the pacing.

Pipeline & workflow

Jonas Kluger was always on hand to help us plan an effective workflow. He explained how to use Shotgrid and Prism software, which made Project management a lot easier. Even in the deepest jungle of linked Blender scenes, rigs, FBX files and textures, we were able to keep an overview.

A forest creature is created

The challenge now was to realise our drawn concepts in 3D. Emil Pogolski used Zbrush to sculpt the forest creature. Our character went through a series of metamorphoses until we finally succeeded in sculpturally reconstructing the expressiveness of the drawings.

In addition, the model was edited with regard to the animation. We opted for a mixture of ball joints and mouldable elements to give the character enough freedom of movement despite its sometimes rigid wooden structure. This also applies to the facial expressions: while the eyelids, nose and mouth are united in a single mesh, the eyebrows move separately from the head as a mosaic of fixed wooden panels. All of the figure’s blendshapes were created (also in Zbrush) using sculpting layers.

We built the flower flute in Blender, also using Blendshapes for the wilting of the petals. A rough reference model of the flute served as a template in Zbrush. The hands and fingers of the forest creature were adapted to the final model. This ensured that the character and asset were a good match. For the modelling of the bud from which the flute was to be modelled, we took a close look at the growth of real plants.

In the virtual forest

The most challenging task during the creation of our film was the environment. The aim was to build an ancient forest whose trees were slowly decaying from lack of light. Here, too, we attached great importance to a detailed elaboration of the tree bark, leaves, roots and undergrowth.

This task would have been almost impossible to complete using traditional modelling methods in the time we were given. As a solution, Jim developed a system of geometry nodes in Blender with which we were able to procedurally design a large number of unique trees.

Curves were used to define the basic shape of the trunk, while the leaf density, number of branches and structure of the bark could be controlled with specially created parameters.

In addition, we allowed clusters of tree fungi to grow on the bark, including procedurally variable fungal size and density.

We also had the same flexibility with the shape and thickness of the tree branches (which we could let hang down sadly if required). Depending on the layout, we distributed self-made 3D scans of rotten tree trunks, rock formations and roots in the environment. This completed the overall impression of a dark, mystical forest.

Texturing

We wanted Woodland to be a tactile, detailed film. That’s why we decided early on in favour of PBR shading with high-resolution normal and displacement maps. In Zbrush, Emil modelled larger details such as the eye wrinkles and coarse Bark structures of the character. In the next step, we projected this highpoly Model in Substance Painter onto the lowpoly mesh, which had previously been cleanly retopologised in Maya. We distributed the texel density of the lowpoly mesh over several UDIM-tiles in order to maximise the good performance of the blender scenes despite the high level of detail.

Rigging

The humanoid proportions of our character allowed us to use the Blender add-on Autorig Pro as the basis for the rig. Vanessa manually adjusted the weights to anatomical features, such as the forest creature’s flexible neck.
After a few iterations and the support of Benc Orpak, the body rig was ready. For the facial expressions, we built a control panel to quickly control the character’s 20 blendshapes quickly. This also made it easy to create combinations of several blendshapes. Jim rigged the flower flute completely by hand. Its complex rig made it possible not only to manipulate each petal individually, but also the overall shape of the flute. So the growth of the flower from a bud to a fully unfolded flute.

Performance capture

Before the shoot, we had already tried to empathise with the role of the forest creature and
possible movement sequences. It quickly became clear that Jim would be best suited as a MoCap actor. David Emmenlauer was on hand on the day of filming with valuable Advice on the day of filming. He explained how to use the Xsens suit and the associated software so that we could get the most out of Jim’s performance. We used sandbags, elastic bands and a heavy rucksack to restrict our performer’s freedom of movement. This allowed us to bring our idea of a frail forest creature even closer. The foundation for the animation was laid.

Animation

Retargeting turned out to be a challenge: the bones from the MoCap data had to be manually transferred to the final rig. The edited motion data provided an initial starting point for the long animation process that followed. Only the Blender add-on Animation Layers allowed us to bring the forest creature fully to life. We first corrected all imperfections in the MoCap data in order to edit them using manual animation. All the nuances of the flute playing, the the intricate hand movements and the expressiveness of the facial expressions were animated by Vanessa and Jim by hand. They received feedback from Melanie Beisswenger, who also taught us the theory of animation technique. Seeing how, step by step, a vivid character with convincing emotions was a fascinating experience with every new shot.

Light and shadow

Light is one of the most important elements in the story of Woodland. What mattered to us was a strong contrast between light and dark. The oppressive mood of a dying Forest was to be set against the dawning of sunlight. But how do you tell the absence of light without plunging the film plot into darkness?
We decided to solve this problem with a clear colour scheme. The dark forest is bathed in a cold blue-green colour, with a tinge of violet in the shadow areas. In contrast, warmer colours return to the forest with the sunlight – the blue-green is replaced by light ochre and orange tones. To achieve this effect, Emil used numerous area lights in Blender in combination with a volume.

This volume allowed us to create a depth effect and make the rays of sunlight visible. We also sorted all the lights into light groups so that we could adjust them later in compositing. This enabled us to visually separate the character from the environment even in the densest tangle of branches and to bring out all the details even in the dark forest.

Rendering & compositing

We decided early on to render with Cycles. This allowed us to achieve the desired Quality of all transmission, subsurface and volume effects. For the necessary flexibility in compositing, we created masks for the forest creature and its flute for each shot. Nevertheless, we struggled with rendering errors – which were eventually overcome with even more patience. The effort was worth it: the final renders lived up to our expectations. We now put all the render passes together in Nuke to create the finished overall image. Here we came a lot closer to the desired look. We increased the visual clarity the visual clarity of the shots, directing the audience’s gaze to the important image elements. In Nuke we also animated the sunlight, which we had always rendered in a separate light group.

Colour grading

Together with colourist Claudia Fuchs, we achieved the final look, corrected minor rendering errors and added grain. With a subtle radial blur at the edges of the image, we underlined the sometimes dreamlike mood of the film. This put the finishing touches to all the scenes – the work on the visual part was complete.

Wood creaking and flute music

As our film manages without any dialogue, the music plays a very special role. In Woodland, it is not just “background music”, but a fundamental part of the film’s plot. It guides the audience through all the emotional states of the forest creature: from Self-forgetfulness to sadness to hope. This music is the work of our great Composer Lukas Stipar, who, in addition to film music, writes pieces for video games and theatre plays. The sound design took place under the direction of sound engineer Stefan Möhl. The forest was now given an atmospheric sound backdrop, while the gnarled joints creak and crackle with every movement. All animations and textures suddenly seemed even more believable as the sound gave the film a whole new depth.

Retrospective

Working on our first animated film at the HFF demanded a lot of perseverance from us. It was an instructive, exciting journey to the final version with one or two unforeseen twists and turns. We spent almost a whole year in the virtual forest of Woodland, so that in the end we found it difficult to detach ourselves from our work. It always seemed just one or two opportunities for improvement. But the finished film comes closer to our expectations than we initially thought possible. Now we can look back with satisfaction on a long, successful teamwork – and are already looking forward to the next VFX project!

The team

Munich University of Television and Film presents: A film by Vanessa Chu, Jim Obmann, Emil Pogolski

Woodland

Screenplay / Modelling / Texturing / Rigging / Animation / Lighting / Compositing: Vanessa Chu, Jim Obmann, Emil Pogolski
Producer Konstantin Kunze
Composer: Lukas Stipar
Overall management: Prof. Jürgen Schopper
Project supervision: Dr Rodolfo Anes Silveira
Visual Effects Pipeline TD: Jonas Kluger
Mentor 3D Computer Animation: Berter Orpak
Production Management: Ina Mikkat
Team Assistance Production Management: Ron Sikkes
Team assistance: Petra Hereth
Assembly supervision: Prof Beatrice Babin, Prof Michael Palm, Yuval Tzafrir
Colour Grading: Claudia Fuchs
Mixing: Stefan Möhl
Postproduction Supervisor: Christoffer Kempel
Room scheduling: Beate Bialas, Sabina Kannewischer
Editing: Christine Schorr, Yuval Tzafrir
Technical support: Benedikt Geß, Florian Schneeweiß
Equipment HFF Munich: Rainer Christoph
Studio management: Peter Gottschall, Andreas Beckert
Conforming: Martin Foerster

Sirius string quartet, clarinettist Eve Georges

Thanks to our lecturers Prof. Melanie Beisswenger, Prof. Michael Coldewey, David Emmenlauer, Kathrin Hawelka, Benc Orpak, Dr Walter Stehling.

Special thanks to Edgar Bauer, Mayra Ebensen, Paula Wodniok, Silvia Loose, Franz Stöcker, Felix Zachau, Hannes Werner, Alexander Hupp, Ines Timmich, Franziska Bayer, Valentin Dittlmann

Producers Comment

When I started at the HFF, I wasn’t even aware that there were animated films in addition to documentaries and feature films that we production students were allowed to accompany as producers.

by Konstantin Kunze

In the first few weeks of my studies, however, I gradually found out that we could get this opportunity and be allowed to produce an animated film. I approached Vanessa and offered to help her and the team with the production. The offer quickly became a reality and I became part of Team JEV: Team Jim Obmann, Emil Pogolski and Vanessa Chu.
Every week we met with the other team and the lecturers from the VFX department for weekly meetings in which the film was shaped step by step. Starting with brainstorming, script development and then everything to do with the animation and completion of the film. What I’m describing here so casually and briefly was a process that took months and ultimately lasted a year. A process in which I learnt what in-depth character and story development means and what it means to track the progress of an animated film in Shotdeck, to get to know and understand general terms and the workflow of an animation project.

I can only repeat it again and again and take my hat off to Vanessa, Emil and Jim. What you three have achieved over the last year is incredible and I am deeply grateful to you for letting me go along for the ride. Your skills and abilities have made my jaw drop more than once. Seeing how you have grown together as a team and how everyone in the team has found their role based on their skills makes me proud. Proud of your work and especially proud of the three of you.

A big thank you to everyone in the VFX department for their commitment and time, and to everyone else involved, especially the production manager Ina Mikkat and her assistant and good soul in the production department, Daniel Zitzer. If there’s one important thing to take away from the last year, it’s a newfound understanding of what it means to work in VFX. Even if it was only a small insight into the big VFX world, you can now better appreciate what it really means to produce visual effects or animations and that it is not just a ‘job on the side’, as it is often seen in the film industry. Vanessa, Emil and Jim, it was a pleasure to produce this film with you, and if this is your start, then we can’t help but look forward to all the wonderful things to come from you.

The post Through the Woodlands first appeared on DIGITAL PRODUCTION and was written by HFF Hochschule für Fernsehen und Film München.

Well, the documentary „Our universe“ has a bigger scope than the west of England, but the VFX House Lux Aeterna is based there – and we got a chance to chat to VFX Supervisor Paul Silcox!

DP: To get a sense of the scope of your project, how many full CG shots did you create for the six episodes? Was there anything you didn‘t simulate?
Paul Silcox: Hi, yes, we did visualise a lot of phenomena but not everything was simulated, where possible we leaned on proceduralism in Houdini to produce the variety of FX. In the end there were nearly 400 full CG shots in the show and nearly 700 shots in total, these were produced over an 18-month period.

DP: How big was the team for this show, and what was your “primary” pipeline?
Paul Silcox: The team for Our universe varied over the production but was generally between 20 and 30. We had a very senior team working FX, Lighting and comp so we were able to deliver beautiful shots effi­ciently. In order to handle the sheer amount of active shots and the massive amounts of data utilised in the show we boosted our IT infrastructure adding 70 High-end render nodes, high bandwidth network hubs and super fast SSD storage. Managing all of this is our bespoke Shotgrid and Deadline management software.
The core of the studio‘s creative output is based around Houdini, Maya and Nuke and this is managed through Shotgrid, though we still work in C4d and After Effects for certain shots or projects. Our renderers of choice
for Our Universe were Arnold, Mantra and Redshift.

DP: Did you use different toolsets for the different shots?
Paul Silcox: Houdini was our go to creative package for a lot of phenomena and this was supported by Maya and Nuke. The power of Houdini to test ideas and play with concepts allowed us to communicate scientific stories in a variety of new and interesting ways.
Our Universe was a dream job as there were so many examples of phenomena that we had to synthesize, from the inside of the cell to the inside of the sun there was always a new creative challenge. The atomic sequences are a great example of the type of collaboration that marked the production – our CG Supervisor created a beautiful sequence visualising the interaction of atomic particles and the FX department was tasked with developing a system that could replicate the look across a variety of shots. The team developed a procedural SDF system in Houdini that was relatively light-weight and art directable and this was used to demonstrate the many atomic interactions that drive the universe.

DP: Did you add any special tools to the Houdini pipeline?
Paul Silcox: Houdini was our primary FX software though there were other packages used for simulation FX. For one sequence we handled a massive SPH dataset computed in SWIFT at Durham University on the Cosma supercomputer. The data arrived in HDF5 format and was converted to a usable format for visualisation in Houdini. We also use MASH in Maya, particles in nuke and we use After Effects with Element 3D.

DP: And then you added particles to everything?
Paul Silcox: Lux Aeterna‘s Comp team did a brilliant job of working with Houdini and Maya environments, simulations and FX and they are always adding a sprinkle of something to a shot, from volumetric lighting to new particles. Our 3D teams worked closely with comp to make sure they had everything necessary in the renders from an AOV point of view and all shots were lit and rendered in ACES colour space to the required delivery spec.

DP: How did you keep an overview of these many, sometimes rather similar shots?
Paul Silcox: Lux Aeterna used Shotgrid to manage the shot delivery and our workflows allowed for there to be a significant number of shots to be live and worked on concurrently. Production was brilliant at managing the reviews through the playlists on shotgrid and for the artists this worked very well. You‘d think that it would be easy to get confused when the differences between shots are subtle but it‘s like the penguins finding their young, once you have worked on a shot you can find it and talk about it instantly no matter how many similar versions you have worked on.

DP: Did you have to develop something from scratch for “Our Universe”?
Paul Silcox: Our Universe presented many challenges and Lux Aeterna responded in a variety of ways developing numerous new workflows, one example was our collaboration with Amazon AWS. We had used online render farms many times before but we had never needed so many hours of rendering in such a short delivery window. We worked closely with the UK and US teams to implement the AWS software and learn the intricacies of working with datacenter infrastructure to add several hundred nodes to our render capacity at peak times.

DP: And speaking of delivery, how long did you (approximately) render per frame?
Paul Silcox: Ha, how long is a piece of string? Let me just say this, there were a significant number of shots with super complex volumes, billions of voxels instanced many times, SSS shots with full frame transmission and scenes with many millions of polygons, all rendered at 4K. A lot of these shots would take 5 hours plus per frame to render all layers so the demand on the render farm was huge.

DP: In comparison to other shows like Blue Whales or 8 Days, what were the difficulties in the pipeline?
Paul Silcox: Our Universe was complex and wide ranging in its scope but the demands are always the same, more power, more storage and more bandwidth. Lux Aeterna has developed a pipeline to handle the complexities of a show like Our Universe and I was proud to see it delivered so efficiently.

DP: There were “pickup” and “inbetween shots” in almost every jump from documentary footage, animals, and the space-pictures – did you have a library for that, or did you create a shot for each?
Paul Silcox: Our artists worked particularly hard on the interstitials creating the timelapse and spatial jump effect that bridged the many sequences. We didn‘t rely on anything except the creative flair and extreme hard work by our dedicated team.

DP: I assume that some shots had “invisible Vfx” as well?
Paul Silcox: There was definitely some cleanup and augmentation as this is always the case for this type of show. Our comp team worked brilliantly to create the continuity in the show though you‘ll have to look hard to find it!

DP: How did you balance between the “Look” and the input from the scientific advisors?
Paul Silcox: Finding the balance between science and entertainment is always a journey, luckily we have experienced and senior creatives with a long history of scientific storytelling having worked on BBC Science shows like ‚Wonders of the Universe‘, ‚Wonders of Life‘ and ‚Human Universe‘, just to name a few. They brought this considerable experience to the show working closely with the showrunner Mike Davies and the brilliant Producer Directors to deliver a cinematic vision and relatable stories to the screen.

DP: What would you do differently if you started at Episode One again?
Paul Silcox: VFX is a dynamic business and so we are always looking forward not back, having said that there are always efficiencies to be found. In an ideal world I would share ALL of our knowledge with our younger selves, even if all it did was bring the render times down.

DP: And what was your favourite shot?
Paul Silcox: Of course, as the supervisor I‘m not allowed to have favourite shots ;). I would say that the first episode was fun as we were right at the beginning of our journey and discovering a look for the programme, it was a really exciting time.

DP: What are you working on now?
Paul Silcox: We are always under such strict rules when it comes to discussing live projects but what I will tell you is that as well as our unscripted slate we are very happy to be working on more scripted productions and as always we are developing new ways to tell stories and continuing to challenge our skills in environment and FX.

The post Our Universe of… Houdini? first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

by Jens Dessilla, Jhonie Aelbrecht, Jürgen Firsching

There are many reasons why catalogues, brochures and flyers no longer always go to the photographer – it is faster, better, cheaper and more flexible to create products and assets digitally. Need a quick change of perspective? No problem. But a different product? Simply swap the asset in the rendering. Colours, textures and versions? No problem – and because the VFX studios of this world have been doing exactly that for film productions for many years, tools have been developed that make exactly that possible. And here we see what something like this can look like – a discounter has ventured into the VFX pipeline – but how?

Who does that?

Pixel Nexus (pixel-nexus.com) from Ghent in Belgium is responsible for the realisation. Together with dve advanced systems (dveas.de), Jhonie Albrecht’s team offers “custom pipelines” – for CG, the integration of software and apps, the corresponding hardware and server structures as well as training, consulting, maintenance and everything else that goes with it. Jens Dessilla, project manager in the international marketing department of a discounter and responsible for the CGI asset creation, was the third member of the team for this special project.

Jhonie tells us that in recent years, catalogues, flyers and other advertising materials have made the shift to computer-generated images – and today the majority of products are already available in this form. So the content is ready – and you can learn from the experience of so-called “asset management” in film productions, which regularly juggle thousands and thousands of elements, putting them together across continents – and all in such a way that the result looks good. So why not utilise these ideas and tools?

Digital asset management

In the CG industry, this is called “digital asset management” – huge databases that manage all the aliens, orcs, spaceships and whatever else is used in the blockbusters and make them available to everyone who needs them in production. According to Jhonie, the amount of data is not a hurdle – a few thousand assets, each with a 3D model, texture and colour variants, do not cause a VFX database to break a sweat.

Familiar processes in a new guise

Jens Dessilla on the decision in favour of Shotgrid: “We quickly realised that we needed a central solution that would support us in various disciplines. One of these is monitoring & controlling. Shotgrid (SG) helps us to monitor and control the ongoing CGI productions in real time. It tracks the status of assets from start to finish, giving us the ability to track them at any time. Centralisation and the exchange of information via interfaces allows us to work more efficiently. This helps us to further scale our production volume.

This production volume can vary depending on the month and area, but in the past a higher three- to four-digit number of assets per month has proven to be realistic. This takes into account various playouts for our most important communication channels, i.e. moving image & still image assets.”

Components and extensions

You might think that since the problems and challenges of everyday life are well known, there is a solution or an extension for everything? This is not the case, and Jhonie explains why: “We start with the standard version of Shotgrid and program all extensions and every piece of additional code ourselves – because with software from the net you never know what licences are behind it. Even if it is supposedly open source and free of charge, dependencies, code snippets and individual parts may be subject to different licences.

The second reason for “doing it yourself” is also simple: if you do it yourself, you have good documentation and can customise all the components yourself, whereas external software is always difficult to maintain – and some features may work in the test, but you don’t know what’s going on in the background. And since we attach great importance to data security and the privacy of our customers, we don’t even take this risk. What’s more, we know from experience that third-party customisations for new features tend to crash, break or simply not be developed further – after a few years, you can practically do everything from scratch again.

Jens Dessilla comments: Additional software had to be written to enable the most automated exchange of information possible between our systems and SG. In the first part, we have a module that filters, records, transfers and updates the data. The second part is an extension of SG Publishing. Finally, we made various customisations within the SG environment that, for example, perform repetitive tasks or react to certain dependencies.

What language do the files speak?

But the idea goes beyond the next quarter, as Jürgen Firsching explains: “The findings from cinema, TV and advertising production go even further, for example when it comes to file formats.” While 20 years ago many things only worked on a computer and 10 years ago “only in software”, the technology behind 3D formats and asset management is now so mature that
all relevant components – from databases to individual 3D assets – can be stored in open standards.
For our customers, this means that all components will remain usable not only today, but also in ten years’ time – without having to buy licences for the models they have created themselves. With USD, GLTF and Alembic in particular, everything is now just a click away in a variety of software packages. And as the VFX industry accepts these standards and actively develops them further in productions of all sizes, these files – which are always backwards compatible – will also be available in the foreseeable future. All of these formats are also completely open and documented, meaning that project-specific extensions are not only possible but also easy to implement.

Up to the first image

Enough of the basics – how did this project come about? Jens Dessilla reports: ‘We had to go through several phases: After viewing and testing various tools on the market, we decided in favour of Shotgrid (then still called Shotgun). We carried out an internal, isolated test in our specialist department for just under a month. The aim was to test the possibilities and the functionalities included as standard. We were supported by the Autodesk Shotgun team. After successful testing, we converted the isolated test into a proof of concept (POC). In this phase, various internal processes were initiated and various sales and implementation partners were viewed and tested. Furthermore, our various pipeline processes were recorded, consolidated and then transferred step by step to Shotgrid and validated by us. In total, more than a year passed from the decision to the “first frame”.
We taught ourselves a lot during the initial tests, but we also had direct support from Autodesk. We now know how to use Shotgrid well, but we are still learning something new every day. The tool is very versatile and can quickly become complex and overwhelming in certain areas. That’s why we handle certain things ourselves to a certain extent, but leave everything beyond that to the experts.
This is also one of the bigger tasks when the pipeline is automated, as Jhonie points out: “You can say goodbye to various “classic” tasks, for example understanding what is in the final colour space and what is not is a bit of a stumbling block. The preview images generated are optimised for
optimised for the screen and fast transmission, and the colour proof only arrives once it has been predicted in the pipeline. Of course, this is just one example – and such stumbling blocks need to be recognised early on and worked around together with the employees. Just as, in this example, hopefully nobody is trying to judge print colours on uncalibrated screens of mobile devices.

“Telling the user story”

According to Jhonie, it always starts with a “user story” – a precisely defined process of what the customer wants. The employee has a file, drags and drops it somewhere, sees that a file has been uploaded and four people are notified in a certain way. Previews and notifications for reviews are then created and an item is generated in the accounting system. And then Pixel Nexus sets about mapping exactly that.
The first question, of course, is the underlying architecture. One aim of the changeover was to gain a better overview. However, these checks are necessary for efficiency – who does what, for how long and is the quality sufficient for the standard that the company specifies?

So Jhonie and his team break everything down into the smallest possible components – right down to the individual button – and once you have the exact overview, the required function becomes clear – and you can pack it into an attractive guise – nobody wants to work all day in an ugly interface.
So the question is what exactly is needed – how many files, who has access where and how often? Which notifications are optional, which are necessary and where are approvals available? To this end, Jhonie and his team are developing “user stories” – a precise sequence of all tasks, actions and interactions that a user has – from uploads, files and their versions to naming and exports. The more precisely you analyse each step here, the quicker you can see which functions are needed.

Jens Dessilla explains: “We use Shotgrid to distribute the required articles and information to our partners via the interface. We have various coordination points with our interfaces within the pipelines. If everything has been approved, the assets finally end up back with us via Review & Approval. After the final review & approval, the assets go to our Media Asset Management (MAM). From there, the content is then distributed to the channels. We manage all final assets in our MAM system. These are stored correctly using a combination of naming conventions and metadata. This makes managing thousands of assets much easier.

A familiar interface is also an advantage for the suppliers, as Jürgen emphasises: “The CG agencies are familiar with Shotgrid and know how to use it – this makes data delivery much easier. Uploaders for files go directly into the approval loops. This allows the agency to synchronise the information relevant to them via a familiar API without having to send anything back and forth. For the individual users, it is easy to use thanks to so-called webhooks: The 3D partner uploads the finished file, the system generates the images and stores everything correctly. And this can be done from anywhere in the world. This saves time, eliminates sources of error and facilitates the centralised further development of the line in the background – regardless of how many agencies, suppliers or employees are involved in the process, as nothing changes for the user. The interface can look the way employees from all departments want it to – no technical interfaces, just a modern, appealing environment. Of course, this also makes onboarding new employees trivially easy!

Conclusion

And now that everything is up and running, what are the lessons learnt from the switch to Shotgrid? What would the team do differently? Jens Dessilla: “It was a very exciting and instructive project for me personally. I can only recommend to everyone not to underestimate the process phase and to clearly define, structure, implement and validate processes in advance. All of this can be a very time-consuming and complex process with several interfaces. However, it should not be seen as “finished”: A pipeline is a living project and needs to be constantly developed. Of course, we are constantly endeavouring to improve our pipeline. I can only make one recommendation here: Increase the level of automation.

The post Shotgrid at the discounter? first appeared on DIGITAL PRODUCTION and was written by Jürgen Firsching.

And above all: how will we look back on our mistakes today? In Adjourned, our contemporary climate summits are already a historical relic, a classic theatre play from the past. Having failed to fulfil their actual task, their former existence now serves only serves to amuse a few survivors. In the dystopia, our present-day climate theatre becomes a perfect source of satire. We realised this in our second film at the HFF Munich under the direction of Prof. Jürgen Schopper as follows.

In the second year of our training, as visual effects students at HFF Munich, we had the opportunity for the first time to develop a short film idea together with other departments at the university, such as production, camera and screenplay, which had to be realised with the help of visual effects. The advantage of this co-operation was that the effort and feasibility of potential visual effects shots could already be planned down to the smallest detail during script development. We tried to work as closely as possible to the principle of virtual production, for which close co-operation with the other departments was a prerequisite. This collaboration was extended by VFX industry professionals, who supported us again and again during the course of the production. Petra Hereth was responsible for team coordination.

by Christian Geßner, Nicolas Schwarz, Chris Kühn,
Malte Pell, Tobias Sodeikat and Jonas Potthoff

From the first script version in October 2021 to the start of shooting in April 2022, we were involved in the preparation of the film in many ways: in parallel with the script development, we created the first concept art, which we used to design the look for our world together with author Larissa Dold and director Matthias Zentner.
At the same time, we constantly updated the VFX calculation with the latest findings from the joint meetings from the start of the script work in order to guarantee the feasibility of the visual effects. In this way, we were able to ensure that the VFX effort was in line with the time frame available to us during book development. It also gave us the opportunity to prioritise during development which parts of the story would benefit from visual effects and where they were not absolutely necessary. In addition to storyboarding and concept art, this process was accompanied by us with the support of Luis Guggenberger. With the help of 3D mentor Berter Orpak, we created a 3D pre-visualisation in a very short time, which not only showed roughly blocked scenes, but already included tracking shots, animated characters and a rough sound layout.

Production: University of Television and Film Munich 
Duration: 07:51 min (25fps)
Resolution: 2K (Aspect Ratio: 2:39)
Render Engine: Redshift, Mantra
Texturing Software: Substance Painter
3D Software: Blender, Houdini
Compositing Software:  Nuke

Once the script was largely finalised in February 2022, we were able to focus on the actual filming preparations. As we already had a very concrete idea of the shots to be filmed based on the 3D previs and the entire shoot was also very VFX-heavy, the shooting schedule was developed directly in the VFX department in close consultation with the producers Luisa Eichler and Michaela Mederer. In various production meetings and shooting schedule discussions, we also planned the concrete realisation of each shot with the other trades – for example, we were able to determine exactly where the real studio set would merge into the digital world with the art department under the direction of Katja Severin and how we could make these transitions as unobtrusive as possible. It also took some coordination with the costume (costume designer: Katharina Ost) and make-up (key make-up: Sabeth Kelwing) departments in order to be able to shoot VFX-compatible costumes and SFX make-up, such as burning hands, as sensibly as possible.

During filming (camera: HFF graduate Teresa Renn), we as VFX students were represented in various positions on set, with the role of visual effects supervisor being swapped on a daily basis so that every student had the opportunity to experience this function for themselves. We were supported by professionals from the industry (Jan Stoltz and Dietrich Hasse). But we were also very busy outside of this position: Both the set and the actors* had to be scanned and data also had to be collected from the set after each take.

After the end of the shooting week, it only took another week until we were able to lure the first VFX shots from a rough cut and start editing (editing: Michael Dervenski & Matthias Zentner). To do this, we updated the latest cut version in DaVinci Resolve with the online material and exported the shot plates and references in 16-bit Linear EXR sequences for editing.

Order in the chaos of assets – the modelling

Hopefully it will still be a few years before it looks like the Vertagt universe here in Munich. As the only thing that already existed during the production period was an empty stage, the world around it had to be created from scratch in the computer. We used a combination of specially created, purchased and scanned assets.
This resulted in a total of over 50 different models, some in up to six different versions. The largest of these was a broken container ship. We reworked the purchased 3D models with our own textures for our film in order to adjust the level of detail for the project and the individual shots. The realistic replica of a whale skeleton, shipping containers and oil drums are some of the many assets that were added to the interior and exterior of the wreck.

Image references of possible shipwrecks, damaged cars, aeroplanes, harbours, pipeline systems and materials affected by sand and weather formed the basis of our research. From the references summarised in mood boards
References summarised in mood boards, we were able to pick out new ideas throughout the project and recreate them in detail. The interior of the shipwreck was continuously filled with first large, then smaller and smaller objects.

The 3D models were modelled and “UV unwrapped” in Blender. In order to cope with the large number of differently coloured and dented containers, we created various textures and models, which were assigned procedurally in Houdini. To ensure that accessories such as cables, ladders and rubbish could still be placed on the containers and that the AO map could be calculated correctly in Substance Painter, the scene was initially blocked with cuboids.

In addition, we modelled a second interior, which is revealed to us in the long return journey as the ruins of an engine room, gradually adding information about the location and the dystopian world. The centrepiece is an old, oversized ship’s engine. The difficulty here was to combine the realistic depiction of the working environment in an engine room with as open an environment as possible to show the size of the wreck. Some elements run through both areas of the ship in order to connect them as seamlessly as possible. Both the rust shader and the cables hanging from the ceiling serve as a link here.
“Among other things, a model looks realistic when the eye and brain cannot grasp all the elements at once, but discover new things bit by bit”. To follow this advice from Dirk Mauche (our active support in the modelling area), a tangle of cables, chains and rope ladders provides the necessary details (and disorder) in the picture.

A crawler learns to fly – rigging & animation

The main CG character, a cockroach called “Despair”, was already delivered with various animation cycles and a rig, but first had to be fed into the pipeline. To do this, we created a motion cycle system in Houdini that could be used to efficiently fade between the various animation cycles. With the help of several controllers, it was possible to run the CG cockroach on a spline curve at different speeds. It only became problematic when more complex movements were required. A rotation around its own axis, when the cockroach has to perform a somersault to escape from a tricky situation, became an endless search for the right point of rotation. The problem was solved using the good old “brute force” method. A second locator served as a new anchor. Despite using ready-made animation presets, we were once again lucky enough to be supported by Prof Melanie Beisswenger as an animation lecturer. We learnt that even the smallest changes in the running speed of a cockroach can provide a lot of information about how it can affect the viewer.

Continuity of light and shadow

We realised early on that we needed low key lighting on set. The only source of light was to be the extremely bright lightbeams that would shine through small holes in the outer wall of our shipwreck, but from whose scorching heat the ship’s inhabitants were to hide. The darkness surrounding them was only to be discreetly brightened up by their bounce lights. However, as is so often the case, it turned out during pre-production that the reality was different. We couldn’t completely do without a few bright accents in the form of artificial light lamps on set in order to capture the mood and create enough detail in the blacks for the camera. This resulted in an interplay of lightbeams, which have a daylight and therefore cool colour temperature, and practicals, which emit artificial light and therefore have a warmer colour temperature.

In order to get as close as possible to the properties of real sunlight in our studio environment, our head lighting technician Torsten Baier organised a large PAR spotlight, which was directed into the right paths using mirrors and whose light cone was suitably shaped. Thanks to the parallel beam path of this spotlight, it hardly loses any brightness at a distance and thus corresponds to our perception of sunlight. A lot of artificial fog on set also ensured that the beam of light was visible in the air and that our surroundings looked appropriately dusty. Now it was time to digitally match the lighting from the set..

The long shots were particularly challenging, in which we had to extend our shot set outwards in order to be able to tell the interior of the shipwreck credibly. The transition between the filmed stage and the digital set was concealed by 3D-scanned scrap parts and models, but the lighting mood had to match exactly for both. The light beams also cross the “boundary” between the filmed and digital plate, which is why they had to be partially supplemented, but also completely retouched and digitally replaced. The aim was to recreate the correct angle, diameter, intensity and colour temperature of the real light beam. This was done in Houdini and then rendered with Redshift. In compositing, we added further details such as animated fog and particles floating in the air to the light beams, further blurring the line between real and computer-generated footage. We received a lot of support from our lecturer Frank Dürschinger, who provided us with the final food for thought to create a realistic image.

Other shots had a smaller CG component, but this had to be all the more seamless. As a completely digital character, our cockroach needed lighting that was as true to the original as possible, including refraction, reflection and shadows, in order to fit exactly onto the plate being shot and integrate itself into the real world. And that in every setting size – whether it appears large in the picture or only takes up a few pixels. To achieve this, we used a 360° camera to take exposure series of the respective location and its lighting during the shoot and then stitched them together to create HDRIs. The HDRIs served as the basis for the lighting of the respective 3D scenes, but were often supported by additional spot and area lights. Finding the right balance between too much and too little additional lighting was a challenging fine-tuning task, but it was also a lot of fun.

FX simulations: Sand and bone dust

The requirements for the FX simulations ranged from simple setups like the main title crumbling into dust and a cockroach kicking up sand, to big challenges like the skull shattering on the ground and a photorealistic desert that had to work in both close-up shots and a super long shot. We were once again lucky enough to have Felix Hörlein on board as a lecturer for our second project at the HFF and were therefore able to draw from the full range of possibilities.

In the final shot of the film, we establish a vast, open desert landscape swept by sand and wind. The biggest challenge in realising this haze was the enormous size of the terrain. With an area of three square kilometres, a simulation approach was needed that could simulate different resolutions for different areas. Thanks to the help of Felix Hörlein, an LOD system was created based on the distance to the camera. In the first step, a point cloud was generated at three different points in time using Mantra’s ray tracer, which subsequently produced a representation of the entire visible geometry.

In combination with the LOD system, this resulted in a significantly reduced footprint that could be used to generate the volume. All parameters that have an influence on the volume must also be controlled globally in order to ensure that the edges of the individual LOD areas blend into each other as much as possible. To save computing power, time and storage space, the simulations on the individual wedges only start shortly before they are visible in the camera. In addition to the volumes, we used a particle simulation in the foremost areas of the field of view to get as close as possible to the “sandstorm” target. This was controlled by the Vel field from the volume simulation.

Despite all the cost-saving measures, one workstation per version took an average of around six days to simulate all the individual parts, generating a cache size of 5 TB. This is largely due – at 1250 frames – to the length of the shot. Mantra became our render engine for all simulations. Rendering was always done with mattes, IDs and cryptomattes to give the compositing specific access to the individual simulations.

The skull crashing to the ground and disintegrating is the dramaturgical highlight of the film and demanded a lot from us due to the size of the shot. The basis of the effect is an RBD simulation with custom constraints for the three areas “skull”, “jaw” and “teeth”. To make the breaking more interesting, the option “switch constraints when broken” is also active for a selected area that contains the main features of the skull. Using a second constraint type, the selected geometry is held together for longer before it finally breaks. The skull has been acquired and prepared for the simulation. Three separate “rbd-fracture-nodes” are used to divide it into fragments in order to get as close as possible to the real properties of the different bone thicknesses.

To save memory space and optimise performance, the RBD simulation was only cached as points. This allowed us to remesh the geometry of the skull only after the simulation and thus determine the final resolution of the mesh. A growth solver, which is initiated by changing the distance between neighbouring points when breaking, starts the “disintegration” process. All infected polygons are passed on to another solver, which freezes them at their position and feeds their centre as a single point into a POP network. After the simulation of the POP solver, the polygons are linked to the animation of the respective points using an ID. This allows the dissolving parts to be simulated and saved in a very computationally and data-efficient manner. The individual points are controlled by a velocity field that was generated with the RBD simulation.

In order to intensify the shattering, we have also added two further particle simulations, which on the one hand provide more volume, but more importantly create the appearance of a dust-covered floor – and thus correspond to the rotated plate. We were also able to use a similar but significantly simplified technique for two shots in which the hand and arm of an actor are burnt by the sun and disintegrate into dust.

Digital film set

The use of the Faro laser scanner provided great technical support for post-production. Purchased especially for the Visual Effects degree programme, we were able to create 3D scans of the entire set, which later enabled us to read off accurate distances and create precise match moves. Our initial expectations that tracking would not be a problem with smaller camera pans were quickly dashed by the bitter realisation of how important a good match move is.
Thanks to Matchmove lecturer Ando Avila, however, we were also able to overcome this challenge. The scans also form the basis for the digital replica of the film set. An initial rough reconstruction provided information on the position and tilt of the camera, and details such as wooden struts, chairs and lamps were subsequently added. The recording of the actors was rotoscoped and projected onto the geometry. The projection of the recorded stage onto 3D geometry was used several times. Especially to create subtle
3D projection was an important tool, especially for credibly narrating subtle camera movements with parallax shifts. Of course, it was also helpful to use rudimentary geometry.

Pipeline

In the previous year and during the course of the project, we learnt a lot about effectiveness and workflow. Many shots with the same environment led to the decision to integrate Houdini digital assets into our workflow. This allowed us to tackle steps such as modelling and animation at the same time. But that alone is not enough to keep a cool head and keep things organised. Our Pipeline TD Jonas Kluger, who supported us in the workflow with Shotgrid Studio and modified the pipeline according to our needs, made sure of this. This enabled us to keep a better overview of the tasks and stick to our production schedule.

Compositing

The final step in post production was compositing. As the production offered everything from simple retouching to elaborate full CG shots, the six students had to finalise the more than 40 visual effects shots in a short space of time. Deadlines are deadlines and they don’t wait any longer than our climate. The comp work took place exclusively in Nuke and for some of us, working on the project was a good introduction to the software. Fortunately, we were able to rely on the support of Christoph Zapletal and Jens Schneider, who were able to teach us better Nuke structures and advanced techniques. This was the only way we could work on many different shots at the same time.
At the end of the film, there were also several shots in which we had to digitally add ash flying through the air. The “Das Element” software helped us enormously here, as plates can be organised and found quickly. These
Plates were inserted after they had been created on the last day of filming and thus supplemented the library of purchased stock footage. From a large ladder we threw dust particles, torn paper or we blew mist through a hose into a rubber glove. As everything was filmed against a black background, we could simply use these elements in Nuke and add them to the shot plates on the stage.

Nice and dirty – the colour grading

Once shooting, editing and visual effects were complete, the film was given its finishing touches. Andreas Lautil from Pharos created an individual look to match the eccentric style of the dystopian theatre. Although the grading is based on fairly classic teal and orange lighting on set, it was pushed in a much dirtier direction here. The dark areas were made dirtier and greener so that the audience could put themselves in the shoes of the run-down world and better empathise with the society in the film. Once again, it became clear how much influence each department has on the final project. Originally, a rather desaturated style was planned – clearly recognisable in our concept drawings. However, this was greatly varied in the grading. Now the contrasting cold tones in the depths harmonise with the warmer highlights and thus also with the absurd events in front of and behind the stage.

The sound design and funny background conversations

The quiet murmuring, the sound echoing from all directions and the creaking of the rusting steel transported us to the gigantic wreck in the middle of the desert for the first time in the making of the film. Thanks to Dr Rodolfo Silveira’s work in sound design, the silent shots that accompanied us for months became an atmospheric experience. In several sets, vocal ranges and positions, we students were even able to lend our voices to the digital audience ourselves and push our vocal chords to their limits. What do old, injured people who are on the verge of dying of thirst sound like when they nevertheless enter a bizarre theatre? The HFF’s in-house recording studio demanded a lot from us in terms of acting, but also brought to light a hidden passion for some of us. As the film was shot entirely in a studio, it was necessary to place all the metallic sounds of a ship in the very first shot of the film.

Thus, the entire opening sequence, which takes place in a corridor on the side of the theatre stage, was completely resonated to convey the echoes, vibrations and thus the dimensions and weight of an abandoned oil tanker. Through this strategy, the sound information creates a new level of understanding that complements and enlarges the film for the audience and prepares them for the climax and the central conflict of the story. The sound design was supported by an atmospheric composition by musician Meredi, who was able to capture a unique mood for the film using specially created sounds.

Outlook

Above all, working with industry professionals has shown us that even a little insight and practical experience in all departments helps us to gain an understanding of other departments. The mentality that visual effects is just a part of post-production is a thing of the past, because film-making begins for visual effects during script development. Virtual production is becoming increasingly relevant for well-planned productions with a visual effects component. The first internal presentation took place as part of the “VFX-Reel” 2022 exhibition in the Audimax of the HFF Munich.

Team

• Script: Larissa Dold
• Director: Matthias Zentner
• Producer: Michaela Mederer and Luisa Eichler
• Director of Photography: Teresa Renn
• Gaffer: Torsten Baier
• Production Designer: Katja Severin
• Costume Designer: Katharina Ost
• Key Make-Up: Sabeth Kelwing
• Composer: Ina Meredi Arakelian
• Editor: Michael Dervenski, Matthias Zentner
• Colorgrading: Andreas Lautil
• VFX Supervisor: Jan Stoltz and Dietrich Hasse
• Project Supervision: Prof. Jürgen Schopper
• Project Consultant: Dr Rodolfo Anes Silveira
• VFX Pipeline TD: Jonas Kluger
• 3D Mentor: Berter Orpak
• Team Assitant: Petra Hereth
• Technical Tutor: Moritz Rautenberg
• VFX Producer: Chris Kühn, Jonas Potthoff
• Modellers: Christian Gessner, Chris Kühn, Malte Pell, Tobias Sodeikat
• Texture Paint Artists: Christian Gessner,
• Chris Kühn, Malte Pell, Tobias Sodeikat
• Simulation Artist: Nicolas Schwarz
• Animators: Chris Kühn, Tobias Sodeikat, Malte Pell
• Compositors: Jonas Potthoff, Chris Kühn, Nicolas Schwarz, Malte Pell, Tobias Sodeikat, Christian Gessner
• Visual Effects Editor: Jonas Potthoff
• PreViz Artists: Christian Gessner, Chris Kühn
• Sound Design/Re-Recording Mixer: Dr Rodolfo Anes Silveira
  • VFX Mentors
• Concept: Luis Guggenberger
• Modelling/Texturing: Dirk “Superdirk” Mauche
• MATCHMOVE Ando Avila
• FX: Felix Hörlein
• Mattepainting: Jens Schneider
• Animation: Prof. Melanie Beisswenger
• Compositing: Christoph Zapletal
• Lighting: Frank Dürschinger
  • Cast
• A Chancellor: Viola von der Burg
• A Conservative Party Member: Claus Peter Seifert
• Green Party Member: Ronja Katharina Brusa
• A Prompter: Patrick Bimazubute
• The Choir Singers: Emil Vorbrugg

The post VERTAGT – VFX for a dystopian satire first appeared on DIGITAL PRODUCTION and was written by HFF Hochschule für Fernsehen und Film München.

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.

Six of us started our studies with Professor Michael Coldewey in the 2020 winter semester. Thanks to his extraordinary commitment, we were the first VFX class at HFF to start giving free rein to our ideas early on. When Professor Jürgen Schopper took over as head of the specialisation in spring 2021, we were confronted with realistic project planning, which meant that the projects could be completed in July 2021. For the most part, we succeeded and it was an extremely important experience for us.

by Chris Kühn, Nicolas Schwarz and Christian Geßner

Jonas Kluger, Pipeline TD at HFF Munich, set up the Shotgrid software for us to manage the projects. With regard to time tracking, which is common in the industry, we quickly realised how much time is actually needed for some “small” changes. We received cinematographic input from Rodolfo Anes Silveira, who also supported us in all audiovisual matters.

The two films 01 of the new VFX class at the HFF Munich 

Jürgen Schopper took over the professorship of the VFX specialisation in April 2021. The first students have now completed their film 01. The result is the animated short film "Sleep Tight" and the fully animated fictional teaser "17 Souls". 

Jürgen Schopper started as head professor of the VFX specialisation at the Munich University of Television and Film (HFF) at the beginning of April. The specialisation is anchored in the HFF Department of Visual Design (headed by Prof. Tom Fährmann). The first VFX students started there in the winter semester 20/21. 

Prof. Jürgen Schopper: "I really enjoyed planning the VFX specialisation and supervising the very first two films in this new degree programme. I would like to thank our President Prof Bettina Reitz, without whose support this new direction at HFF Munich would not exist, Prof Tom Fährmann, who has always supported me in the planning, and above all Prof Michael Coldewey, who was such a great mentor during the first semester before I was appointed to HFF Munich. I would also like to thank Prof Dr Peter C. Slansky, who was a great help with all the technical aspects. With Petra Hereth (Team Assistant), Rodolfo Silveira (Artistic Associate) and Jonas Kluger (Pipeline TD), we have now set up a great VFX team in our department, which is supplemented by external lecturers. This ensures the most up-to-date references in the curriculum and the exchange of students with the VFX industry from the very first day of study. We have opted for an end-to-end VFX workflow - from brainstorming to the finished film - which is also state of the art in the industry. But it's best to let the students themselves have their say and describe their impressions and experiences in the process of creating their first two films."

The first film and an immediate crash

What do “Der Schimmelreiter” by Theodor Storm and a missing passenger plane from the 1940s have in common? The teaser “17 Souls” tells the beginnings of a mystery story about a ghost ship based on true events.

At the end of the 1940s, several “Avro Tudor” aeroplanes disappeared over the Atlantic Ocean in the infamous Bermuda Triangle. To this day, it is still not clear how these crashes could have happened despite the best weather conditions. Based on these events, the 3D animated teaser “17 Souls” was created at the HFF Munich, supervised by professors Jürgen Schopper and Michael Coldewey. We were very fortunate to be supported by people with industry experience from the VFX and animation film industry departments.

Brainstorming and conception – the visual claim

The long-standing tradition of the HFF Munich actually stipulates that the students’ first film must be shot in black and white. The various areas of VFX bring with them many innovations, which means that HFF Munich has finally created a link between analogue and digital. As a result, we were lucky enough to introduce a bit of colour into our film.

We initially pursued a visual ambition rather than a profound narrative. As pioneers of the new VFX programme, we knew at the beginning of the semester that we wanted to create images that would impress our viewers. We already had enough material for initial concepts from our research. With the first storyboard, we were able to cut together a pre-visualised film and use an initial sound design layout to better capture the mood and direction we wanted to take. We used the weekly meetings with Prof Michael Coldewey, Prof Jürgen Schopper and Rodolfo Anes Silveira to get suggestions and feedback. From this point on, we moved up a dimension from the flat 2D drawings to the 3D software.

Modelling – design first, history second

Due to the coronavirus pandemic, we were unfortunately unable to visit the nearby aircraft museum in Schleißheim for research. Nevertheless, we stuck almost exactly to the original model of the “Avro Tudor IV” for the external shape. Thanks to blueprints and discussions in aircraft forums about the Avro Tudor series, we were able to get a good idea of the aircraft and block out the first settings with a rough model.

As the pre-visualisation gave us an accurate picture of the perspectives that would be seen of the aircraft, the focus of the model was placed more on the front and side views, which allowed us to save unnecessary work on details that were not visible.

For close-ups of the engines, the outer turbines were moved a little further towards the bow so that they are easily recognisable in the blur. The interior of the aircraft is very different from the original and is largely based on our own design, as the original aircraft interior nowadays is more like that of a train compartment. Nevertheless, we have always orientated ourselves on the designs of the time. The cockpit is a combination of modern spaceship seats, control elements from various aeroplanes and several duplicated elements.

Texturing – You snooze, you lose!

The assets were then all given a used look through texturing. It was important to create a dilapidated surface without telling the story of a completely destroyed aircraft. Different camera angles meant that different levels of detail were required on the aircraft. For example, a single wing and the foremost metre of the aircraft nose each have their own 8K texture for base colour, bump, metallic and roughness.

Rigging & animation – a turbulent affair

Due to the stormy environment in which the aircraft is located, we were aware that it had to be shaken up properly. This meant that the aircraft rig had to have several controllers in order to be able to control the shaking independently of the aircraft’s direction of movement. We then implemented the interior in a similar way. Assets such as the seats in the cockpit and passenger area were given their own controller for each seat, which could be animated in the classic way or procedurally.

Problems only arose when changes were made to the geometry of the aircraft, which usually led to less than pleasant surprises in the rig. We were very lucky to work with Prof Melanie Beisswenger from the Ostfalia University of Applied Sciences via Zoom on specific problems in the animation.

Light(n)ing – Let there be light!

Most of the film takes place in a wild thunderstorm. For planning purposes, we created a light sheet under the guidance of creative director & CGI artist Kathrin Hawelka in order to pre-define the right lighting mood. The indirect lighting of the lightning between the different layers of clouds created a special atmosphere. As most of the clouds were actual volumetrics, we were also able to place the lightning, which was generated in Houdini using L-systems, freely in the 3D scene.

In addition, a very transparent volume over the whole scene created an impressive weather glow when lightning struck. To create a gloomy mood, the entire film is lit low-key and is often limited to a single edge lighting. Inside the aisle of the aeroplane, we used flickering neon lights and occasional bright flashes to maintain the basic nervousness.

FX – Smoking heads and burning engines

To keep our finger on the pulse, Houdini was our first choice for all simulations. The industry standard software demanded a lot from us and has become a real asset, especially with the help of our lecturer Felix Hörlein.

The animations of all shots were exported as Alembic from Maya. To keep the simulations as stable as possible, the aircraft was animated at the origin of the coordinate system and not moved forwards at cruising speed.

The climax of the tension in the film is the burning engine. Fire and smoke were created using the sparse solver “Axiom” and controlled with a particle simulation. The time advantage provided by the GPU acceleration of the plug-in was the decisive factor in our decision.

The rain that hits the windscreen consists of particles that are measured to form a water surface. To do this, we created clusters that generate several particles simultaneously and shoot them at the cockpit’s collider geometry. The windscreen wipers do not interact directly with the individual particles, but generate a force field that is responsible for the streak-like distribution of the droplets.

We have created proxy geometries with a significantly reduced number of polygons for all rigid body objects. The collider geometries also only consist of rudimentary geometry such as cuboids. We used Vellum for all pockets in the interior and soft bodies. As it was not possible at the time of production to have Vellum objects and RBD objects collide with each other, we also opted for Vellum for the suitcases in the luggage rack net.

Rendering – If you don’t render, you freeze!

The rendering was carried out using the in-house render farm – a network of 7 workstations. For reasons of time and cost, a CPU render with Arnold or Mantra was out of the question. The original plan was to render in Maya with Redshift. In the end, however, Houdini (also with Redshift) became our lighting and rendering software.
In addition to the classic back-to-beauty layers, we also rendered a depth channel and the cryptomat for all shots for compositing. The distribution of the individual render jobs was monitored with the Deadline Monitor software, which woke us up a few times during the night if a rendering was faulty. The result was wonderful 32-bit multilayer EXR files.

Compositing – Cloudy with a view of rain

For the compositing we were able to use additional layers of rain as well as self-created matte paintings to give our images more depth and realism. For the clouds in the storm, we opted for a mixture of rendered volumes interacting with the aircraft and 2D plates of procedurally generated noise. Compositing artist Heike Kluger showed us the endless possibilities of noise algorithms, which we used for rain, haze and clouds, among other things.

Colour grading – showing your colours

We also noticed the freshness of the course in colour grading, when the in-house colourist, Claudia Fuchs, was very pleased with images with a colour depth of 32 bits. You don’t even get that with the raw codec from RED. Together with the colourist, we created an aesthetic black and white look with a few colour accents.

Sound design – boom, crack, hiss

When we marched into the HFF sound studio with the finished film, we didn’t realise how important the sound design would be for our film. Together with sound designers Gerhard Auer and Rodolfo Anes Silveira, we filled the images with sound. When the first thunderclap was set, a broad grin spread and suddenly the film felt like great cinema. Pattering rain, a burning engine and the distant rumble of the storm resounded through the cinema. The trembling of the low tones and clinking of the flying glass provided the final immersion of the teaser.

Happy accidents & virtual meetings

Virtual feedback loops, digital beer drinking and lectures in all kinds of transport: This is what life was like during the project. Review rounds initially took place exclusively online. We were all the more surprised when we got to see an interim result on the HFF cinema screen for the first time. The initial anticipation quickly evaporated in view of the amount of work that still needed to be done. That evening we also realised that the films were designed for the cinema and not for the monitors we were working on. The joy was all the greater a few weeks later when – back on the screen – we realised what had happened in the final stages. The biggest hurdles had now been overcome.

One example of such a hurdle was moving the 3D models from Blender to Maya. This tended to work smoothly via an FBX export. Only the naming made the Maya file almost unusable. Dots in object names were replaced by a long string after the import and all constraints were included in the object name. The solution to this was a self-programmed Blender add-on that replaced dots with underscores and a checkbox in Maya to hide the name spaces.

Outlook

The first film of our studies is finished. But what are we going to do with it? The teaser and the collected material are perfect for a pitch-vis to push the development of the feature film, which shows the whole story around the mysterious disappearance of the plane. A series of festival submissions is also planned to network even more closely with other filmmakers and gain new experiences. And if you want to see it all in motion, you can find the making-of at is.gd/hff_17souls.

The team 
Cast: Maximilian Klampfl, pilot voice 

Crew:
Producer: Michaela Mederer 
Director / Script / Modelling / Texturing / Rigging / Animation / Compositing: Chris Kühn 
Director / Concept / Matte Painting / FX: Nico Schwarz 
Director / Concept / Modelling / Texturing / Lighting: Christian Geßner
Project Supervision: Prof. Michael Coldewey & Prof. Jürgen Schopper
 
Project Consultant: Rodolfo Anes Silveira 
VFX Pipeline TD: Jonas Kluger 
Line Producer: Ina Mikkat 
Team Assistant to Line Producer: Jenny Freyburger 
Team Assistant: Petra Hereth 
Colour Grading: Claudia Fuchs 
Sound Design: Gerhard Auer & Rodolfo Anes Silveira 
Postproduction Supervisor: Christoffer Kempel 
Technical Support: Benedikt Geß & Florian Schneeweiß 
Conforming: Martin Foerster 

Department Mentors: 
Melanie Beisswenger (Animation)
Kathrin Hawelka (Lighting & Shading)
Felix Hörlein (FX)
Heike Kluger (Compositing)
"Super" Dirk Mauche (Modelling & Texturing)
Moritz Rautenberg (Camera)

The post 17 Souls first appeared on DIGITAL PRODUCTION and was written by HFF Hochschule für Fernsehen und Film München.

“Sleep Tight” is a homage to the horror films of days gone by, but at the same time it also breaks with convention. Our aim was to capture this dichotomy visually. After a few brainstorming sessions and mood research, the setting was found: The world was to be dark and foggy, the images diffuse and rich in contrast. Our professor Michael Coldewey gave us a lot of freedom to come up with ideas, and so the first very ambitious script was soon created. That’s how we came to want a creature as the main character: a werewolf.

by Malte Pell, Tobias Sodeikat and Jonas Potthoff

With this basic idea, further meetings took place in which the story began to take shape: a short, menacing sequence – a werewolf breaking into a house – told full of suspense and with a twist at the end that bypasses the usual tropes of the genre. Here, for once, no one is eaten; the werewolf creature is itself an inhabitant of the house it appears to be breaking into.
But above all, the werewolf becomes a werewolf in the course of this process. This variation is not common in film history, and it was precisely this break with the traditional that brought us a huge step forward in the conception. Based on this premise, the rest of the setting was also modernised under the supervision of Prof. Jürgen Schopper; the originally planned, run-down forest hut was replaced by a modern flat that now stands on the outskirts of the big city. The first storyboard and character drafts were created in November 2020, which were later incorporated into a simple animatic. This rough preliminary version gave us an impression of the most important story beats and, above all, gave us an idea of the timing and pacing, so that we were able to further develop the rhythm and camera angles under the supervision of our artistic collaborator Rodolfo Anes Silveira.
The conception phase lasted a total of 3 months, after which the entire project was set up on the project management platform ShotGrid (formerly Shotgun). A particular challenge in times of coronavirus was that we were often only able to meet online. Nevertheless, we were supported by weekly Zoom meetings with professors and artistic staff from the HFF, as well as experts from the industry – from topics such as concept art and storyboarding to rigging, modelling, texturing, animation, simulation and compositing.

Horror on velvet paws – the creature design

The creature design in particular posed various challenges that had to be taken into account right from the start: In terms of content, we had the requirement that the werewolf could not be too big and massive, after all she still had to fit through the doors of the house. At the same time, she had to move on velvet paws so that her husband wouldn’t wake up in bed when she crept through the building. Nevertheless, she still had to look scary and command respect. Various references from nature were therefore incorporated into the design process: The teeth are arranged in several rows, similar to a shark. We modelled the fur comb on the back on the hump and fur of a hyena.

An additional challenge was that the creature had to walk on both four and two legs. It only reaches its maximum size and dominance at the very end, when it stands up and steps into the moonlight. Before that, it only appears in reflections, in details or as a shadow, so it is always veiled. Only in this shot do we see it clearly and distinctly in front of us.

To ensure that this straightening works, we carried out a number of tests with a motion capture suit from Xsens. We realised early on that the three of us would never be able to animate the entire character by hand. So we took inspiration from films like “Planet of the Apes” and built our own forearm extension from sawn-off crutches. These were adapted precisely to the proportions of the werewolf model so that the sensors of the suit were located where the werewolf’s wrists had to be. This enabled more precise retargeting of the movements of the (real) motion capture performer to the rig of the (digital) werewolf. For her skeleton, the lower body of a dog was fused with the upper body of a human; the creature’s outer skin was modelled around it.
In addition, the extensions of our actress’s arms helped her to feel her way into the role of a 2 metre tall, four-legged monster. We were able to recruit the actress and dancer Kathrin Knöpfle for this physically demanding task.

Digital film set – motion capturing

After this intensive preparation phase, the time had finally come. The model of the werewolf was optimised for capturing, the environments were prepared so that we could create and measure a floor plan of each digital set. Then the four-day shoot began in the HFF film studio. The sets were recreated using movable walls. If there were to be interactions between the werewolf and the environment, they were supplemented with props such as moving doors, branches or a mattress, representing the bed in the bedroom. Various versions were recorded for each shot, which were analysed on set and fed into the existing scenes in Maya via retargeting. This allowed us to view all takes in the form of grayshade playblasts after each day of shooting and decide whether shots needed to be repeated if necessary. Almost like a classic film set! To recreate the mood of the scene as well as possible on set and thus support Kathrin’s performance, we also used a bright light source from the direction of the (digital) moon. At the same time, all motion capture takes were also recorded with a real camera in order to obtain as many movement references as possible.

Bringing the dead to life – the animation

A more detailed, three-dimensional animatic, the first real rough cut so to speak, was cut together from the playblasts of the motion capture shoot. This allowed us to reassess the narrative necessity of each shot, after which we significantly shortened the entire film. Now we could start with the detailed work. In almost every shot, errors that had occurred during motion capturing or retargeting had to be corrected by hand animation. The hands, ears and the blendshapes on the werewolf’s face also had to be animated by hand and any connection errors between the shots had to be corrected.
The two words that give the film its title, “Sleep Tight”, also posed a challenge, as they are spoken by the reverted woman at the end of the film. She turns directly into the camera and speaks to us. Her eyes glow discreetly in the darkness. In order to avoid the Uncanny Valley as much as possible, we had initially thought of a more distant shot. However, for the emotional impact of the final scene, we realised that we couldn’t avoid including a close-up of the woman. This meant that the lip synchronisation and facial animation had to be as detailed and believable as possible. To do this, we not only recorded the audio of the speaker in the recording studio, but also filmed her face at the same time to obtain reference material. This helped immensely with the facial animation. It added nuances to her performance that we would probably never have realised when animating by hand without a reference. We tried to recreate her acting as well as possible digitally. Our lecturer, Prof Melanie Beisswenger, was a great support in this, regularly assisting us online with all questions relating to the animation.
Furthermore, the animation of the camera was fine-tuned afterwards to ensure that the camera movements meshed as well as possible. At the same time, our concept from the outset was to limit ourselves to camera movements that could actually be realised and not to incorporate any illogical or exaggerated movements. We also wanted to do justice to our role models, the early horror films.

Cosy blankets and lumpy fur – the simulation

Once the animation was complete, we moved on from Maya to Houdini, because another major challenge followed: the simulation. Our aim was to make the look as realistic as possible. So with a creature full of fur, we had no choice but to delve into the topic of grooming. Various attempts and several hours and Gbytes of simulation cache finally led to a result. In the final version, the setup consists of three different grooms for different parts of the creature’s body, each of which is simulated with its own parameters in order to get as close as possible to real fur behaviour.
In addition, the woman lies down in bed with her husband at the end of the film, so an elaborate cloth simulation was necessary for the interaction of the two characters with the blanket. Finding the right stiffness with a natural drape took time. But the specialist Felix Hörlein helped us enormously with all the simulations.

Leathery to shiny – the texturing / shading

Underneath the fur, our werewolf naturally also needed a detailed texture for her skin, nose, teeth, eyes, etc. All the texturing was done in Substance Painter. Here we made sure to give the skin a leathery look and to include lots of details such as abrasions and scars, especially on the face. The shader itself was then created in Houdini, with various masks for individual areas such as the skin, nose, teeth and eyes. As with the modelling, we received a lot of support from asset specialist Dirk Mauche. The fur was deliberately not simulated in scarred areas so that the skin comes through in some places.
The remaining shaders for the environments and objects were also built in Houdini. Here, we paid particular attention to matching the colour scheme to the black and white final image from the outset, so that the greyscale supports the focus on the respective image section wherever possible. There was also a further element to help focus on certain areas of the image: a special feature of the creature is that its eyes constantly emit a menacing, subtle glow.
The glowing eyes in the darkness of the house were an element that we wanted to have in the film from the outset. It can be found in early mood boards, but also in the very first storyboard. And it closes the film as a bracket, because the eyes of the reverted woman in the bed also glow in the dark. For this, we created the shaders with an emission map in Houdini. In this area, the texturing went hand in hand with the lighting.

Telling darkness with light – the lighting

Just like the visual design of the camera and set pieces, our lighting concept was consistent throughout the project: Light that is as hard as possible with clear edges that emphasise certain parts of the image and thus support the suspense of the film at the end. At the same time, we hide the exact appearance of the werewolf until the last moment – and thus (hopefully) also increase the suspense.
To achieve this look, we tried to limit ourselves to as few light sources as possible and orientate them on real-life models. The moonlight in the outdoor shots was mainly created using HDRIs supplemented by hard panel lights. In the interior shots, mainly strongly focussed panel lights were used, which were supplemented with moving gobos in some places. These moving, very natural shadows also helped massively to give the images a more realistic look. The lighting design process was supervised by creative director and CGI artist Kathrin Hawelka and DoP Moritz Rautenberg.
Rendering was done with Redshift from Houdini. Pipeline TD Jonas Kluger set up his own render farm at the HFF, which is operated via Deadline. Despite the computing power, up to 5 days were needed for some of the renderings. The fine-tuning of the images only came afterwards, in compositing.

Digital to analogue – compositing

As each shot from the lighting was rendered as a multilayer EXR with 32 bits, we still had a lot of leeway in compositing to adjust the light across all shots and to further harmonise the atmospheric elements with each other.
For the establishing shot in particular, in which we see the modern house and the werewolf’s leg for the first time, some layers were combined as matte painting in Photoshop and Nuke.
In compositing, we also further developed the aesthetics of the film under the guidance of senior compositor Heike Kluger. In order to simulate older lenses, we created a sharpness drop-off towards the edges of the image and a separate lens distortion for each focal length based on old Angenieux zoom lenses. The corresponding lens grids were shot by fellow students from the HFF camera department when they had a seminar on handling green screen and VFX on set at the same time as our motion capture shoot.
In Nuke, we also added a subtle glow to the highlights and particles, similar to the properties of a BPM filter. This stylistic patination of the otherwise clean, digital images contributes to the impression that the footage was actually shot, and we also wanted to get even closer to the aesthetic of old horror films. In colour grading (colourist: Claudia Fuchs), we then reinforced this impression even further by adding film grain and high contrasts. Here, too, the large headroom of the EXR files paid off and we were able to give the images the perfect finishing touches.

Lost in the sound? – The sound design

The final step was a sound mix in 5.1 under the direction of Gerhard Auer and Rodolfo Anes Silveira. For the sound design, we focussed on atmospheric sounds and music beds that didn’t sound too melodic and intrusive in order to draw the suspense from the sounds of the creature and the house. Only at the big climax, when the werewolf stands up, do weird violins enter and the music comes to the fore, getting louder and louder to make the atmosphere as uncomfortable as possible and the twist afterwards all the more effective. We even recorded the squeaking for this ourselves at home.

On velvet paws into the future – an outlook

Once the sound mix and the edited material had come together in the form of a DCP, an internal team premiere took place in the HFF’s own cinema. Guests included the department heads and supervisors from the industry, with whom 9 months of work on this film came to a provisional conclusion. We are very proud of the result and would like to thank everyone involved for their support. The film will be released in 2022, and perhaps our Werwölfin will then sneak into one or two festivals. Until then, you can watch a making-of at is.gd/hff_sleep_tight.

Team

Cast

Motion Capture Actress: Kathrin Knöpfle
Voices: Lisa Hagleitner, Hendrik Ehlers

Crew

Directors, Script, Editing, Camera, Animation, Simulation, Compositing: Tobias Sodeikat, Malte Pell, Jonas Potthoff
Producer: Luisa Eichler
Project Supervision: Prof. Jürgen Schopper, Prof. Michael Coldewey
Project Consultant: Rodolfo Anes Silveira
VFX Pipeline TD: Jonas Kluger
Line Producer: Ina Mikkat
Assistant to Line Producer: Jenny Freyburger
Team Assistant: Petra Hereth
Colour Grading: Claudia Fuchs
Re-Recording Mixer / Sound Design: Gerhard Auer, Rodolfo Anes Silveira, Stefan Möhl
Postproduction Supervisor: Christoffer Kempel
Scheduling: Beate Bialas, Sabina Kannewischer
Editing Support: Christine Schorr, Yuval Tzafrir
Technical Support: Benedikt Geß, Florian Schneeweiß
Rental HFF Munich: Rainer Christoph, Boris Levine
Studio Management: Peter Gottschall, Andreas Beckert
Conforming: Martin Foerster
Consultants: Dirk Mauche, Kathrin Hawelka, Moritz Rautenberg, Felix Hörlein, Melanie 
Beisswenger, Heike Kluger

Production

University of Television and Film Munich
Supervising Professor: Prof. Jürgen Schopper, Prof. Michael Coldewey
Technical Details
Frames: 4,608; Resolution: 2,048 x 858; Aspect Ratio: 2.39:1; Renderer: Redshift; Compositing: Nuke, After Effects, Photoshop; 
3D software: Houdini, Maya, Blender, Substance; Sound: 5.1
Website hff-muenchen.de/

The post Sleep Tight – A modern horror tale first appeared on DIGITAL PRODUCTION and was written by HFF Hochschule für Fernsehen und Film München.