EPISODE 1772

[INTRO]

[0:00:00] ANNOUNCER: Teardown is a 2022 sandbox puzzle game developed and published by Tuxedo Labs. The game revolves around the owner of a financially stricken demolition company who is caught undertaking a questionable job and becomes entangled between helping police investigations and taking on further dubious assignments. The game stands out for its technical achievements, particularly its use of voxel-based rendering, which enables highly interactive and fully destructible environments.

Dennis Gustafsson is the founder of Tuxedo Labs and the creator of Teardown, among other games. In today's episode, Dennis speaks with Joe Nash about his 20-year history in game development, his passion for physics and games, Teardown, the advantage of using voxels, and much more.

Joe Nash is a developer, educator, and award -winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got a start in software development by creating mods and running servers for Garry's Mod, and game development remains his favorite way to experience and explore new technologies and concepts.

[EPISODE]

[0:01:16] JN: Welcome to the show Dennis. How are you doing today?

[0:01:19] DG: Thank you. I'm very good. Really happy to be here.

[0:01:20] JN: Yes. Awesome. Thank you so much for joining us. So, where I want to start today is your journey into game development because you know poking around in preparation for the show, it seems you come from a very much like rendering background which makes a lot of sense looking at Teardown. I'm really interested like what was your career to date leading up to Teardown?

[0:01:37] DG: Yes. That's actually not entirely correct. For being a game developer, I've been pretty uninterested in rendering for a long time. I've been working in games since 2001 or 2002. It's more than 20 years now, and I only started tinkering with rendering really just a couple of years before starting on Teardown, really. I've been doing some rendering, of course, in order to be able to do the previous games. So, that was maybe seven, eight years ago or something like that.

My main interest has always been physics in games, and that's also where my main part of my career has been. I worked for physics engines companies and writing my own physics engines and doing physics games. So, that's really the core of my background.

[0:02:24] JN: That absolutely makes a lot of sense. Having experienced Teardown and the core gameplay loop of physics background absolutely makes sense. Where did that interest come from? Is that driven by your own gameplay experiences? What got you going on physics engines?

[0:02:36] DG: Yes, I can't remember exactly, but it was during my time at the university when I was studying media technology. A lot of my student colleagues were really interested in rendering. I thought somehow that physics was more interesting because of the interactivity. It wasn't really that much used in games back then. This was 1997. We didn't even have ragdolls at that time. It was just no physics at all for the most part. I remember, there were a couple of games that started to use physics. One of them was Carmageddon 2. I remember playing that a lot to study the physics. There was also this dinosaur game. I don't remember the name now. But there was one where you could actually pick up objects and manipulate them with a virtual hand, and I thought that was really cool. So, I just started tinkering with that, and then, yes.

[0:03:30] JN: Was Carmageddon the one on the Nintendo 64?

[0:03:32] DG: The one I played was on PC. It might have been on multiple platforms.

[0:03:37] JN: We spoke to the developer of the back port of Valve's portal to Nintendo 64 a while ago, and I remember looking at that, there was one game I had like physical driven gameplay on the Nintendo 64 and it was a car game. So, maybe that Carmageddon.

[0:03:49] DG: Yes, maybe. It was a pretty silly game, but the physics was good. So yes.

[0:03:55] JN: Well, awesome. Obviously, we're going to spend a lot of time talking about Teardown a wonderfully physics-driven game. For folks who aren't familiar or haven't experienced the game. Can you briefly introduce the title?

[0:04:05] DG: So, Teardown is a voxel sandbox game where the gameplay is based around heists. So, you can - since everything is based on voxels, you can modify the environment. You can break things and they break in a physical way, not like Minecraft where you can remove blocks, but when you remove something and explode something, they actually fly and rotate and behave like actual objects. 

