B (3:54)

Yeah, that raises a lot of questions, I guess. First one, before we get to in the weeds on this, I want to give you a chance to talk about what you particularly do. But one question on that. So you said you're always working on that latest main, and I imagine with that goal of trying to make sure you're always testing the latest stuff that puts. How many projects are you doing a year? Basically? I guess they must be quite. They have to be quite short to keep that goal relevant, right?

C (4:13)

Yeah. So it really varies. Like we've been doing some longer projects, I think on average it's been about a year for one project because we're a relatively small team and we have like long cycles of preparing the production, doing the production, and then we also do other stuff in between. Like we also create educational content and blog posts and stuff like that to actually share that knowledge. Because it's not just the content creation that takes up a lot of time, but sharing that is also something that you need to actually actively put time into. So it's been more of like one project a year and then some stuff in between, but more recently been trying to speed that up and have like a shorter iteration cycle to be able to also, like you said, try out different things, be very much on top of what Blender is doing. Because if it's a longer cycle, like one year, that is difficult to make sure that it's aligned with the Blender development in a way that it actually makes sense. Some smaller experimental Stuff is a lot easier to handle in that sense. So I'm trying to this year do four projects that cut down into like three and a half maybe, but we've already shipped one of them, which is Dog Walk. One of them is almost done, which is a character asset that people can use a full production ready rig that animators can use for their reels and stuff like that studios can learn from. And currently we're working on another short film called Singularity and upcoming is another short film that we already produced a little reel for that is still in development.

B (5:39)

Nice.

C (5:39)

But yeah, I've been trying to speed it up quite a bit.

B (5:41)

Yeah. Moving from one to four is a lot of projects.

C (5:45)

Yeah.

B (5:45)

But it's interesting. I was familiar with Blend Studio short films, but it's really cool, you know, Dog Walk was really cool to see. But also hearing about the character rig, that's really interesting work and I guess that's a good segue into your role. What is a technical artist? What is it you do?

C (5:58)

Well, I think technical artist is a role that's not super defined. It really depends on the branch that you're working in. It's just that little spot in between being a programmer working on the software and an artist using it. It's a little bit of both. And mainly I just try to find technical solutions to the creative problems that we're facing. So what I do a lot is just shading, like writing shaders for the assets that we're creating and tools for the other artists in our team also to work like a lot of it is geometry notes work nowadays. Yeah. With the Blender studio being very tightly connected with Blender for the software development, I'm also. Or not just me, but our whole team is also pretty involved with that. And in that sense I'm quite involved with the geometry nodes development team as a stakeholder artist, basically helping them design the features and test everything before it makes it into main. Awesome.

B (6:52)

That makes sense. A lot of you found a geometry node problem whilst using it for a project and now you have to help fix it kind of situation.

C (6:59)

Yeah, that. I mean it comes with downsides and upsides. Right. But a lot of the time it's very nice being able to face a problem in production and then talk to the people that work on the features directly and help come up with a solution that integrates well into Blender for everybody to use but fixes our problem. Yeah, that's kind of been a large part of the philosophy of the Blender studio being so connected to Blender development, if we fix a problem for ourselves, it's probably also going to help other people out. So it's easier to make a software for us because we know what we want and it's probably still going to be useful for others rather than only focusing. Okay, let's make the best possible software for everyone. Of course, we're trying to keep that in mind, but it makes it a lot easier to have a concrete example of the Blender studio as a use case. Right.

B (7:47)

So with that in mind, what was the problem you were trying to fix with Dog Walk?

C (7:50)

Yeah, so with Dog Walk for us it's been like really a big change of pace being a game, since we're very much used to movie productions and it was mainly just that we are very much aware that the game development community is using Blender quite a lot more so maybe even in the movie industry, because it's kind of already disconnected between the DCC and the engine where most people wouldn't use their actual game engine to create the assets. So there's a difference anyways, so might as well use Blender in your pipeline. It's a lot easier to interconnect than maybe in the movie industry where people might already be using Maya for animation. So it integrates well with Autodesk software and then it's harder to shoehorn Blender in there. So we're very much aware of that being the case and don't have that much experience ourselves with it. So like we do for movie creation, we wanted to also have some more like real life experience of how the process works for game development with Blender or generally with open source. So it was definitely something that was interesting to us to just get the experience and just connect basically with the interoperability aspect of how can we make Blender more easy to hook up to for exchange of creating assets and then using them in a game. Cool.

