The Video Copilot programmers from Germany

This article originally appeared in DP 04 : 2019.

At Video Copilot Live in Berlin, Andrew Kramer showed in a sneak preview how volumes can be illuminated in real time and manipulated with masks – and we got to know his two German programmers there.

As the new Nebula 3D plug-in is in the starting blocks, we asked the developers for a chat – as I write this article, the beta phase is just beginning and the stress is only just starting for the guys. We hope that there aren’t too many bugs to iron out and are very excited about the real-time cloud spinner. But who is behind Nebula?

Thomas Obermaier (www. instagram.com/thomas_obermaier) is the coder from the Allgäu region. He had been working with Andrew for eight years before they met in person for the first time at the event in Berlin. He is responsible for the programme code, specialises in render engines and is now a consultant for rendering projects, among other things. For Video Copilot, he has worked on Optical Flares and Element 3D, among others. He has the best ideas when he’s out walking his dog.

Fabian Buckreus(www.instagram.com/fabianbuckreus) from near Dortmund is responsible for content. He has developed some of the content for the Video Copilot library – for example Shockwave. He has generated huge amounts of VDB sequences for the new plug-in. When he’s not working for Andrew, he’s often freelancing on cinema productions as a specialist in particle effects, destruction and simulation, such as “Star Trek – Into Darkness”, “Transformers 4”, “San Andreas” and “Cosmos – A Spacetime Odyssey”. His tools are mainly 3ds Max, Thinking Particles, FumeFX, PhoenixFD and Houdini. And he does all the particle simulations for Video Copilot.

DP: How did you come up with the idea for Nebula 3D?

Thomas Obermaier: We were experimenting with lights and I said to Andrew: “I’ve tested this once, let’s add another volume.” He thought that was a cool idea and I tried it out. And then suddenly I had an extremely cool volume in After Effects that looked spectacular and could be moved in real time.

DP: Fabian, what was your reaction back then?

Fabian Buckreus: I think I fell off my chair, if I remember correctly.

DP: And what were the hurdles during the first tests?

Thomas Obermaier: In the beginning, when you turned the quality up extremely high, it became slow. Andrew said to me: “Thomas, that’s pretty cool, but can’t it go any faster?” After about 3 days of sitting quietly in my little room, I had an idea and thought: “Oh, that really works.” Then I showed it to Andrew and he said, “That was actually just a joke, that you should do it faster.” Anyway, now we can render high-resolution volumes in real time.

Fabian Buckreus: In the beginning,we still had problems with aliasing at the edges and we solved each problem in turn – now it’s perfect. I’ve always done the volumes for Video Copilot, but sometimes it took two weeks to render a volume. And now it works in real time.

DP: But what’s behind it all?

Thomas Obermaier: It ‘s a completely independent renderer that can also render atmospheric things like volumetric lights with noise, for example, as with cigarette smoke in the air. And it can import OpenVDB data, which can be rendered with all shading options such as lights, density changes, scattering and occlusion. The cool thing is that the lights also cast shadows in the volume. For example, you take an Element3D scene and place the Nebula layer over it. Then you have all your lights directly in there as volumetric lights. You want an aeroplane to fly through a cloud. Or a car is burning in a city scene and all of this is also “occluded” correctly – we don’t cache anything. You put in the volume and a light with it. Then you can rotate and scale it in real time with the camera and don’t have to wait forever. Normally, it takes some time to render such a volume. But since here, as in Element3D, it is rendered on the GPU, it can be done almost in real time.

The atmospheric lights don’t consume a lot of memory either, but a volume like this can be quite memory-intensive. In the feature film area, you sometimes have volumes of 40 Gbytes. Which of course we do: We optimise it internally, and because we don’t cache, we don’t have to outsource so much additional data. We always recalculate the lights to avoid caching and to utilise the graphics card memory as optimally as possible. A lot of work has also gone into making this really work. I have a GTX 980 graphics card in my computer (which is consumer level from 3 years ago) and deliberately not a Titan card, because it’s important to me that I develop this on a normal graphics card. It should render quickly for everyone.

DP: The plug-in will be ready in one of the next issues and we can test it and do a workshop?

Fabian & Thomas: Definitely ! The beta already looks very good, and it will be ready soon!