The core gameplay is that you're preparing a scene for a heist. You're tasked to steal a number of objects on a timer, and you can, before starting that timer and starting the heist, you can go around and prepare the level of destroy things, you can build stuff, you can move vehicles, and then when you perform the heist, hopefully you can steal all the targets in 60 seconds.

[0:04:53] JN: Awesome. Yes, that's a great description. I think that first point you mentioned is actually particularly important about you can damage objects and they go flying off and the comparison to Minecraft. So, I think one of the things that first caught my attention on it is like, there are voxel games where the voxels exist to make up the worlds, make up the objects, but then everything is aligned to a voxel grid. That is not the case with Teardown, right? The voxels make up the geometry of the things in the world, but then they are operating in free 3D space. Am I correct on that?

[0:05:20] DG: Yes, that's correct. They're still on a grid, but each object is on its own grid, and then the whole grid can rotate in the world and move around freely.

[0:05:29] JN: Perfect. Yes. We'll come back to the heist concept, because I think it's really neat and a really good way of using the engine you've built to make gameplay. It's really, really fantastic. But I was spending a little bit of time on the game and the engine that you mentioned. So, it's built out in its own engine. Where's the chicken and egg here? Did you have the idea for the game well-formed and was like, "Cool, this is - I need to build this you to do this." Or was it very much a, "I know these are the features I want to make from an engine perspective," and thus the game grew out of it?

[0:05:56] DG: Yes, it's very much the second one. I had no idea about gameplay when I started to tinker with this. I just wanted to do cool physics-based, destructible voxels and then gameplay was actually a pretty hard one to crack for this game. It took a long time to come up with that concept and there was a lot of prototyping for different games involved in that. So, it was really nice when that finally landed.

[0:06:21] JN: Fascinating. And what kind of time period? How long have you been working on the engine before the core gameplay loop kind of cemented?

[0:06:28] DG: I started in 2017, I think. And then building the technology and doing prototype for the gameplay was kind of interleaved a little bit. But it wasn't until 2019, it must have been where I finally decided on the gameplay and started building the actual game. So, that was a couple of years.

[0:06:50] JN: Yes. That's a good amount of time. So, I guess, tell us about the engine. I guess a place to start, what were you seeking to build? What was the engine that you had in your mind before the game crystallized? What were you after?

[0:07:02] DG: So, the idea for the voxels started, I think, with this little voxel modeling program called MagicaVoxel. It got pretty popular during that time. There was a lot of beautiful images floating around on Twitter, and I just saw them by accident, and it struck me how well-suited that would be for a game, and I don't think that had really been done before at that scale. It was also kind of perfect for physics, because normally when you do destruction with polygons, like you normally do with games, you have this triangle meshes.

When you do destruction on those, there are a lot of gnarly cases with degenerate triangles and floating-point precision issues and none of that really exists with voxels. Everything is nicely aligned on the grid. It's all integer math, and it's much more well-behaved. So, that kind of clicked the whole thing. It could also be worth mentioning here that the voxels here are considerably smaller than typical voxel games. So, they are on the scale of where 1 voxel is 10 centimeters. There's quite a lot of them. I wasn't really sure that was going to work and that's sort of what inspired me to try and replicate that MagicaVoxel feel in a video game.

[0:08:20] JN: Oh, that's awesome. So, the size of the voxels came from MagicaVoxel. Do I understand that correctly?

[0:08:23] DG: Yes.

[0:08:23] JN: Fascinating. Okay, cool. That was going to be one of my questions because that's one of the first things, as a person who spent a good amount of their teams on Minecraft, like the size of the voxels is one of the first things you notice booting up the game, that and the ray tracing. So, I was like really interested in how you came by that size, but okay, that being come from MagicaVoxel makes sense.

So actually, mentioning the size of the voxels and how many of them in the performance, I think, there's been, I don't know if you're aware, but there's been a couple of really amazing like blogs tearing down Teardown and the rendering and the performance of it and lots of people are very impressed by your work. What are some of the challenges of dealing with, I guess, both physics and also just drawing that many voxels on the screen that you're dealing with?