B (9:14)

So I guess before I follow up on that and ask some of the ways you do that, I guess it'd be useful to talk about what Dog Walk is as a game, what the gameplay is, that kind of thing.

C (9:21)

Yeah. So Dog Walk is a little micro game, we call it, because it's very small, can play through it in like 20 minutes. But it's a little interactive experience where you walk around in a winter landscape building a snowman as a dog. You're actually playing the dog, being led by or maybe leading a little kid through that landscape and then you need to decorate the snowman, find some items around the world and you need to get along. So there's like really a relationship aspect to this game as well.

B (9:53)

Yeah, absolutely. The leading bit with the first time I realized I could hurt the kid by pulling too hard, I was like, oh, no.

C (10:00)

Yeah, no, that was definitely intentional. To create these moments where people maybe accidentally at first or just find out how you really affect the emotion of the kid running around with your behavior. That's one of the main core aspects. Because in terms of game mechanics, there's not a lot. It's really just movement mechanics. You're just walking around and that's it. And then there's obstacles and different environments and you need to kind of lead the child around the landscape without making it cry so much that it doesn't want to move anymore.

B (10:31)

Yeah, it's very charming. As you said, the 20 minute length, super playable, highly recommend. Just go grab it from Steam and give it a go. If you're listening to this, it's really fun. Also, I like the way you worked in Blender's Dutch roots by calling the dog Chocomel. Very good. So I appreciated that.

C (10:45)

I appreciate you noticing.

B (10:48)

So that's the game and it is, I think a really. You call it a micro game, but it has a lot of like, obviously, which makes sense given the origin of the team. A lot of like love and attention to the art and the art style. With that art style, I got the vibe that you were going for like a crafted, like almost. I'm sure it recommended it to like Yoshi's island, like looking like craft paper kind of thing. What led to the decision to do the art style? You said that you tend to experiment with different art styles to drive Blender development. Was that something there?

C (11:13)

Yeah. So definitely in general for this, it was actually a little bit different because the final implementation of the game obviously would not be in Blender, but it was in Godot. So it's not really about pushing the art style capabilities of Blender as much. It was more about the interoperability really. And on a technical level, the question of the art style was more how can we get something that we can work mainly in Blender and don't really need to focus too much on getting that same look in Godot because we wanted to really focus on other aspects. Like we just wanted to focus on the pipeline for getting assets into Godot. But shaders, like replicating like a complicated shader setup, for example, that was like a few steps too far for that goal because it was really just a small project, so we couldn't really Focus on everything. And then the logical conclusion was kind of to try and go for an art style that allows us to basically use the built in interoperability features that we already have. And we went with GLTF as the exchange format. And there's many standards just for PBR workflows. Right. It's just physically based rendering. You just have some color map, roughness map and normal maps and such. And then it just works for anything that is supposed to kind of look photorealistic. And for anything else that's really stylized, you might need to do something very custom. And we didn't really want to do that. So the idea was to focus on a PBR workflow, but still stylize it on top of that. And Papercraft is kind of a natural answer to that because it is like physically based. It's supposed to look realistic in the sense of the surface quality and everything, the lighting, but at its core it's still very stylized. It's purely art, basically. It's all crafted in a way. So that was kind of the logical conclusion on a technical level for us. Also our art director on the game, Vivian Lakovsky, she's very excited always when it comes to doing things at a practical table, not just in the digital space. So it was also very fun to see these things come to life in real life and then recreating them in 3D. And that workflow worked out perfectly because that meant also for us we could focus with the creation of these assets and mainly on the interoperability part. And it was relatively straightforward to just build the assets themselves. So it was really, for us, trying to put the focus where we wanted to and then see what results from that.

B (13:41)

Very interesting. Good incentive to finish the game as well. If you want to see any of those physical models, they are in the credits.

C (13:47)

Yes.

B (13:47)

