Pioneering Real Time Tools with Andre Gauthier

Announcer:

Today on Building the Open Metaverse...

Andre Gauthier:

Unity is transforming and slowly introducing those things into the engine, where you get the segmentation. You can load the data, separate the processing from the information, and actually think about your game in such a way.

Announcer:

Welcome to Building the Open Metaverse, where technology experts discuss how the community is building the open metaverse together.

Hosted by Patrick Cozzi from Cesium and Marc Petit from Epic Games.

Marc Petit:

My name is Marc Petit. I'm from Epic Games, and my co-host is Patrick Cozzi from Cesium.

Hey Patrick, how are you today?

Patrick Cozzi:

Hey Marc. I'm doing fantastic. I always love to chat with pioneers and learn a lot about the history of where we've been, and where we're going.

Marc Petit:

Well, we have a true pioneer today. We're happy to welcome Andre Gauthier.

Andre was the former founder of Kaydara, the makers of FiLMBOX, and then MotionBuilder, and has been a software architect at both Autodesk and Unity.

Andre, we're super happy to have you with us today. Welcome to the show.

Andre Gauthier:

Thank you. I'm happy to be here.

Marc Petit:

You may know that we like to start the show by asking our guests about their background and their journey to the metaverse. So please tell us about yours.

Andre Gauthier:

All right. I would say that my 3D adventure, that part, started with a company named Kaydara.

In 1993 we founded a company, Michel Besner, and Sebastien Lavier, and myself, founded a company named Kaydara. Then we started working on a product called FiLMBOX, which eventually became MotionBuilder.

What we were interested in at that point was we made a contract with Productions Pascal Blais. We were dealing with a motion control camera, a two-ton camera that needed to move in space, something, and there was nothing to drive it.

Working with them, we created a kernel that would make that camera move in space, and I got fascinated with the idea of the virtual world meeting the real world.

Talking with Michel and Sebastien and saying, hey, let's make a business out of that. We were doing consulting for Softimage to pay our bills. While Michel and Sebastien were consulting there, I was building the kernel.

We started this adventure. We ended up in the motion capture. We ended up building these things. At some point, we had to exist in the 3D world. We created a format that was the FiLMBOX format, which was called FDX, and we needed to transfer information to and from. That evolved; we ended up being acquired by Alias and then at Autodesk. So that's where we saw each other, Marc.

Marc Petit:

Yep.

Andre Gauthier:

Then, through the adventures after that, did some stories into cloud, and some aspects of dealing with general storage something, came back to Autodesk, and finally started the Montreal office of Unity.

I’ve been doing that for the last 10 years. I'm just leaving that position right now and then looking at what I will do next.

Patrick Cozzi:

John Gaeta is also one of our guests this season, and FiLMBOX played a big role in the making of The Matrix, back in 1999. Could you tell us how it was used?

Andre Gauthier:

Yeah, it was interesting. Like I said, we got interested in the hardware side of things, so how do you connect the virtual to the hardware part?

We started with this motion roll camera. Then we ended up in a studio called Magiscope. They had a polymous system. It had a magnetic ball with sensors, something. We wanted to connect those things and get the data out of that, and it was all distorted. Those things were warped by metal.

We said, hey, we need to correct the information. So we started doing the drivers to record those things, and then we were looking for everything that was actually device-related. We ended up talking with production from Matrix, and they needed to do this rig with 130 cameras. We used fixed camera rolls, and they needed three of those things in real-time and making those things take pictures, and did that.

We ended up adding that to the punctuality of FiLMBOX at the time, and we ended up driving everything that related to those famous shots. Obviously, we did the hardware part of that, they did the hard work,  which is cleaning up the data after that, and actually do something useful out of this.

Marc Petit:

It's interesting because there was MotionBuilder; I mean, in 2002, FiLMBOX got renamed MotionBuilder, as it focused on motion capture. It was always about real-time, and it has that in its DNA and got used for motion capture, performance capture, and, interestingly, even virtual production.

We may remember that MotionBuilder was at the heart of the first Avatar Visual Production System at Lightstorm, back in the day. Is there anything specific about that architecture that gives this real-time support to MotionBuilder?

You could not find… I mean, it hasn't been replicated. There is, MotionBuilder's still alive, and there is no application actually can do what it's been doing.

Andre Gauthier:

We really thought about that data flow and the capture of the system synchronization, and everything. 3D was just a side effect; it was visualization for us. 3D wasn't at the heart of what we were trying to do. We're trying to capture all those events.

