Fail Fast, Fix Faster: Pipeline Wisdom from Halo Infinite to Virtual Production

If you have a minute wasted here, two minutes wasted there, and things that just like, you know, the user just sits and does not respond, that frustration keeps growing. It translates to millions of dollars of lost time and lost effort and a lot of impact to the person itself.

Welcome to In Development, where we explore the technical realities of creating today's most ambitious digital experiences.

Each episode features in-depth discussions with technical directors, pipeline specialists, and digital creators who share their approaches to overcoming real life production challenges. Not just what they accomplished, but what went wrong along the way and how they approached solving those problems.

Today's episode is an especially fun one for me. I'm joined by Luis Placid, a fantastic developer who's worked on a huge number of well known projects in gaming such as the Halo franchise and the Age of Empires series, as well as major films for VFX such as Dune part two, The Last Airbender, Furiosa, and much more. I always enjoy chatting with Luis when we meet at conferences, nerding out about pipelines, and he's so generous with his knowledge that I always learn something from him. And with that, let's get right into the interview.

Luis, thank you so much for joining me today.

Oh, it's super awesome to have joined you. Thank you so much for the invitation. I'm very excited about this.

Your backstory is an interesting one where you've jumped across different industries between media and gaming.

So could you give us a little bit of a background of the short version of that journey and then what you're doing?

Absolutely. Yeah. I'm glad how you put it. My industry experience has taken me into a lot of different places. Apple as a, like, as a genius behind a Genius Bar. And then from there, I jumped to doing test field analyst for Bluetooth chipsets with them.

And part of that went into gaming at a small offshoot here in Vancouver, BC in which I spent ten years of my life in it. I had the pleasure of working in the games that made my childhood, like Age of Empires, Age of Mythology, Horizon Nations. Then I had the amazing opportunity of being one of the contributors and then leads on Halo Infinite and the Halo franchise as a whole. And then, yeah, four years ago, I kinda did like a I'm gonna switch everything and went into films, joining a company called DNEG, which is a ten thousand plus company, Oscar winning. We did Dune. We worked on Oppenheimer, a lot of stuff. And I had the pleasure of being their head of research for real time development, integrating a game engine into virtual production, which is a significant up and coming industry within the film games that does anything from animation, marketing, capturing things in front of a volume.

And you got into that pretty early, like, early in that trend of starting to use game engines and things. I know that DNEG, I think it was on For All Mankind.

Yeah. So DNEG started getting into it pretty early, and they started doing tests with Matrix Revolutions, Bullet Train that were done using Unreal driving their LED volumes. But what a lot of people don't know is that we started doing a lot of work earlier than that. Virtual production was used in Unreal Engine that's using game engines as well as the entirety of Battlefield, which was Tom Hanks.

That was done during COVID using Unity. Yeah. Wow. So it's like, a lot of companies were starting to explore that space during and slightly before COVID, and now it's taking the world by storm.

For sure. I feel like now it's all over the place. Lots of people trying to revamp their pipelines to speed up their VFX pipeline or animation, things like that. So, yeah.

You were there right from the beginning.

And I've been lucky because it's a very awesome tool in the arsenal of the director and the script writers and stuff like that that they can actually go and create new movies and focus more on the performance instead of having to focus on the actor and everybody in cast, trying to figure out their place in space against a green screen. Now they can actually see the environment that's around them, And that's one of the main associated uses of virtual production. But virtual production goes anywhere from set extensions, computer graphics to clear buildings or even the street signs that has been going on for a while. It's just that now there's very big ticket items that a lot of people will go less. That's the piss ass. Right?

Yeah. Okay. So sorry to interrupt your story. So you were at DNEG, worked on a lot of that stuff. What was your department title?

So my official department title was head of research for real time development, and that included everything that has to be using a real time engine. It could be Unity or Unreal or even, like, some other offshoot systems that use real time rendering for applications in virtual production and interactive media space because DNA was also expanding a way for not just being a VFX studio. They wanted to do both. Like, they had a very established feature animation team, but they wanted to, like many of our publishers and major companies, expand other areas of where they can use their IP in more interactive places. It could be like art installations or video game tie ins or even like phone companions for movies. That was something that we were trying to explore a lot of the use of that interactive media.

And then after a three and a half year stint at DNEG, I wanted to do something impactful, smaller team in which I can actually push the envelopes. And now I open my own company, Shift Storm Entertainment. I do software consultation with several companies, and right now, I have the pleasure of being associated with a company called ICVR, which is in the virtual production space, and I act as their director of engineering.

Yeah. It's fun. I've I've worked with the guys from ICVR for many years, and then I've also known you for quite a while when you were at Deneg, so then it's fun that now you've joined forces with ICVR.

So I'm like, It's all the people I already know.

So now we're slowly getting into the which is one bucket. Right?

To do everything. Right? Gaming and media and everything.