[0:09:00] DG: Yes, I read those blogs. Also, it's really incredible how detailed they are and they've done a much better job than I could have done describing that. So, I'm really thankful someone did it, because I've been wanting to write that up for some time, but now I don't have to. I think the most challenging issues, there were a lot of challenges, both in the physics and in the rendering. But I know for a long time, I was keeping lighting in screen space, meaning that when doing ray tracing, it was only considering the parts of the world that you were actually looking at, which is not great because if you have light behind your head or if there's something blocking your light behind the head, it's not really casting shadows correctly and it's a lot of artifacts.

So, getting all that to run in voxel space and make it more correct, that was quite challenging to make that run at decent performance. And from a physics perspective, a lot of physics actually turn out much nicer with voxels. That was something I thought was going to be challenging to do collision detection, to detect if two objects are close or overlap in order to make them respond with physical forces. That was something I thought would be really tough, but actually turned out much easier than I thought.

So, there were both pros and cons, I think, with going with voxels instead of regular objects, so to speak.

[0:10:29] JN: Yes. I mean, on the physics in terms of things that are different. I don't know if I have a well-formed question on this, but obviously I noticed like as you're first exploring a physical driven game, especially a destructive one, you're like, "Okay, if I smash it this way, will it react in the way I expect?" Were there any, I guess, particular physics interactions that you found very difficult to implement or decided didn't contribute to the gameplay and didn't implement, if that makes sense? 

[0:10:50] DG: Yes. There is one clear candidate for this question. That is the structural integrity. So, if you have a whole house, for instance, and you remove almost all of the lower floor, so it's only hangs on a single voxel, it is still connected. But in reality, it should just break. No material is so strong to be able to hold up the house. That's something a lot of people have requested, obviously. It's also something I thought would have been cool to have in the game, but I still don't know exactly how I would go about implementing something like that, because it's really complicated when it's so generic as it is in Teardown, and there are just so many voxels. There are hundreds of millions of voxels in the scene and trying to untangle how they're connected exactly and how much weight they're feeling how much they're supporting.

[0:11:43] JN: We have to like calculate stresses along like different lines of material types and all kinds of nonsense.

[0:11:47] DG: So, I'm not doing that. I think, and there have been some misconceptions about this in the past, but I think it was actually a good decision for gameplay. I don't know that since I don't know how the game would have played with it. But I do appreciate that you can trust the environment. If there is something holding up a building or something, I know that it's not just going to randomly break like it does in the real world. Then that gives you more ability to plan when you prepare.

[0:12:17] JN: Yes, that is really interesting for the planning stages. As you say, like, you can set up, I know on my way out that I want this thing to collapse, and I want it to be a single block that I knock out, right? It would be very stressful to do that otherwise. Fascinating. So, this is, I guess, like a very table-stakes question. But what is the technology of the engine? What did you use to build the engine?

[0:12:39] DG: I'm really interested in game technology and I tend to build a lot of stuff myself. I mean, they're pros and cons. I could have built Teardown in an engine. It would have been hard because there are no engines supporting that technology natively. So, I would have to rewrite large portions of it. I'm not sure in the end if it would have been easier or harder to do it in something like Unity or Unreal. You get a lot of things for free, but it also takes a long time to learn and you have to keep updating it and all that.

But I've always, also in the past, written my own engines. I really enjoy it. It's a big motivating factor for me. So, I'm not really planning on changing that. I wrote everything. I do use, for Teardown, I wrote the graphics using the OpenGL API. It's an old API. It was old already when I started. Now, it's ancient, and we have replaced it since. But that's pretty much it.

I do use some libraries for compression, reading images and stuff like that. But it's very low-level, small, replaceable bits and pieces. It's not built on any existing framework or anything like that. So, it's very much a handwritten engine in that sense.