So do roll through. So in terms of the pipeline itself, so the team has said some really interesting things, some of your devlogs about what you were trying to achieve with the pipeline. Like some things that stood out were you. You wanted it to be blender driven as much as possible and to do as little as possible in Godot, which is really interesting. And the other one was about GLTF and why you chose gltf. But let's start with the first one. So actually, I guess at a high level, what did you want this pipeline to look like as an artist, what did you want the flow to be?

C (14:14)

Yeah. So basically the idea was that like you mentioned, we could do as much as possible in Blender. Because like I mentioned before, we are very much coming from just using Blender for all of our content creation. And having people learn a new software would be. I mean, it would be possible, of course, but also it's not really in the interest of the people that are supporting us to some degree. Of course, like, we want to also support the Godot development. That's not the point. But we wanted to, with the funding that we get from people that want to support Blender, keep as much also from that in Blender, while we are still providing a use case for Godot and giving them feedback for their development. So, yeah, it's a little bit about the skillset of the people that come from the background of movie production, but also about just keeping our focus strictly on Blender. So the idea pipeline for us was to just basically use exactly what we've been doing so far for asset creation, which is really relying on the data structures that we have in Blender. So having everything set up with collections as like a unit of an asset, and then objects inside there that contain all the data, the geometry, all the different data layers, and then being able to nest them inside each other. So a tree would have multiple branches, but then another tree could use those same branches to basically make it easier for ourselves to create those assets and not duplicate the data all over the place. So we'd be able to nest them inside each other. So each branch would be an asset, and those are used in all the trees, which are all individual assets. Then those are finally used in the set, and the set itself is also an asset. So nesting was like very much at the core of what we were trying to go for, because that's something that we're used to from working in Blender. Then the idea was that we really just have all the assets set, the characters, everything set up in Blender like we normally do, and then instead of linking everything into animation files, which is what we usually do as like a direct reference, export it to a GLTF and then push it to godot. But on the Blender side, everything was very much the same as we usually have it, just with nested assets that are just instancing data around. And then the pipeline would take care of the rest by recreating all of that hierarchy on the Godot side. So the artists that were working for the actual content creation of the assets on the Blender end only really needed to touch Godot for validating that what they did actually looks the same. So if the pipeline worked perfectly, they wouldn't really need to touch Godot at all, which obviously it's very important for us to still take a look and validate everything. And the people that were actually working with the game code would mainly work on Godot, but the people creating the content would really be able to stick to just working in Blender.

B (17:04)

Very cool. And so part of that workflow that I found interesting as a amateur Godot dabbler who has been frustrated by collision meshes, is that you were also trying to deal with the collision meshes in the Blender side. Right. Did that work out?

C (17:16)

Yeah, I think that worked quite well. So with the pipeline that we went for, we immediately saw that if we want to actually have this work, we need to extend the built in functionality quite a bit with some custom things that we want to add. And once we have some setup in place to just have an extension, which is very easy to do with Blender for the GLTF export, is just create an extension by the template that already exists, and then you can add a lot of functionality as hooks to just run code whenever something in the exporter is happening. So it was very easy for us to just write metadata to the individual export nodes about the collision, for example. So it's very custom, of course. So it's not really super easy to replicate that unless you really just use the exact same methods. But for me, within that framework, it was very easy to create a geometry nodes node group, for example, that would create some of the primitives that we want to use for collisions. So the capsule, sphere, whatever there exists in Godot, and then have a user interface on the Blender side for people to define the properties of that, like the size, the radius and everything of the primitives for the collision. And then just in the name of the object, just mark it as this is supposed to be for collision. And then the script could very easily just read out all those properties, write them as metadata, attach them to the node on export, and all that would happen automatically. And then on import we would just use all of that metadata to just recreate the exact settings. So we really have this mirroring setup on Blender on Godot side to give us the same kind of functionality to communicate to the artist working on it. Basically this is what you're going to get, and then make sure with the pipeline that that's actually happening by recreating the whole setup using the metadata. So it was really quite easy for us to set up a nice user interface also on the blender side and write that data in a way that can Be used on export.

B (19:11)

That's awesome. That's very cool. Which I guess brings me to, you know, the goal of this project was to experiment this pipeline and see, you know, how the pipeline between these two pieces of software was and you know, drive the development of that. How much of what you ended up with was additional tooling on top of Blender and Godot and how much is things that we might see appear in a later version of Blender, if that makes sense.