And it's funny because those tools the tools that I use in gaming have made their way into being used today on the film and entertainment space, like Perforce that I'd used for well, close to seventeen years of my life now, I seem to not be able to get away from it. Right? And as our still tried and true solution for any heavy binary related projects, right, and games and film and entertainment, especially film and entertainment, things are heavy, right? Our hero assets are gigs at a Right?

To just have that beautiful Yeah. Nice little render or let's say that ship on Interstellar that we used that was like close to like three gigs alone after optimizations. Right?

So just for the models.

Just for the models. And we did that in Unreal and it was I have so many stories because of how it will break the physics engine because we were doing calculations against kilometers trying to put it in real space.

Right.

It's like the scale it's not used to thinking And then, you know, things that we don't think about, that little tiny GPU fluctuation.

When you're traveling at close to speed of light in the engine and you're trying to simulate, that breaks Yeah.

How bad.

That zero point zero one just Wow. Puts like an extra like ten thousand newtons of force or something and it just blows up.

Yeah.

It was pretty fun.

Okay. Wow. Alright. So, this is a great segue into what is in your toolkit now. Right? You mentioned a lot of things from gaming, getting over into media, that you're actually using a lot of the same things. So, besides Perforce, what else is in your tool?

Yeah. So a lot of the things significantly overlap. If we start talking from the digital creator side of things for like the artist, we still use Maya on games, we still use Blender, we use three d Max, Zbrush. Right?

It's a choice of the artist to really figure out what they're used to. Photoshop's still a thing there in which we use that to do textures. Now, we use it for cleaning up little frames and like having little problems that need to be manually cleaned up. That's still there.

There is a little bit more of specialized tools in the side of the virtual production space like Mari and Katana that are specifically for lighting. Right? Because we need a higher quality lighting definition in the film space versus the Unreal, Unity, even like Go engines, I've seen that being used in film. It's a little bit insane how you see that.

It's still the Saxon environment, it's just how you use the tool. Right? How do you create your our hero assets on film could be millions of polygon and textures that are eight k plus, right, to make sure that it looks crisp and great. And they don't care that it takes like, oh, it takes like twenty minutes to an hour to render, right, per frame.

But, like, on the Yeah. Gaming side, our hero assets are still high quality, but, like, we will cap them at, like, two k, for example, certain amount of polygons. Right. So, it, it is optimized.

And then, even things that if we can hide them off screen, like Master Chief, it's just a series of floating gauntlets and legs. Right? So that's like tricks that we have to do on the game side, but it's still at its core the same.

We use Python, we use C plus plus because if you're using Unreal or Unity to make it extremely optimized, you have to rely on those languages. Python to script anything because you're still targeting Maya, as I said, Maya, ZBrush, Blender, and those are basically Python interactable.

I also just feel like so much of the pipeline world and scripts out there is all using Python Yeah.

Anyway. So it's like, if you wanna reuse stuff that other people have, if you wanna use open source projects, it's almost always Yeah. Python.

I I'm hard pressed to think of any exceptions to As a funny aside, I've seen Lua somehow make its way now into the virtual production space.

Yeah.

Every now and then. It's like, you know, we use Lua and a lot of state machines and, like, design driven systems for for video games.

Like, it was heavily used in all the games that I worked on when I was doing EA work. But, yeah, I was surprised the other day to hear people scripting in Lua for a movie that I'm part of, and I'm like, woah, why are doing that? But it was a blast in the Like, yeah, no matter how much, all these tools that I once thought that they were like, oh, they're temporary. It's only for this project. They have moved across my career in surprising ways. Right. So.

Yeah. And then what about some other things for keeping track of everything?

You mentioned the tools you use for creating things, but what are the other pieces of the pipeline that glue it all So very similar in games and film.

If it's a very heavy asset based game, something like Halo, for example, or something like No Man's Sky or Dragon Age, you need to track a lot of the assets in the state of things. So a lot of people use Ftrack or ShockGrid or any other digital asset management system, which is front facing. I know I've seen even people use a new Perforce DAM system, right, very successfully depending on what their needs are. Source control generally stays the same, and it's very similar in the virtual production space.

Anything that's binary, like, on real projects goes into Perforce. Anything that is scripting or, like, can be isolated goes into your usual Git SVN Mercurial if you are old school. Right? So and then, like, there's that nice separation.

It's just a lot of reeducation. Reeducating the user, especially the artist, about, like, how to operate. In film production, they just basically create duplicates and keep track of everything, versus in games, you're used to just, okay, cool. We save on top because we rely on something like Perforce to keep track of it.

And the first couple of times that you explain it to an artist to, hey, save on top, it's fine. You will not lose your progress.

They look at you like you just asked them to punch a baby. It's okay, I swear, we're gonna save your work. And it's a lot of reeducation to have them be able to create and not focus on like, you know, the panic of losing their work.