[0:14:00] JN: When you say you've replaced OpenGL, was that with Vulkan or DirectX?

[0:14:03] DG: It's actually a D3D12. I did not replace that myself, but it was done by Saber Interactive when porting it to console, so that was - we needed something else for that to work.

[0:14:17] JN: Awesome. Cool. So, you mentioned that you only really got into rendering shortly before starting to build the game. Obviously, one of the very like commented on things is like the beautiful ray tracing and it's I think also just as a side aside, the fact that the like planning phase of so many levels takes part like golden hour is like a fantastic touch. Everything's beautifully lit. Excellent choice of time of day for your game. What was the way around that was like, you developed an interest in rendering, you were like, "Cool, I now need to - I'm going to - this interest has fueled this game." How did the ray tracing element come about?

[0:14:54] DG: So, I think since they have not been so interested in rendering previously, I kind of missed that whole train of learning all these tricks that you have to do in rendering. I never implemented cascaded shadow maps and all these tricks that people use in order to simulate what ray tracing already does. I kind of jumped straight to ray tracing instead, and ray tracing is conceptually much simpler than rasterization. So, a lot of things is just easier.

I think that the choice of voxels was also simplified the ray tracing implementation a little bit. There were a couple of tricks that I used that you can't really do not as easy at least with triangle meshes. That is in order to calculate what light is blocked, I actually create a voxelized version of the level that is all in memory, where I just represent each voxel as a single bit. So, it's basically a bitmap with hundreds of millions of voxels. I can just keep that updated and use that for ray tracing. It's super fast to just traverse the bits in that grid instead of visiting different objects and all acceleration structures and things that they do in normal hardware ray tracing that's becoming popular now.

It's a very custom implementation of ray tracing that only works for this particular game. It's not really something you can apply to any game.

[0:16:30] JN: That's fascinating. So, trace for the implication, I guess I'm most surprised that keeping and maintaining that bitmap and keeping it updated when you've got players knocking houses down in real-time. I'm surprised that's performant.

[0:16:43] DG: Yes. I wasn't sure it was going to work. I've often gotten the recommendation to, why don't you move that to the GPU? Because right now, the CPU is actually orchestrating that whole update scheme. It can be complicated. If you have a lot of changes simultaneously on the map, you have to update a lot of objects, obviously. But the CPU is pretty good at orchestrating difficult, complex things. Whereas the GPU is not. It's much better at just crunching numbers, just going over big chunks of data and crunching numbers.

So, it's a pretty hard task for the GPU to do. And I think it turned out pretty well. You can see sometimes it gets expensive if you play the game and you've driven one of these large boats, there's a yacht, for instance, you can drive around. That one is pretty expensive to update because there's just so many voxels moving. But for the most part, it's not really a bottleneck. You can obviously do that update on the CPU in the background, so you don't really have to do it all at once. You can just paralyze that really well while doing other stuff.

[0:17:50] JN: That's nice. I think that's very cool. We mentioned this blog, I should probably, yes, this is an Aco.net's Teardown blog was one, I think I read and mentioned that your ray tracing was entirely on the CPU, I think, which was very interesting.

[0:18:01] DG: The ray tracing is not on the CPU. It's actually on the GPU. It's only the update of this shadow volume. These are the bits that block light.

[0:18:09] JN: Right. Okay, cool. So, we've spoken a bit about the development of the highest concept, and obviously the gap between you starting the engine and the highest concept coming out. I guess, one thing I'm dying to know is the teardowns that could have been. Like what concepts did you experiment with in that two-year period before you landed on the heist?

[0:18:29] DG: So, I was working with a colleague, Emil, and we were trying to come up with different games with this. We did quite a few prototypes on that. We started, I don't remember which one was the first one, but we did have a heist game that we worked on. But it wasn't really the same concept. It didn't have a timer. It didn't have multiple targets in the same way that Teardown does. It was more based around resource limitations. So, you had like one explosive and a sledge and they were affecting different materials and you had to be strategic about where you placed that bomb.