The idea of FiLMBOX and it, stupidly enough, in '94, '93, we say, we want to be a part of the set, recording, the lights, and controlling the equipment. That was the dream. I don't know if there was a huge market for that, but, at that time, we thought it was a fantastic idea.

The whole kernel of MotionBuilder knows about when things happen and synchronize, and then brings the data, and then it's completely decoupled for the rendering, and the rendering picks up the information when it needs it for the specific frame they need to record.

That was kind of the bizarre aspect. We could synchronize with decks, tape decks, and pre-rolls, and videos. We really were interested in making sure the data was timed correctly, and nobody did that again. Film does, specifically, in some aspects, but as a commercial product, that was a special aspect of the product.

Marc Petit:

It looks like you had more potential that never got really realized, and had to wait for 10 years for game engines to pick up the real-time agenda.

Why?

Andre Gauthier:

It's a niche problem; MotionBuilder was answering that one. The place where MotionBuilder didn't follow-up, was, obviously, as it's niche, you don't invest the same way in those products as you would with general products.

The game engines were really, really good at the simulation aspect, the rendering. Obviously, the rendering got updated. I think the last render of MotionBuilder was updated in 2006 or something.

Essentially, visual aspects were there. Then more and more people want to have the visual realism that they have in games, was super, now it's amazing. We're closing the gap between software rendering, and real-time rendering. I think the gap is in this data recording, data assessment part of the thing. Studios are fixing that. It's still not necessarily yet a priority for any game engines because it's still niche.

People are finding solutions to make sure that they fix that part of the problem. But obviously, the rendering and the capacities of the game engine draw people toward them. It makes a lot of sense.

It's funny; we were in a meeting where I got told, we need to replace FDX, we need to replace MotionBuilder. I was at Unity, and they had to say bye, whatever, Unity and Unreal, and we need to replace all those things. I was smirking because it's standard, a nice thing to be said.

Marc Petit:

Also, for the record, remember Project Sextant? We did an attempt to build more capabilities on MotionBuilder, back in the day-

Andre Gauthier:

Yes, yes.

Marc Petit:

... and for some internal reasons, it did not see the light of day. I have some regrets. I mean, in hindsight, we were down the right path, and we just were not... But it was a financial crisis, 2009; it was hard to invest at that time.

Andre Gauthier:

But those things will reappear.

AR and some of those problems show up in new ways which aren’t niche, so they will come back in other forms and in other shapes.

Obviously, those problems will be the same. If you want to integrate yourself into some kind of a real-time environment, you need to mind the moment where things happen, what you're doing versus all of those things. It will, in another form, with a lot more market behind it, essentially.

Patrick Cozzi:

I believe it was maybe 1996 when you released FBX with FiLMBOX 1.5. Then, over time, you released an SDK, with this focus on interoperable 3D scenes and objects, especially around animation.

Even though the formats stayed proprietary, they did become a de facto standard. I was wondering if you could maybe bring us through the journey of FBX, then also tell us if you ever considered even open-sourcing FBX.

Andre Gauthier:

I would've loved that.

FBX was born, FBX, which is FiLMBOX file format, what it was. And the first part of FiLMBOX was running inside Softimage as a plugin because we didn't want to do the 3D part. We wanted to do this data part and the recording part, and multi-threading part, and all of that. We ended up not being able to do that, because when you run inside the 3D software, threading and, anyway, so it wasn't trivial; we have to separate ourselves from that.

We needed the information, and we weren't a modeler, weren't a renderer, weren't any of that. We needed information in. We started writing plugins for Softimage and the PowerAnimator at the time, and it was Alias, not Alias… the other one is Lightwave.

We started wanting to get the information site, FiLMBOX at the time, and display that information, and we started with simple models, and we needed textures, and then we needed the formable things, and then we needed to capture the recording of the animation, and then we needed to send the animation back.

We created plugins and then slowly, just for our own survival, had a plugin for the major, the three major first three packages. Once we got, I would say, decent at that, people started actually exchanging between themselves.

It's not that we had the vision of the file format for everybody, it was just for us to exist, and we wanted the visuals to be as good. When we were working with studios, they wanted to see the things that looked like what they had in their 3D packages. That's how it evolved. The more you start solving those problems, the more you realize it's complicated. It's actually non-trivial.

After that, as we got acquired by Alias, Alias got interested in FBX. When they wanted to use FBX in other products, we started auto studio integration and others.