And that's that's the key thing we wanna talk about today is the challenges and the journey of that reeducating of trying to work both with artists and with technical people together so that everyone has a good pipeline there. And you've had a lot of experience with that both within the companies you've worked for and now also consulting for lots of other companies, and ICVR works with a ton of huge companies. So you've got a lot of experience now. Bringing artists into version control is a passion of mine because I started as an artist as well. Like, I was originally a VFX artist and then was like a lead artist and then started doing some scripting and then started writing some things for the pipeline team.

And only then did someone say, hey, you should be using git. You should be using version control for your code. I was like, okay. Alright.

Let me look that up. And I just had the worst time trying to learn it because I had no context. I wasn't working with other people that used it. I was alone trying to understand it and it was way over my head.

Like even after people explained it to me, I didn't quite get it. I started using it and then just gradually came to use it just to now the point where I couldn't imagine living without And then, you know, obviously with Perforce for more binary art assets being able to do the same, I'm like, oh my gosh, why haven't we been doing this all along? What's been wrong with us all along?

But I can empathize with that pain of learning it, of trying to wrap your head around And I'm gonna throw a shout out to an amazing person that I had the pleasure of working with, Josh Marble and Josh Dean, as well as Kevin Dalciel, all three of them, which I have the pleasure working with them when I was on the Halo engine doing Slip Space work.

Because I'm a technical guy. I'm I'm nerdy. I have Git requests being sent to my phone. So I'm that guy.

Right? I'm that annoying guy. It took me a while to actually try to figure out how to put myself in the other shoes and I have those three people really sit down with me and explain to me their process. And funny enough, that's how we unearthed some of the amazing gains of how to make the work to be even better.

If I may, I'm gonna go a little bit on that story to give you a little bit of insight. Sure. I gave them a massive document, it like, here's how you do get and here's how you do Perforce and then I was finding myself frustrated that they were having the exact same experience as you. It like, oh, this is super overwhelming and like, how do we get this to work together?

Because you kinda get ingrained into you in university or even early days of source control. Like, you do a couple of things, you save it, and then now it stays somewhere. Hopefully, you push it somewhere else, so now you have a backup. Right?

Yeah. So it's backed up. Oh, yeah.

And then, it took me a while to actually figure out that this is not something that they're used to. They just would duplicate their asset or save as final final final final, which we all make fun of. But it was it is manual source control and they have to mentally do the like, what was the actual final version that I want and some people had notes Right. Or like excel document that they would copy and paste the name of the files. Yeah.

I have memories of doing all of those things. Right? Yeah. I I always take a little bit of offense whenever people make the final final final joke because, I mean, I make the joke too, but I'm always like, no, come on. If you're a professional, you name everything v o o one, v o o two, sometimes like v o o three b. Yeah.

There you If you wanna do an alternate, like There you go. It's like, it's not quite as bad as final final final, except that one of our bosses at the VFX studio where I worked at, anytime he would come along and do some work, he would always just save it locally on his computer.

So you'd have to go, like, figure out which workstation he was on to get his files and put them on the network store. Come on, guys.

Or it even happens don't get me wrong, like, it happens to technical people because I'm an interviewing lead, I've been interviewed for several years, and right now, I'm evaluating a couple candidates and they forget that we see the name of the file, the somebody's name, resume, final corrected English Right. Finals. I sat down with Josh Dean, Josh Marble, Kevin Dalciel as we were looking into how we were gonna change the way that lighting was done in the Slip Space engine.

They have very awesome ambitions of what the game was gonna be and we wanted to realize their tools. And just going through and talking with them about like how they operate, it helped me figure out that I needed to go back and sit down with them and give them an example project or like a sandbox for them to actually do Like actually walk through it for them to and then not write it as like, here's what the program does And it's like, no no. If you wanna save your work, like, basically, write it from the perspective of a user. I wanna save my work.

Here is what I do. And then I click here, click there, a little bit of screenshots for the visual learners. Right? While at the same time, like, transcribing everything for the for those who are kinesthetic or, like, they have other methods of learning, and then just go through it.

And after that, it was just, like, smooth. Right? It was pretty good. At the same time, as we were observing what they were doing, we unearthed pretty good collaborations of how to improve.

For example, I have with the same group, we were talking about how lighting was done in the engine and Josh tells me like, oh, I played this light like this using a very difficult interface that was just like dragging sliders to try and put things in front of the camera and they have to do a lot of like mental work to figure out like three d space movement.

Yeah. Up in there.

Using sliders instead of dragging and dropping. And then Josh tells me, yeah. So I do that, place all the lights in where I think it's gonna be and put the intensity, like, think it's gonna be looking. He had been at the engine for such a long time that he had a pretty good idea how to light it.

But then he's like, yeah. And then I press burn, then I go and play ping pong or go grab a sandwich. And I'm like, do you not realize there's a problem? He's like, you don't get to see your result of you.