It was a game, but it wasn't really that fun because if you're given this world with infinite destruction and you have like one bomb, it's just not going to be such a fun game. That was, I think, the main problem and with most ideas that we tried. Also, we had a vehicle or like a driving game of sorts, where the physics and the destruction was more like a decoration, more like a visual effect, and that was something I didn't want. I wanted the destruction to affect gameplay and really matter and not just the big explosions with things flying everywhere. You actually want to use that for some problem-solving. 

So, there were a lot of constraints. Also, doing games with fully destructible worlds is a nightmare for a designer because there's really nothing to work with. You're players in this world and you don't really have anything that can limit the player. You can't place - well, you could place unbreakable walls, of course, but then everything wouldn't be destructible. So, everything is destructible. It comes with a lot of constraints on the gameplay. It wouldn't work - most games just wouldn't work if you added fully destructible environments, because they're designed to limit the player. If you can just, if you're going to pick up key card, the yellow key card, and you could just take out the walls and pick it up, it wouldn't be much of a game. I think that was the biggest obstacle in trying to come up with a good gameplay. 

[0:20:40] JN: Fascinating. Yes, it's really interesting to hear just thinking about like, the first couple of levels and how concepts, different material harnesses and stuff coming, like how you introduced that first level where you're like, "Oh, I can't just sledgehammer through this wall because it's brick. Ah, there's a window around the side." It's really interesting to think about that I guess like escalation of all like that problem-solving experience from the perspective of like finding that hard as a level designer, because I think you've approached that really well. Also, the limitations is fascinating because one of the things that like really surprised me in multiple ways because you said now, is that first I guess like quasi tutorial level where you just got to smash up the first house. I was like, "Oh, okay, we've got a house here, there's a couple of propane barrels next to it. That's cool. Turn around. Oh, there's three tractors and another stack of propane barrels. They really want me to go ham on this." I was like, so surprised how quickly you were just like, have all the tools, do everything. The sky is the limit.

[0:21:31] DG: Yes. That tutorial level was actually, it was designed that way that, you get two or three propane tanks, but it's not enough to take down the house. So, that kind of encourages the player to look around the environment and see if they can find something else.

[0:21:43] JN: It's also very interesting in terms of what you said about the example you gave for the limitation of the physics engine in terms of not having like structural stress in terms of if you knock down all the walls of a house, but there's one pillar, there's one like pixel still stand, or one voxel still standing, it will stay up. It's then interesting that the first building to destroy is literally a house where the intuition I think for most players is going to be take out the ground floor walls, right? It's a good -

[0:22:06] DG: Yes. That was also a very deliberate decision, because we knew a lot of people were going to be disappointed for that lack of structural integrity. So, we thought it was better to just 
show it immediately. This is how it works. You're not going to get the full thing. It would be cool to try and add something like that. You could also fake it a little bit by making the house in multiple parts and join them together with like physical joints instead. We do that for some parts of the buildings, but it's generally quite hard, I think, to enable that on everything.

[0:22:42] JN: Yes, I imagine you start getting into unpredictable behavior like bits of building shaking, even this kind of thing, right?

[0:22:48] DG: Yes. That was actually one other constraint in the beginning. When we released Teardown in 2020 in early access, there was a limitation on this thing that find connected parts. So, if you have a really big house and you take down the whole entire lower floor, even the last voxel, it would actually still stand, which was incredibly frustrating for people who took the time to do that. That's something we updated a few months later. It was a really challenging technical problem, actually, to come up with an algorithm that could do that for infinitely large objects, because you may end up searching the whole level, which is hundreds of millions of voxels. So, it can be really slow. 
But we managed to come up with a good one, in the end.