Then when you guys came in, Mac, as Autodesk at that time, was then Autodesk, we did that, or AutoCAD and Revit. Then FBX took on a wider set of problems. And we had to deal with the integration of all those products, because 3D information has no standards, it didn't, and it's a complicated standard. We have to start to fix that problem. It took what, I would say 14-20 years for this thing to actually be usable in a way that makes sense.

I would love to say it’s like the phone. When a phone antenna doesn't work, it's like your phone doesn't work. When it does work, you don't see it. But everything that needs to happen for this thing to work is crazy.

It took us a long, long time to get to that. Through those experiences, at least the format became good, and I think it was when we got to Alias/Autodesk that it started, and slowly people used it more. We got to invest a bit more. The team was a bit bigger, so we could actually start doing something with this.

Marc Petit:

What about open-sourcing it?

Andre Gauthier:

Okay, so that, well, at the time, there are F curves and all kinds of tricks and things, so I'll just stop for a moment, one or two minutes, about that specific thing.

People don't understand the level of problems you have when you transfer data from one package to the other. A mesh is a mesh, is a mesh, and animation is animation, is animation.

The problem is if you're Y up, Z up, left end, right end, if your U alert ZYX, YZX or something, as soon as you start moving that data, the package where you go, doesn't understand the world the same way, and you need to transform that data in a way that makes sense.

One specific example, I'm using the simplest of it is the field of view for a camera. There's the field of view and focal length. If you think about it, the focal length is a distance, and the field of view is an angle.

If you animate a focal length with bias curves and then you need to transfer that to a focal view, not an angle. You cannot transfer the keyframes. You need to re-sample the whole thing. You need to manage all of those. Nothing is simple because it requires a kind of knowledge that nobody has. It's not all, my God, “I know this is how you transfer YZXU alert angle into this.”

It becomes extremely specialized knowledge that needs to be there, in order for the data to make sense.

It took a hell of a long time to actually do that. I would love for that knowledge to be transferred; at the time, with Autodesk, everybody's a bit worried about IP, or is this part of MotionBuilder, are we giving away special sauce? I don't think we're in the same situation at all right now. We're interested to re-engage with those companies and see if we could actually extract that, and then give that to the community.

It would be sad if we resolved the problem that we solved, I don't know, 17 years ago, again as we're doing with new formats and dealing with those things, because they have the same problems. The problem hasn't gone away.

Marc Petit:

You know Patrick and I, and a bunch of other people, are involved in the Metaverse Standards Forum, where we are trying to align things like USD and glTF and establish a common basis to enable less loss to our probability.

A lot of things you mentioned, do you think they could be lifted from FBX, and brought into the wall of USD and glTF, to accelerate the roadmap there?

Andre Gauthier:

I would really love that. Yes, I think it can.

It may be a good use of my time in the future months to try to start to talk to a few people and sit. But for me, I was a bit disappointed because we're tackling a lot of difficult problems, and the problems of the metaverse have a new set of new problems that are there. Making sure that we combine the forces that are already there to help drive what needs to be there.

In USD, you can have no translation and rotation in any order. It's great when you write a file, but when you read it, then you need to interpret all those things in your context.

If we can help people build what that would be, I think it would be really useful.

Marc Petit:

Yeah, it's interesting. I think people feel ready to tackle F curves, function curves, finally, 30 years later.

Andre Gauthier:

Well, we'll see what we can do about that. But at least I'm happy to bring the knowledge or conversations all of that with this.

Hopefully, we can actually pull the code out. That would be great.

Patrick Cozzi:

I believe back in 2004, Kaydara released HumanIK, a Metaware library that included the MotionBuilder IK solvers, then also a model for defining characters. That model really became a de facto standard in the industry, and it allowed folks like Stefano Corraza, who's another guest this season, to create a very successful MoCap library.

We would love to hear your thoughts on how we take this further, and can we one day standardize avatars?

Andre Gauthier:

What was good at that moment was under your governance, Marc, Autodesk.

We decided that we would carry the full body description coming from MotionBuilder, the two other products, which were Max and Maya. That's where a lot of animators would do that. And we already realized that for FiLMBOX, MotionBuider was a market for the game companies.

We already had packaged the solvers for the full body IK to the game companies, because they send for it. It was already extracted and something. Why not leverage that so that authoring could move away from one package to another?

You mentioned it really well. There's a description aspect of it, and there's a solver aspect of it. This is a hand, this is what it is, this is what it looks like, and you get in all kinds of trouble because what is the hand like that? What's the angle, when that's, so standardization and orientation, it's all that. That was part of the information that was useful.