He's like, no, that light has to calculate and burn. I'm like, woke. This engine should do this. Yeah.

It's like, it's very normal to have real time displays on other engines. So we started doing that.

And we gave him a visual, it refreshes automatically, burns really quickly in the game. And what I loved was that once I showed him the demo, he's like, now I had time to play ping pong. That was his complaint.

Yeah. That's the problem. Right? Excited.

In VFX, it's like that too. You're you're just sitting at your desk like watching some YouTube. Someone's like, what are you doing? Like, I'm rendering. You know, I just gotta wait.

Yeah. The the I'm rendering is the developer, I'm compiling. Yeah. So yeah.

So that was something that we had, and then it really clicked for me that I needed to learn how to put myself in the shoes of my user and at the same time include them as stakeholders very early for them to be able to have something effective. So Josh Marble, Josh Dean, Kevin Del Siale, we sat down. Kevin Magnussen, Laura Tiebels, we sat down. Was like, okay, let's actually figure out how we're gonna build this tool. And did a sticky note session and then everybody they told me everything that they wanted to be able to calculate automatically the zenith of the sun based on the physical possession of the ring. And I was just like, wait.

But it was a really good set of discussions, and then within like six months, we had we gave them a full time of day dynamic system that they could completely light the ring at night, day, dusk, afternoon with fog, without fog. And then, like, they were just elated. Right?

And then I made that I made a career out of it.

I made a career of, like, let's sit down with an end user, and let's figure out how we get to them with the constraints that we have. And it's been nothing but fulfilling, and that's why where I am now, reeducating people, helping build the tools of what is it that you're trying to do, and then let's build that.

If you made like the Louis Plessied reeducation center, like, do you do?

I reeducate people. But it's funny because like, I have the pleasure that I don't like to hoard information, so I give it away to people. Arturo Brenna from Keyframe Effects, he's sent me a message the other day. He's like, hey, when are you doing your Perforce fellowship?

Can I call you because, like, things are a little bit broken for me right now? And then I help him out. Right? Right.

I can give you the the entire instructions. It's how do you use the tools that is how the craft is really made. Right?

So when we were talking before this, you told me a story about a presentation that you did that was to both a tech team and an art team altogether about version control and the pipeline in general. And that you got really different questions from the artists versus the tech Like, they reacted completely differently to the same information.

Yeah. For that story, what happened is that we were introducing how we were gonna address Perforce and source control going forward in all the projects that we were doing for virtual production. I did the presentation twice, first for a tech team, which is like the back end IT DevOps. And they were excited.

They were like, this is great. But then like, how are we gonna revert files? How are we gonna lock this? The usual tech only questions.

It's like, they were immediately like, how does it break?

Sure.

How can I resolve when they break in panic and like, this person went on vacation and had the entire half of the files locked, what do we do?

And then when I went to the artist team, it was like, what do you mean I need to save on top?

What if I wanna get everything? Do I just check out the entire project? Which immediately, we're like, no. Never do that.

Just don't ever do Don't ever perform because then that's gonna be a world of pain.

And it was goes back to the message that I said earlier, I have to put myself in the shoes of the user and then tailor the presentations entirely of the education for that. Because a lot of the times, it's easy for me to go through.

I don't need to explain a lot of the concepts of what version control is, what a checkout is, like what a stash or a branch is in the tech team versus you have to spend a significant amount of time when you do that to an artist or somebody who's not Yeah.

Who's Definitely.

Just visually trained. Right? Like, was explaining to one of the artists, okay, here's how you do what a branch is. You can start drawing here, you save this, you duplicate it. And then you start drawing on top this part versus you on this other thing, you start drawing on the opposite side of the branch. Right? Or I was using a literal tree as a representation.

Oh, I see.

And there's like, at some point, you need to Yeah.

Put one on top of each other and then merge down. Like, I was telling them in like terms, like, you then enable Right. Do two layers and then you merge down and now you have the entire work. And they're like, oh, I finally get it. And I was like, okay.

Nice. That's cool. I like the idea of using, like, layers in Photoshop because you can turn them on Yeah.

And overlay them and stuff like that to And then you can even say it sometimes, this layer just gets used for this marketing material.

It never sees the light of day and, like, the actual final product. Right? Right. So you have that ability to, like, not model your entire drawing by separating your work. And then they were extremely happy to learn it that way that they can actually, oh, I can do my work safely and don't have to worry about really messing it up and being destructive.

Yeah. That's the part that once I got it was that why have we not been doing this all along? This makes it so much safer. You have more of this safety net, so you can be more creative rather than I think the way a lot of us artists approach it at the start.

This is overwhelming and complicated, and I wanna focus on being creative and not doing this. And it once you get over that initial hump, it actually frees you up because then you're like, yeah, I can try whatever. If I totally break it, that's fine. I can go back.