[0:23:37] JN: So, you mentioned that infinitely large objects, which makes me think of modding. A lot of these constraints, in a normal game, you could be like, "Okay, well, we don't have to make this super generic, powerful algorithm, because we know we're not going to build a structure that's going to be a problem." But obviously, your game is enormously popular with the modding community. I think actually, there's an article that describes it as like the new GMod, which is very - was very happy to see that description of it. What was your approach to making the game model? Was that a vision you had from the start to support the modding community? Was that an emergent use case?

[0:24:09] DG: It was not there from the very start, but we knew that or we had a hunch that people were going to be into modding this, even before the first early access release. So, we did kind of prepare the game in order to have a fully supported scripting API and all that.

I think in the first version, we even had a little bit of modability. You could like build an object in a MagicaVoxel and then import it into the game. We did have this idea that we wanted to support modding properly already from the start. I think for me, that has been the most rewarding part of the whole experience to see what the modding community can do with this and that's one thing I'm particularly happy about, that it turned out so well. We have so many people spending their free time modding this game. It's amazing.

[0:25:02] JN: I guess as a developer, as someone who you mentioned earlier, really enjoying building your own tools, how do you think about providing that development experience for your modders? Is there any particular tools or things of the API that you were really interested in making a good experience?

[0:25:17] DG: I think in the beginning, we just did what we needed in order to build the game, but made sure that it was in a format so that it could be used for other things as well. But as time went on, we started implementing recommendations or requirements from the modding community. So, now it's been a little bit of a mix between the two. It's not really a full platform. There are still some things that are really hard to do for the modders, like implementing a custom character controller, for instance. Some people have tried and failed, and it's not really, or it's very much not designed to do that. So, it's kind of hard.

I think at this point, it's going to be hard to change the API, because we have so many mods using it. So, we're a little bit locked in. I guess, that's the downside with all software one that you keep updating that you kind of get locked into a corner. There are definitely some things I would have done differently if I knew where it was going. But for the most part, I think it turned out fine, actually.

[0:26:15] JN: I realize there's a really hard question on top of your head. Are there any mods or the work of modders that really surprised you where you were like, "Oh, I didn't think anyone would be able to do that with this engine."

[0:26:24] DG: Yes, there's a lot of them. I think the first time I felt that must have been the portal gun. Someone obviously implemented the portal gun in Teardown. I was just amazed. This shouldn't be possible. They had like a rendering from within the portal using - we didn't even have a way to draw pixels on the screen. So, they were using the UI API to draw big rectangles and they just did lots of them and doing RateCast. It had their own ray tracer from within the scripting language to render the portal and put in the world using sprites. It was just incredible and not something I would have ever thought would be possible. So yes, things like that are really fun to see.

[0:27:10] JN: Also, the game has been around for a while now and you've been - it's been a journey, like you've been acquired and then I believe Saber are no longer part of the chain. You're directly under Embracer, is that correct?

[0:27:22] DG: Yes. This has been a little rough path last couple years. I sold the company to Saber Interactive. They were owned by Embracer. Then about maybe half a year ago, Embracer got rid of Saber or Saber got rid. They were changing ownership.

[0:27:38] JN: Embracer did a lot of things now half a year ago.

[0:27:42] DG: Yes, a lot of things back at that time. And in that process, Embracer really wanted to keep us so we changed owner to be under Embracer instead. It hasn't really affected us that much, I must say. We do have a little bit more control now, which is good, but it's been relatively smooth, I would say.

[0:28:01] JN: Yes, so across all of that, game is reaching its maturity, it's got a great user base building great content on it. How are you thinking about the future of Teardown or of Tuxedo Labs? Is there anything else cooking in this engine? You think about future titles? Are you working on more stuff for Teardown?

[0:28:17] DG: Yes, I've been doing for the last - I'm actually not that much actively working on Teardown anymore. We now have a good team doing updates and working on that. I've spent most of this year, actually, researching new technologies and new types of rendering and whether some of that ends up in Teardown or a new title is not really decided. But it's been a lot of fun to get back to more tech research. I haven't really done much of that in the last six, seven years. It's been mostly just crunching out features and code for the existing one. So, I'm really happy to be back at that.