The second part of it is actually solving, as we move those things with IK and something how this solver reacts and moves the character. How do you transfer that data to the game end? Because how does that authoring then exist somewhere else in another space and then react correctly?

The simple part of it, the description, moves really well. The challenge is when a solver changes over time; one parameter changes everything. You don't support that parameter. That parameter is on, the effect of that thing will be different.

As you start to deal with standards, then your description is interesting. Solving then, version of solver, where it lands, where it goes, is something that has bothered me for a while. We've struggled with that. We were releasing Max and Maya at the same time, and then the solvers weren't compatible, and then people would move data from one to the other, and they weren't doing the right thing.

We started releasing the solver at the same time as the plug-ins. You realize that you need to think about the software in a different way.

Marc Petit:

You spent 10 years at Unity and said you just left to do other things.

I have a few questions for you. The first one would be, so you created that Montreal studio, I think. How big is it now? It's 300, 400?

Andre Gauthier:

No, it's a thousand now. It's pretty big.

Marc Petit:

A thousand people? That's crazy. I know you are very careful in building up the studio with a certain culture. Can you speak to that culture? What was your vision for the Montreal studio culture at Unity?

Andre Gauthier:

It's a bit selfish, but I wanted to create a place where I wanted to work. I think there were a few things that we were looking for, especially when we were interviewing the leaders at the beginning.

What I wanted is, first thing, I was looking for is curiosity. Essentially, people that are actually wanting to make a difference and have curiosity for something.

Then experience, I was looking for experience. But the problem is when you get experience sometimes you get jaded. There's some that go, “I've seen this,” and you don't want that. That's not the spirit.

You want experience, and you want that curiosity.

But the last really, really, important part for me was kindness. Actual kindness and interest for human beings. We would interview people with that.

The way the Montreal studio started, is a conversation with Joachim and David, at the time, was CEO, and they go, what do you need? It was kind of an independent business, find a place, hire people.

It was a privilege at that time; it was kind of a startup with a non-startup with everything about the Unity brand, and the Unity product. It was great. We could do and decided to do this.

We did that. We hired the leaders, and then as we grew, the culture propagates, because I always tell people, you have the company you deserve.

If you want to be treated with kindness, treat people with kindness. If you want curiosity about what you're trying to do, treat people with curiosity. That was kind of the heart of that. It became extremely warm as a culture.

When we were interviewing people, I was always interviewing the leaders. I was the last interviewee, making sure that we had that culture of that. We were meeting every single employee as they were coming and talking about that.

Talking about the responsibility of that, because it's not just the responsibility of leadership, it's also the responsibility of everybody coming in. You want to be treated like that, you need to be open. Especially these days, a lot of people are rage or angry and something, and that is a way you end up with the place where it looks like that. I think all of those things made it fun, made it with creative people, and they were entrepreneurial by temperament. It was an interesting, really interesting ride.

Marc Petit:

If you think about your stint at Unity, you were initially focused on animation with Mécanim, that acquisition, Bob Lanciault, and the gang. Then you basically took charge of the editor, but then recently, you were VP of technology, and you were actively involved in ECS/DOTS, the NTT component system, and the data-oriented tech stack.

Can you give us a quick primer on what those technologies are? Why are they important, and the potential benefits to a game engine like Unity?

Andre Gauthier:

It's interesting, I evolved from the editor part. I had a conversation with Joachim and Mike Acton at the time. Mike was, I would say, almost an ECS activist. He believed in that profoundly, and we had many conversations. The way he articulate those things were really, really, I think, forward-looking, in ways that are, I hadn't thought about.

I was taking care of the editors, something, and I started minding, what we call runtime applications.

Runtime applications are any application that is created using Unity, but it creates an app. It's not a game; it's an application, essentially. Either for the building, the construction market, or for architecture for something. Using Unity to build an application that uses Unity. It's such its own thing.

I started looking at this, and I realized that most of the problem is in making sure that the information is what you care about.

In a game engine, when you're by yourself, you build all those things together. You both build a code and build data, and they're all jointly… what was interesting about the DOTS proposition, it says, separate the information from the process. If you start looking at that, because normal C#, C++, code, mix objects, and all those things are intertwined. If you look at the web world, the web world works with databases and then code queries databases, does something, and puts data with databases.

If you think about a game, that's what a game does. A game you have, get me all the players, querying environment, what is happening? Who are the things I'm interested in? I'm interested in the enemies of something. Okay, good, get them too. All right, and what about the world? Where are the closest friends, enemies, or something? You would do a query; you process information, you provide any information.