Or it's like, I'm about to try something risky. I actually just did that today. I was working on an unreal project. I was like, I wanna see if I could totally redo this camera system.

Let me save a version of this first Yeah.

And then now I'll make my changes. And I did end up rolling back because I screwed it all up.

So Yeah.

That's the magic. Right? And it's something that like, I was very open about it when I was doing my fellowship with Epic for the storytelling fellowship.

I think I changed something, like, one of the characters and it broke all my animatics. And I was just, like, didn't even panic. I was just like, okay, cool. Let's just revert it to the last time I remember it worked and then do my work again because I'm used to it. It's like, fine. There was a couple of unfortunate souls in the fellowship that did not know about source control and they just kept saving and then they're like, oh, all of a sudden my project doesn't open because they move a file.

Yeah. And they're like panicking.

Yeah. I've been there.

Right?

And that's why Arturo keeps bugging me about the Perforce Fellowship because of the time on the fellowship during the social hours, it was just me remoting into people's machines to try and like bring projects back Yeah.

From the dead. There's something that you have said, hey, I wish we could have done this before and I don't know why we never did it. And I do wanna address that because a lot of people are like, yeah, why am I not doing it when they go and hear us rant about this? Right. Let's be let's be real. There is overhead cost and overhead, like, not only of time, but money to actually set this up. Right?

Depending on your team, if it's something small, you can make use of, like, little git repositories or like the the free licenses that Perforce has. So you can create your user and your own like storage setup. Start downloading. Once you grow, you go through the path of like, hey, let's start setting up the accounts, getting our licenses correctly, and then start distributing your work.

Right? But there's an overhead cost as you say, hey, let me save that version. If I'm an artist on Photoshop, generally, will go save as and then continue. And then kinda forget about that other file that's there.

Versus, if you do have your PSD file source controlled, you have to go save, then it will show up as, hey, this has been modified, you have to go and create your there's like an extra thirty seconds.

Yeah. There is a little extra step.

And there's an overhead, but that thirty seconds could save you days.

Oh, word.

Yeah.

Right? And a lot of people don't understand that cost upfront. Sometimes, having that backup is good.

Some people cheat it by just relying on, let's say, they work on a Mac, hey, time machine, that's a form of version control. Right? It's just a hidden one.

Right. Or like sometimes if you put stuff in Google Drive or something, you can go back to versions. It's hard to know which one because it's just automatically making them randomly, but yeah, it can save you sometimes if you have that. It's just harder.

In my ideal world In that situation.

I wish this was something that was like, hey, welcome to like film school or like three d VFX school. Here's how you version control, day one. That's like, going forward, here's how you version. Here's how you set up your own little tiny server for all your projects that you're gonna be doing here. And then yeah. Because I've seen many students have panic attacks of breaking a project at last second.

Yep. So as a person who does scripting and has the capability of being more technical and writing automations and that kind of stuff, My mind, of course, when you talk about, oh, it takes this extra thirty seconds to submit a version. My mind goes to, is that something you could then automate for them so that you're kind of lowering that barrier even further so it's easier for them to work with? I know it might not be that out of the box because every studio is gonna have a different way they want it to work.

That is absolutely one thing that I do and I always focus on. If I myself am finding myself doing something more than four or five times. I can show you my Notion. Like, I used this thing called OceanOS.

Absolutely recommend. You will see that I will put in a task and then be like, automate this because I hate having to like do things repetitively. It's the way that my brain functions. I really go, ugh.

Yep. Like, it's annoying. So, I would write a little script. Yeah. It could be like either a Python script or even like a batch file to be like, if I double click this and I pass it like a file, it just does the thing that I needed to do.

I do know that I'm extremely privileged over the fact that as a technical person, I can sort self soothe that way. So Right. Like, I'm cheating in that regard. What I would suggest, if you're an artist and you're doing something very repetitive is, hey, talk to your team.

Be like, can I what's the backlog of nice to haves? Ask them if they have like a board for that. Can I contribute to that? And then be like, I'm doing this a thousand times.

Or let's say, I'm going through a whole bunch of blueprints and renaming. So somebody will you have a technical artist because it doesn't have to be a full developer. It could be like a technical artist that writes you a script, writes you a little Python blueprint. That will be like, you just add all your things or drag and drop and it handles that work for you.

I'll also say, as far as that goes of, like, the nice to haves requests, is that I did find when I was on the pipeline team in VFX. You know, a lot of times we're working on things that are gonna take quite a while and multiple of us have to coordinate about changing how we do deliveries or a render farm or something. But then if someone comes along and just mentions something that we think is interesting where they're like, hey, I have to do this over and over when I import these files.

Is there any way that you could speed that up? If someone's like, I think I could do that in like a day. I'm gonna take a day to do that because it's gonna feel good to have accomplished something that I know right away is useful, rather than just plugging away at this thing that hopefully eventually pays off. So even if you feel like, oh, I don't wanna interrupt, they might actually be stoked to get a chance to work on a little thing that you're gonna love.