C (19:32)

Yeah.

B (19:34)

Capital One's tech team isn't just talking about multi agentic AI. They already deployed one. It's called Chat concierge. And a simplifying car shopping using self reflection and layered reasoning with live API checks. It doesn't just help buyers find a car they love, it helps schedule a test drive, get pre approved for financing and estimate trade in value. Advanced, intuitive and deployed. That's how they stack.

C (19:54)

That's technology at Capital One. I think most of the features that came out of this are already in the release of 4.5 that's out. So that was mainly like bug fixes, some smaller features for the GLTF exporter, some bigger ones also like on the geometry node side, like some reworks on the API to make it easier to export geometry data. That's hopefully still coming, that's still in the works. But there was a big chunk that was also just custom code on top which hopefully we can still use to communicate also with the Godot developers to just see, okay, what of that? Can we, how can we tackle those shortcomings? Basically to some degree. It's also that Kronos group for developing the GLTF exchange format, they have some extensions to GLTF that we haven't really used. Because to be honest, at the time when we were developing the pipeline, I wasn't fully aware of those or some of them I saw, but they seemed very much work in progress. So I wasn't sure if you could rely on them. And at that point it was easier for us to just do a custom thing our own that we know works that we have full control over. But there's some extensions that they're working on, like for example for complex scenes, the whole nesting concept that I talked about earlier that we kind of did in a custom way, there's a concept for that with GLTF as well with that extension. So I think now it's a little bit of a matter of trying to assemble the pieces to really bring those features to the regular user that doesn't necessarily want to write their own Custom pipeline, because that's something that we still need to do. But that's definitely planned for now. It was like with the project itself, because it was a relatively small scope, we did the whole thing in four months. So doing that with some development on the side and then also like polishing everything is not really feasible. So for now we just focused on getting all the pieces and then assembling them later. Yeah, so also planning to do a workshop with some Godot developers and some interested people to actually make that happen. But yeah, that's going to drag a little bit more, unfortunately, as things go, because we also have some other projects that we're working on. But yeah, we definitely still want to make that happen.

B (22:07)

That's awesome. Yeah. And although I know in the post you've kind of just done it there as well, disclaim that it's not production ready and you know, it's very beta. But in the post as well, you did release the source of the pipeline that you have currently, again with a lot of disclaimers, but if folks are interested, you can go poke that around, look up the dog walk. Wrap up post.

C (22:21)

Yeah, we definitely have the entire repository of the project actually uploaded. So the game itself, the code, including also the pipeline is all online for people to dabble around.

B (22:31)

Perfect. So one thing I think is really interesting, so you just said there that, you know, you were thinking about the DX of this from the perspective of like an individual user, either program. But like, one of the special things about Blender Studio is you're doing this at a production scale, so it's a large ish team working together. And that I saw had some really interesting implications for your selection of GLTF as the interchange format over, you know, the blend files. Can you talk to us a bit about that?

C (22:54)

Oh, over blend files? Well, as far as I know, on the Godot side, from what I understood, so the blend file itself directly as an exchange format, is under the hood, still using GLTF for the exchange. So in terms of like the feature set, it would have been more or less the same what's supported out of the box, but for additional customizability, it was a lot easier for us to make that step explicit because if we just have the blend file itself as the thing that's imported for the game files, it would still generate that ephemeral data of a GLTF under the hood, but we would have no control over it, basically. So the way that we did it now is more or less the same, because it's still using gltf, but we actually have control over the data that we output. So hooking up to that export step by having an explicit export step in the first place was really valuable for us in that sense. Something that we also generally have been walking towards in terms of our workflow is to have an explicit publishing step. So rather than having all of the working data that you might be work in progress, working on having an explicit publishing step that the artist can control to say, okay, this is done, this can go into production and then pressing the button, that's not something that we see as negative at all. It's something that's actually very positive by creating that in your workflow. So having the Blend files as direct input to Godot wasn't actually very useful for us because we would make a custom pipeline anyways. I think for people, individuals, for example, that are working on their own, it might still be very useful to have that, just because it cuts out one element of their pipeline that might not be necessary. But for us as a studio working on this, it meant giving us more control, which was actually very valuable.

B (24:43)