What was interesting is that segmentation brought those concepts back into the game engine, in a way that is performance. Because obviously, in a game, an SQL query wouldn't be that probable. It does for some aspects of that, but that was where the interest was.

Unity is transforming, slowly introducing, by a lot of work, introducing those things into the engine where you get the segmentation. You can load the data, separate the processing from the information, and actually think about your game in such a way.

That's what made the web, the web. This way, you can have a lot of services with central information. And those services can evolve over time, and it really is a good pattern for what you need to do.

It separates the file format problem from the code problem, and it allowed everything to be performed. I started to be interested as I was looking into runtime and then talking with Joachim and Mike; they say, come and join us. And then start minding that, trying to harmonize that story around what we were trying to do.

Patrick Cozzi:

I wanted to ask; I have some battle scars myself in terms of shipping a product regularly, but then also trying to transition, and upgrade that core technology.

I was curious how they're navigating that and how it is going.

Andre Gauthier:

It'll always be a debate, so do you write a new one, or do you refactor? Both of those things are painful. In one case, you carry your bugs with you, and then, or you say, no, no, no, or you're reinventing. When you reinvent it, you forget about things. Just send us three use cases that we haven't thought about in the new thing. You end up with two systems coexisting for a long time.

In this case, what we ended up doing is side by side. Both can exist.

You decide how much DOTS you're doing more and what it is about. But if you look at the evolution of Unity, the complexity of Unity, it supports 20-some platforms. It has tests and suites for all of those things. Every time code is checked and tested against the biases and all those things.

You need to evolve that at some point; you need to retire some of those, and then you need to tell the customers that you'll do that. How do you do that? Pick those generational, pick four, pick three, pick four, pick five. You need to tend to be more continuous. I think it is a combination of that.

You need to be able to deal with the breaking change, but it means that you need teams to maintain both the old and the new. There's no simple answer to this one. I would love to say we sat down, and wise people thought about it. No, it isn't. You need to upgrade APIs, and you need to decide how much pain you will throw on your customers, as you do all the building.

The good part is productions tend to stay on a given generation, and they decide if they hop on a new one, and you need to be synchronized with them to know when they can rely on you, the next generation.

At least there are generational breaks also with the customers. But it means that you need to maintain the old things, because they may stay on their start for a long time.

Marc Petit:

How did you interpret the key capabilities that made the success of Unity? When you look back at why does this game engine become so popular?

Andre Gauthier:

At the heart of it was the appearance of the iPhone, at the heart of the beginning. It was a game engine on a Mac, who did that? But the iPhone appeared, and it made it for an opportunity, that nothing was doing that, and then Android something.

If you look at the extension of that, it means device support. Device support is really hard.

You're probably living that joy yourself, on your end, Marc. You get that weird device that supports, I don't know, Windchill 1.0 on something, and so happened the 700 million people having it.

The first strike gaming was multi-device and the fact that we did support that.

The other one is that you get running really quickly. You come in, you start to drop stuff, you type a few lines of code, and it runs in the editor and data changes and databases was, at its heart, what it is. There's a simplicity to it, and there's that.

Now it expands in different ways because it is becoming bigger. The quality of the renderings is reaching out to new kinds of standards of the industry. But at the heart of it was, the fact that it was accessible, and it was reaching all devices, and that it was accessible both for the creators and, I think, that is the heart of it.

Now with the DOTS and something, it is about scale, scale projects, something.

If you look at Epic, it started more in the high-end part of the world. Then Epic, it's needing the devices as it is going down. I think Unity's coming from the other side. It's just availability for everything, and then reaching out to a higher end-version of all that.

Marc Petit:

Let's turn the lens. What's the next big thing for Unity? How do you see what's going to define the engine in the future?

Andre Gauthier:

There's scale content, scale generations. That's one big aspect of it. The other part is, what is happening with the industry in the digital twin, or another version of the term metaverse?

Okay, so AR is coming in; AR won't be a fluke. If the devices are already happening, they're not, your phone is not a great device for AR, and wearables will be. Obviously, the big ones will do good wearables. It will replace the phone eventually.

It's obvious, because as you look at the world you'll have the information.

As that is happening, then it means that consumers are looking at 3D in context. Builders are building 3D in context. Already, the industry, as you know, is doing car generation demos and all of that. That's the whole other super thing that is more related to the real world, real objects, in a retail/experiential creation environment.