And I am so glad that you bring that up because one of the things is like, it is a little dopamine hit that we're actually feeling like sometimes we have this significantly complex problem of, hey, I need to redo the entire physics system for something. Or, like, I'm translating, like, myself. I'm translating all these Vulcan shaders, right, from, like, DirectX twelve so it works on Linux for people to be able to render on real things in the farm. That's a significant problem.

And I could be spending like multiple weeks on it. And my brain, like, sometimes feels flogged out because it's like, I know Yeah. And I'm not seeing direct results of my changes. So having that little backlog, like, need to refresh my brain, make somebody happy.

You feel that little dope having hit, you were a contributor. And at the same time, it's win win on both sides. Right? So you get Totally.

Your workflow a little bit better. Right? And then me as a developer, I get refreshed. And on top of that, I can continue doing my tasks without feeling like, oh, I've been stuck on this for like months.

Right? So Totally. Yeah. So I absolutely I'm so glad that you bring it up and that's extremely important.

So that is something amazing. And one thing that I wanna add in regards to that backlog thing as well is that make sure that you you write it as here's exactly what I click. It sounds like silly. Oh, they'll be able to figure out if I tell them exactly this.

No. No. No. Here's what I click. Here's what I do. Here's what my expectations of it are when it works the right way.

And then you will make me and and me developer extremely happy because we have a full user story to actually track to validate that we did it correctly.

That is a key. I think something that can be a struggle is that the artist will feel like they need to know how to solve the problem before they can come and ask for the solution. No. Just get specific about what you want it to do.

Let us worry about Yeah. How it'll happen behind the scenes. Because we have that all the time where someone would come thinking, yeah, I heard about this type of database. I think if you used that Yeah.

This would work better or something. We're like, stop. Like, that's not Like, it's helpful. Like, we've got systems and places already.

Yeah.

And then makes us think it's like, oh, and then, like, a lot of people think like, oh, it's just you just add this or you add AI to it or you do all it's like, there's a lot of steps. Go and set up machines, we have to set up licenses, sometimes we have to get legal involved for certain things, certain plugins that we have to purchase. It's what I decide, here's what I wanna do, let us handle and make you a stakeholder, like, once we deliver it, you go and respond like, hey, let me actually test it because that's a little little snapback that I will say. Sometimes, do a lot of tools and then they just I give them exactly what they needed and then they'd never test it.

I'm like, well, you're just wasting my time, but Yep.

I've had that happen so many times. Yeah.

Exactly. It's the worst.

It's a bad feeling.

It's a bad feeling.

No one gets the dopamine hit that they want.

Exactly. No. You get it. It's funny. I'm so glad that you have done the artist to like pipeline scripters slash slide developer side of things.

I can feel the pain on both sides.

You feel everything, right?

So Yeah.

So, I wanna go back to this concept of looking for these things to improve. Because I think sometimes someone notices, oh, this is really tedious. I hate doing this each time. But then there's a lot of things like you mentioned where it's, okay, hit bake lighting and then I go have my lunch break or something while it's happening.

And they don't even think, oh, that's a problem. They're just like, oh, that's just normal. That's just a part of life. And so I wanna talk a little bit about how you go about identifying those things that are worth automating or scripting in your pipeline, as well as maybe how to determine which ones are not worth trying to do?

That's a very interesting question and I would say a lot of it comes from just simple observation. Like, experience observation would yield you a lot of that information because a lot of the time, as you said, like, people don't realize they have a problem in front of them because they're just used to that's the way that things work. Right? Right. A lot of the times, it's like, oh, I can render this and then it just takes that long.

And they just assume that, oh, somebody told me that it was gonna always take that long and they don't question that besides observation. I actually rely on something that I learned at a tools tutorial day. Tools tutorial day is an event that happens during GDC in which the people from the Tools UX Summit go and explain different concepts or different games that they have done. Right?

I had the pleasure working with Laura Tieples back in the day on three forty three, and she presented something called the tools tutorial day, the system of tools reducing the frustration in daily workflow. And the way that she presented it was so good. So, I'm gonna do my best. I hope that there's a link in the description, but I'm gonna do my best to actually give a resume of what she presented.

She said like, oh, you know, sometimes the problems that we have are like a stinky diaper. When you have one stinky diaper, it's okay. You're there, but it's like it doesn't stink up the room. It's just it's just there and you just keep kinda going over it.

But then, like, if you have several problems, which are several stinky diapers, it keeps growing until it becomes a mountain that it just, like, knocks out the entire area. Right? You you do notice that there's stools. But move that to into like business terms.