Yeah, that's really interesting. And I guess while we're talking about as a studio working on things you're used to working on shorts and motion picture stuff, how was it working on the game? Did that require any differences in how you worked as a team or your workflows?

C (24:57)

It was quite different. I mean, it was. I think it very much depends on who you ask. For the whole team, it was quite different, but some of the people working on it in terms of pipeline, we tried to keep it as much the same as it was. Right. Like I mentioned before, the people that were creating the assets were still working in blender for 99% of the time. In that sense, we tried to keep it basically the same as it was. Of course, animating for a game is going to be very different than animating for a film because you cannot rely on the camera being in a specific spot or the angle that the character is facing. So we also have a blog post over the difference there. But it's very different animating for a game also with variable refresh rate compared to a film where you always know, okay, it's 24fps, the camera is exactly this, the character is facing this way. And then you can cheat anything that you want in between. With a game, you can't. The player will see immediately when there's something cheated. So in that sense, it was very different for the. The animators, for the asset creation. I think it was quite similar actually, because usually assets we want to be able to see from all angles anyways. For me personally, it was very different because I was in a completely different role than I was usually. So I was mainly doing or almost exclusively doing programming on this project where I usually only do a little bit on the side. So for this I was actually implementing the pipeline, implementing shaders and stuff like that. And then at some point, halfway or so throughout the production, I could actually move over to help out programming on the game code itself, which was quite late. I would have hoped to move over to that a lot earlier, but the pipeline was proving to be more complicated to implement.

B (26:37)

Had you used Godot before this project?

C (26:38)

No, I think I'd opened it up before, but that was about it. I went to last year's Godot conference. At that point I hadn't used it at all. But it was really interesting also to hear about the way that they do open source development and how that is different to what we do at Blender. It was just a super fun event. Really good talks, very cool that you can try out games that people made in Godot just on the trade show. But yeah, that's basically been my experience with Godot before this, just hearing about it.

B (27:08)

What were some of those ways that the two projects managed differently?

C (27:11)

The way they do open source development is maybe a bit more democratic, I would probably say, and more loose in terms of adding features, adding like smaller features. The way I understand it is that they try to solve problems if necessary, several different ways with like a slightly different flavor. While we at Blender try to like keep things a bit more streamlined in that sense. But that makes them a lot more agile because you can just on the fly fix a problem and then it's fixed. And there might be a different way to solve it slightly differently, but that's fine. So I think you can argue about what's the better approach here and what's more scalable in the long run. But it was definitely very interesting to me to see how that works. And I think most of their code, or yeah, most of their code is actually written by contributors and then just reviewed by the people that are actually hired by the foundation. And I think at Blender it's the opposite way around, where most of the code is actually written by people that are on payroll by Blender, hired by the Blender Institute. Yeah, of course there's still contributions from like very important contributions from community members, but in terms of just the quantity, I think it's. It's the other way around for us. Right, right, right.

B (28:23)

So, yeah, I guess coming back to your first use of Godot, I guess you kind of answered this in the intro, but was there anything that drove the choice of Godot here, aside from it being like the open source engine of the moment?

C (28:32)

Yeah, it was kind of an obvious choice for us. Well, the director of the game, the main person driving this idea here, Julian Kaspar, he has been just very interested in games in general, Most of us have been, but he's been trying to just play around a little with game development on the side. He doesn't really come from a strong programming background before that, but he really tried to lean in deeply to figure out how to make these things happen because he was really excited about the project and he had been trying out Godot on the side and he had been really excited about it. So that's mainly where the choice came from, I think. But like you mentioned, it is kind of the open source game engine of the time, I suppose. And personally I've been also very excited about it, like jumping on it. Like when I actually started using it, it felt very familiar. It felt very easy to get around. I was kind of surprised how quickly that would work out, especially Python being something that's very familiar to me also from Blender, like add on development as a basis for the GDScript. So that was very nice to jump onto. Of course there used to be a Blender game engine which. Yeah, I think in the aftermath of releasing this game, there's been lots of talks from people that Blender should bring it back and there is a fork.

B (29:49)

Of that that exists and is ongoing.

C (29:51)