[0:28:55] JN: What is it that's given you that space to do it now? Is it just because where Teardown is in life cycle? Or is it like a stage of Tuxedo Labs' growth?

[0:29:04] DG: I think the main thing that enables me to do that is the fact that I sold the company, because I wasn't really interested in running a company. It was quite surprising to me how Teardown took off and I had to spend a lot of time, salaries, management, just these day-to-day things you do when running a company that I don't enjoy at all compared to technology and programming, so that was the main motivating factor for me to sell it and kind of take a step back and really focus on the technology. It's been taking maybe a year to do that full transition to have build a team that can take over all those tasks of maintenance so I can focus on something new. I think that kind of happened beginning of this year.

[0:29:53] JN: Very cool. Yes, it sounds a lot like the story of the Zatronics acquisition as well, where he was just like, "I don't want to be running this company. I want to make cool games." Yes, very understandable, very understandable impulse. I don't want to push you on revealing a decision reveal in terms of what you're doing with it, but you mentioned up-and-coming rendering technologies that you've been looking at. Is there any particular like-named techniques that the audience might be interested in?

[0:30:15] DG: I finally learned Vulkan.

[0:30:17] JN: Oh, nice.

[0:30:17] DG: I've been stuck on OpenGL for so long, mostly because I'm lazy. Now, I took the time to learn Vulkan. I'm not sure I really like it. I think it's a bit too low-level for me. It's just you have to do everything yourself, even the not-so-fun parts. But the reason I wanted to learn Vulkan was to get access to this hardware ray tracing that's been cooking for, I don't know, how many years now? Did it come in, was it 2018 or something when it came out?

[0:30:48] JN: Yes. It was when the proprietary RTX cards and whatever slot landing. I think about that. 

[0:30:55] DG: Yes. It's actually really useful, even when ray tracing voxels. I thought that it wouldn't be so useful for rendering voxels because it's designed to work with triangles. But it turned out that it's actually quite useful for what we're doing. So, I've been looking into that quite a lot to build a fully hardware ray tracing supported graphics pipeline, which has been really cool because then you can do proper path tracing and you get much better lighting and performance is awesome and you get around a lot of restrictions that we had. We had a limitation on the world size, for instance. We couldn't have more than 4,000 voxels across the world because of a texture size limitation in OpenGL.

Now, that we have hardware ray tracing, we don't really need this big bitmap of voxels, we can just operate directly on the objects. And also, trying to get rid of restrictions that make life easier for modders to build, make it easier to build content faster. That's what I've been focusing on the most. Also, starting to look into physics again a little bit, it would be something I'm wanting to get back to. I haven't really done that much yet in that, but I'm slowly getting there.

[0:32:11] JN: Is that just from the perspective of just revisiting because it's been a while? Or is there, kind of the same with rendering, there's new hardware that's enabling you to tackle problems again? 

[0:32:20] DG: Yes, I don't think from a hardware perspective, it's not really not that much you can do. Well, you could do some physics work on the GPU, but it's not really well suited for it. So, it's more about technologies and algorithms and also other types of simulations. I've been looking into fluid simulation for instance a little bit and also soft body simulation and see if that can be combined with voxels. Yes, there's some things cooking. I have shown a little bit on Twitter about that, but I expect that to be hopefully a lot more during fall this year and going forward.

[0:32:58] JN: The fluid is particularly exciting here. I mean, there are water-based shenanigans in Teardown very, very early on. So yes, that's a very exciting area of exploration. Awesome. Well, Dennis, thank you so much for your time. I think I've run to the end of things I wanted to ask you. Yes, it's been absolutely illuminating. Thank you so much.

[0:33:17] DG: Ye. Thank you for having me.

[END]