If you have a minute wasted here, two minutes wasted there, and things that just like, you know, the user just sits and does not respond, That frustration keeps growing. It translates to millions of dollars of lost time and lost effort and a lot of impact to the person itself. David Limbaugh actually talks about it in in one of his books of design and UX, I absolutely recommend, and if I remember correctly, it's called the Phillips effect of that, like, fallacy of time waste that occurs.

The way that I kinda, like, over time and over my years, I know it's been discussed as the three ways of development. Right? First one is like, think of the principles of your flow. It could be your development flow of how you develop or how you interact with your tools or how you program as an artist of how you create.

The flow of like, here's how I set up my files. Here's that. And then like, be critical about that. That's the first way of the development.

Right? The second one that you should add is a feedback loop or amplification loops. Right? To bring attention to those things that you actually want to validate.

It could be, like, track how long it takes you to set up a file. It tracks how long it takes you to get a response on something, and then you get your feedback. That's what we were talking earlier about stakeholders and how it hurts when they don't give us data. Is the same.

That's actually the second way. Yeah. And then the third way and the one that I find the most important to me, try to create a culture of continuous experimentation. So a lot of the times when we don't see those problems, it's like, hey, what if it were different?

That's all you need to ask. It's like, and then let's experiment. What if I have a button that outer rigs and that's how an outer rigger, came to be or like, you do all this topography cleanup and that operation is very, very common. So we build a script that do topo cleanup and that's in like basically every DCC nowadays.

Out of destinations Right.

Out of subdividers and like cleanup of all those things and Or like fix my normal Exactly.

Like double check if this is watertight. Right? Check if there's zero edge faces. And all these things that we take for granted, I guarantee you, they all started by a question of what if we do this? And a lot of the time, it's like, just looking into size and like, when somebody hits their keyboard, or you see them really going at a stress ball.

I see.

Yeah. And then you're like, what's happening?

Like, what's happening?

It's a little bit more difficult now in the COVID times in which we go remotely, but it's like, are they saying, like, multiple times a day, I need to go for a walk? I guess, this is BS. How I used to pick them up at the workplace is it will be like Junior would be, like, sighing and complaining that they couldn't figure it out. And then I'll just be like, dude, what's up?

You know, what's going on? Actually, was one day at the VFX studio when, you know, we were all in the office back then and like all of us suddenly started being like, what what is that sound? And you just hear this like over and over and like all of us turn and it's one of our coworkers having to do something that just involves clicking his mouse over and over and over and over and over again. We're just like, dude, there's gotta be a better way.

Sometimes that happens or, like, an example is, like, manually somebody had to type in a series of commands to take a screenshot for all the marketing materials on Halo. Great.

To like Oh, ****.

Compress it and do a whole bunch of stuff. I was like, no way, man. It's like, we're gonna build something that if you pass it a JSON file describing everything, would just go through and give you materials. We that's what we call we built something called the darkroom and then that's what's powering all the live events.

Right? All the little, like, icons and stuff like that. It used to be done manually. It was brutal.

Yeah. Wow. And all the balls are like, wait, what are you doing? Why are you doing it that way?

Right. Who told you that you had to do it that way?

I love that. That's awesome. So as we're approaching the end here, I know we could just talk about pipeline ideas the rest of the day, but as we're getting toward the end, you've clearly had a journey that's taken you many different places. But if you could go back in time to yourself, let's say, starting from the time where you're starting to work in pipeline. Right? You're starting to work with artists and tech people and build that. What would be a piece of advice or a suggestion or direction that you would give to yourself back in time then?

That is an excellent question. If I could go back in time to the early days of my pipeline days, I would tell myself to pay attention to failure.

Because a lot of the times It took me a while to actually see failure as a beneficial thing. Not only understanding the human condition of, like, we actually don't learn from our success. Right? We rarely Unless you're, like, a high level Olympic athlete, but you're like, okay, how do I perfect that even more?

We're like, yeah, that worked. Good enough. We're as a developer, if you coded something for an hour and then you just hit compile and it worked and it did what it did, you're like, oh, I'm a programming god. You do not go and think how you can optimize it.

You do not think that there's gonna be anything else wrong with that or how you're gonna improve it. You just move on.

Yeah.

So pay attention to failure because failure is not something that you should feel really bad at. It's a learning opportunity. If we put our hands in a fire, you immediately learn, don't ever do that again. Right?

So the same way Right. We see it in game development or film development, like the first time you check out the entire project on a Perforce thing and block the entire studio. I've deleted databases by mistake. It's things like that.

You, like, observe my failures and be like, to tell myself it would look painful and you will be embarrassed and uncomfortable at times, but the best learnings that I'm about to have throughout my career will come from my failures and pursuing that failure to the part that I learned. Learn to fail gracefully, fast, and effectively so I can learn more. And it's something that I actually go and tell everybody. I had the pleasure of being a lecturer at the University of British Columbia.

It was hilarious when I tell the students, just fail. And then, like, the dean was like, no. I was like, that's how you learn. These are environments in which you will be better.