Right, exactly. That was what I was going to bring up. There is a fork. But yeah, to be honest, we didn't really consider it that much as a viable option. We'd have to actually look into it a bit more again to see how they're doing with the development of that. But yeah, in terms of what people are using, it's a lot more representative to use Godot because like I mentioned before, we were really trying to figure out the current landscape of open source game development to see what people are currently doing and where the shortcomings of that might be. You're a developer who wants to innovate. Instead you're stuck fixing bottlenecks and fighting legacy code. MongoDB can help. It's a flexible, unified platform that's built for developers by developers. MongoDB is acid compliant, enterprise ready with the capabilities you need to ship AI apps fast. That's why so many of the Fortune 500 trust MongoDB with their most critical workloads? Ready to think outside rows and columns start building@mongodb.com build so, yeah, looking at the. I think upbge is the name of the fork for the Blender game engine. Would have not really been super representative of that.

B (30:59)

Yeah. And I also imagine that would probably cause the discourse about Blender should do its game engine again even more if you did.

C (31:05)

Oh, definitely. Yeah.

B (31:07)

So we've spoken quite a bit about things that have been going on in the Blender side, but I guess on the gameplay side, as you were getting into Godot for the first time, was there anything that you were surprised buying Godot or like features that were missing for what you were trying to do?

C (31:22)

So personally also not coming from a game development background, just to put that as a disclaimer. So I don't have a lot of experience and like. Or presumptions, I guess, coming into this, like, I was kind of like a blank slate in that sense. Yeah. So I've been really surprised how extensible Godot is also for tooling. Like, that's actually something that I also heard about a lot before in, for example, the Godot conference when I was there, how writing tools for Godot for the actual development is kind of the same thing as writing the game code itself, which is absolutely true and it's a brilliant concept in my opinion. I've been trying to think also how we can kind of replicate that kind of thing in Blender, which to me, Geometry Notes is a little bit similar, where you can use it directly for content creation itself and for tooling to create content with. So it's kind of a similar idea, which I. Which I really like that there's point of connection in Godot that's been really useful for me, that you can really just write features or tools and it doesn't really matter and you can use the same code in either one. Yeah, we've been exclusively using GDScript just because that's something that we were a lot more familiar with in terms of like being so close to related to Python.

B (32:37)

I think that is definitely the happy path as well, as far as I understand it.

C (32:40)

Yeah. Yeah. We didn't even think about using anything else, to be honest. But yeah, from what I hear also that it's very extensible. With C, for example, it was really interesting to me how extensible it really is, especially also with the signal functionality that you have where you can really hook up Functions that you want to write yourself to the engine itself, like even to the point of the file system, for example. That was very useful actually for us. For me writing the pipeline, I did need to use a lot of workarounds for implementing it the way that I wanted to, by combining different functionalities in a way that I didn't expect I would have to. But Godot made it possible by being so extensible. Like I could have my own functions hooked up to signals of the file system, for example, so whenever Godot would recognize that there's a new file in the game files, I could attach my own code and just do whatever I wanted to prepare the files for import, for example. That's something that we've been doing for this pipeline. Yeah. If I compare that to the extensibility of Blender. In Blender, I would have never been able to do this amount of customization. So that's been really, really interesting for me.

B (33:50)

I guess it's kind of intuitive when you think about how it works, but I didn't realize that the signal system extended to like, you know, what's like how the editor is working, which I guess makes sense because the editor is written in Godot. But yeah, that's a really interesting just concept to hear about. That's really cool.

C (34:03)

No, exactly. It was also a moment that I didn't think about at first and I was trying to solve a problem and I just googled and then somebody suggested on some forum that to use a signal and I was like, huh? And it opened up a whole new world that I didn't know about before because by that time I also didn't do any of the game development itself yet. So I, I was still trying to find my way around the API in Godot and it's, it does work quite differently than what I'm used to in Blender. It is a lot more extensible in that sense. I was really impressed with that. And that's also something that I'd like to potentially bring more to Blender to be able to hook up to native functionality of the software with your own code in an add on. Cool.

B (34:41)

Well, that brings us close to the end of our time, so it's a good place to wrap. So Simon, thank you so much. This has been super interesting and wonderful to hear how the sausage was made in this case. Thank you so much for joining us today.

C (34:53)

Yeah, thank you.