It's true for Epic. Looking if that's true for Unity also. It's true for Nvidia, and it’s true for people looking at this. They see that the virtual world will meet the real world. We don't know exactly where it will tie in. We have few hypotheses, but so I think that's true for Unity, that's true for the whole industry.

Marc Petit:

I remember a few years back; we discussed in-place editing. I think it's a very important concept. Because the metaverse is going to be a permanent 3D world, and augmented reality is our real world, which is persistent by definition.

Is that something, that you still see as part of the vision?

Andre Gauthier:

If you look at where that will go, it means that the object we will want to create will need to exist in all our realities. Some of them, not all of them, some of them. And what does that mean? It means that the appearance of the thing needs to be able… so multi-platform becomes something a bit wider as a, it's not I run on iPhone. It means I exist inside Roblox and inside any virtual environment because I need my thing to be able to exist. What does that mean? It means something about the appearance of the thing, but it also means something about how we simulate, what's the behavior of that thing. How do I make that one? And because it will be, it will work in, how do you call it, the castle? There's an expression about it, walled garden. It will work in walled gardens for a while.

At some point, consumers will want those things to exist across those things. I think, as an industry, this is where all standards become interesting.

How do we make those solvers able to behave in that environment? There are already hints of how to do those things, because new problems, a new problem in that context, will be under progress. I think that is what is in front of us. If we together are able to solve those things, then we'll start to be able to carry those objects from one place to another.

That's the dream of all of us. How do you author those things? You're right. You want to author that in place, in my environment. I want to be able to do that. I want to author that in a place with my skills, as I'm a professional animator or I'm a kid, I want to make my character walk.

I probably won't use the same techniques, no. In one case, we'll use AI, and I'll use my phone; I’ll record my movement, and I'll want that to be capable to do what I'm doing. In some other cases, I'll be a lot more specific. I'll use different tools, and I’ll be able to do that. But you want to be able to add to that metaverse, in the end.

In-place editing, how we run those solvers, and how we actually transform that information, is, I think, at the heart of what we're trying to do. I'm not sure every industry is thinking about that this way, because everybody right now is trying to mind their interests relative to this. But as a group of people thinking about that, I think these are the problems that we need to solve.

Marc Petit:

You mentioned, in a world where you need to create something, it needs to last forever, standards are going to be even more important.

Andre Gauthier:

Yes. That's why use is super important, as part of that.

I think there's a set of conversations that will be interesting to look at as the few of us and more and more people that have tried to do that in the past have a few roadblocks. It's not that they're impossible problems; they’re actual solvable problems. But creating awareness of those problems, and starting to think about those problems collectively, I think would be wonderful.

Marc Petit:

Cool. It’s an interesting moment in your life; you just finished a very successful stint in a major company. What's next for Andre Gauthier?

Andre Gauthier:

We talked a bit, create mind space first. Because when you're in one environment, you take the problems and you try to apply them; you require them all the time. Then you become, maybe you lack perspective, remove my mind out of this, and then I want to pick up those problems again, but with a different light and see if we could help.

Some companies are a bit more myopic, relative to those problems. Some companies are a bit more wide, relative to that.

I'm curious to see how, I would love to use the expertise and things I've learned, in order to actually bring that forward. I don't know in what context yet. I want to engage in conversation with different people and see where we're at, where we see the problem is, and try to help in one way or the other.

I think, then, elimination will happen. But right now, it's more about being inspired and giving space.

Patrick Cozzi:

Andre, look, thank you for sharing all these stories, your passion, and your insights.

To wrap up the episode, we'd love for you to give a shout-out to a person or people, or organization.

Andre Gauthier:

It's not this specific, because of the privilege when you work in that industry; the people you meet are crazy. You've crazy brains everywhere. I mean, really.

Let's not resolve problems that we already solved. Let's try to actually get the industry to collaborate.

I would love Autodesk, Alias, Unity, and Epic on the things that aren't... let's actually get together and get those things out of the way, so that we can run our business and do what you're great at.

Marc Petit:

Andre Gauthier, thank you so much. You've contributed so much to our industry over the years through the work at Kaydara, Autodesk, and 10 years at Unity. Thank you very much for being with us today.

And thank you very much to our listeners. We're super happy to have you with us!

You can reach us at our new website, BuildingTheOpenMetaverse.org. Send us an email at feedback@BuildingTheOpenMetaverse.org.

Tell us what you want to hear, and what you think about this company. Thank you very much, Andre. Thank you, Patrick. And thank you, everybody.