If it weren't for that, I honestly will not be here because it it taught me to be uncomfortable and pursue things that I didn't think it was possible. If you were to ask me when I was a kid, Luis, you were working on Halo on Age of Empires, Age of Mythology as a person coming from Latin America, immigrant, right? I would be like, yeah, you're joking. Like, and in fact, I have friends in you from my high school that I talked today that they're like, dude, we thought you were nuts.

Look at where you are now. Right?

Right. It's something that's very very awesome to see because, like, if I didn't shoot the shot, I would not have done half of the things that I would have done till today. So fail, be there, and then just, like, you know, experiment. Focus on your own growth and how do you contribute to those around you with your failures, and then, like, that would have been, like that is what I want to tell myself.

But then I would have avoided a lot of Yeah.

Could have saved you some years of failure.

Yeah. And at the same time, I feel I would have actually learned to, like, not give up on certain projects that I had earlier in my career to optimize myself because I was like, oh, I'm too junior. They're not gonna accept it. And then I'm like, yeah, I was an idiot. Look at that. I was like, built that and sold that as a plug in now. So it's like, they definitely wanted it.

Yeah. Alright. So my next question is this industry. And I guess this industry, meaning both gaming and media, someone who's just getting into this industry, maybe they're considering getting into the pipeline side of things or maybe being like a TD, technical director, doing some kind of scripting, what would be your advice to a person in that position?

The first thing is don't limit yourself to I'm going through film, and then I had to only learn film because a lot of the things are converging in the assets Stacks that we're doing and a lot of the learnings are coming back and forth. We're doing more cinematic things in games nowadays and we're doing more game stuff and optimization stuff for film because we need to leverage existing technology. That's number one. Right?

And then the second thing is going back earlier is just learn to put yourself in the shoes of the person that you're actually working with. Try to figure out, like, you're gonna be new and you're not gonna understand a lot of the terms, and that's gonna be fine. That's not a deal breaker. In fact, I think that's great because then you'll be able to openly do very naive questions that will give you a head start.

Yeah.

Don't Yeah.

Don't hold yourself like, oh, let me not ask this question because I'm gonna look like an idiot. Sometimes, it's really good to ask the idiot question, which I don't believe there's such a thing. Yeah. Because at the end of the day, if somebody can explain in terms that anybody can understand, that means they have the full domain of the knowledge that they're trying to impart on you. Or if you learn those naive questions, you'll be able to actually impart that knowledge because you'll get full domain knowledge of it. So and then I'll reiterate, don't limit yourself because gaming and film and interactive transmedia and automotive, commercials, I've seen Unreal being used, for example, in so many of these things, medicine, physics simulation, aeronautical space even.

We just did a webinar last year with NASA team that's using Perforce and game engines together to do simulations. Right.

Tesla's run on Unity. So it's like, it's everywhere. So like, all crosses over and that space is great. And then don't shy away of learning those tools. A lot of people are scared because AI is taking the world by storm. Those aren't just tools to do the work.

They will help you accelerate, but remember to critically think about what they're I did have one fun tip for anyone who does want an excuse to ask those idiot questions or to have those conversations and you don't wanna feel dumb about it, you can whip out the term domain driven design or DDD.

That's something I found out about when I was working at the VFX studio doing pipeline stuff. And then I was able to go to the owner of the company and say, hey, so I wanna employ this framework called domain driven design.

What really just meant I wanna actually have meetings with the people who are using these tools and talk to them like they talk about it, not forcing them to think about it the way I think about it.

It's like, hey, just wanna ask some dumb questions or waste of time for a little bit.

Yeah. Yeah. Yeah. Exactly.

I promise something will come out of it. Oh, that's that's that's a very good piece of advice. Fancy words usually do get you to lots of good places.

Awesome. Well, this has been fun.

Thank you so much for joining me today, Thank you so much for having me, Jace.

This is something that has been amazing and, you know, you and I can talk about this for hours. So and if anybody the same wants to reach out, we'll put my LinkedIn information hopefully on the channel so we have that. And then feel free to ask questions. There's no such thing as too dumb or too basic of a question. I'm happy to answer it.

If you enjoy this kind of in-depth conversation with leaders in the media, gaming, and visualization world, be sure to subscribe so you get new episodes as they come out. Subscribing and giving a review or rating is the only way that we know you enjoy this content so that we can keep making more of it.

Reach out to me via email or LinkedIn with feedback, guest suggestions, or to connect if you'd like to be a guest yourself.

I'm always looking for great stories and I love learning about the many ways game and real time technologies are being used today. Links for that are in the episode description. Be sure to check out perforce dot com for information about our full p four platform based on the industry standard perforce p four version control.

Special thanks to our production team, Ella Reiswig, Kaylee Torres, Luisa Puhala, and Chris Perez. I'm Jace Lindgren, and I will see you next time on in development.