Embark-Asset-Processor---Erik-Hallberg--

Hello and welcome. Sorry. Hello and welcome to this presentation. The asset processor, but it's also a two-part presentation. I'll be talking about the asset processor and Darko will present later also from Embark on our landscape tools. First, a bit of introduction about who we are. I'm the lead 3D artist at Embark and Darko is the lead environment artist. Embark Studios was founded in 2018 with the explicit goal of revolutionizing how games are created and played. We currently have three free-to-play projects ongoing.

We have the finals that just, the beta just finished, I think, yesterday, which is a fast-paced first-person shooter with a lot of destruction. And the arc creators, third-person PvPV-E shooter. And then we have a platform for creative play being developed as well. We'll start by taking a look at...

I'm just a touchbird. Coming in damn hot.

Showtime.

Two buddies coming in hot.

Oh, it's on.

Yeah, let's go.

Let's do this. Come on, let's do this.

Hang on, hang on.

Hang on. He's not down.

Go! dancing on my own

so like daco mentioned yesterday it's not actually coming 2022. that's a bit out of update and obviously that's our creators and next we'll take a look at the trailer for the finals

út severa

- réal-

Ah, gee!

Move!

And he gets the backstab!

What a steal!

Let's go!

Oh

As I think you'll see from that trailer, there's a lot of other Houdini stuff involved in making these games as well. That's not right.

So, what we'll present today, I'll be presenting our Asset Processor, which is about making 3D assets, and then Darko will be talking about landscapes.

So, the asset processor presentation. This is the agenda for the presentation. I'll talk a bit about the challenges we face when it comes to creating high quality content that meets player expectations, while we simultaneously need to be faster than ever because of how quickly players turn through content As a solution to that I be presenting our internally built asset processor where we'll be focusing on one of the processes that we run through it, specifically the hard surface process. I've previously held a talk about it when it was still in its infancy back in 2021 at the Nexon developers conference. It covered a lot of philosophy and so on. But it didn't cover the crucial aspect of how players actually experience working with this tool. And I'll show some cool features that we haven't even thought about back then. And we'll go through what type of input it takes and what it spits out to the other end. And then we'll take a super brief look at some of our other processes that we also run through the asset processor. And lastly, I'll talk about some challenges and learnings and what the future looks like.

So the challenge we face, our needs, let's briefly go through what requirements for asset creation we have. We have free-to-play games, so this means that we need to be able to consistently make content drops that appeal to our players. And this is especially important as players' expectations for amounts of content continually increase. And then, since we can't perfectly predict what player tastes are, much less what they'll be tomorrow for that matter, we need to have lots of room to shift what type of content we produce. And there's another type of flexibility, not this one, that's really important too. that since we intend to maintain a relatively small content team, that we make sure that it's easy for people to do a wide range of tasks. And beyond that, that it's easy for people to pick up each other's work files. We also need to establish and maintain a high quality bar for all of our content in order to stay appealing to players. And of course, that's what we as artists do, strive for quality.

I will try to paint a picture of a sort of hell to the left and the type of world where we want to be, heaven, if you will, and what that would look like. So of course, there are many issues with doing certain things manually. The important ones are the fact that as human beings, we only have a limited amount of work that can be done. And it's important that that time can be spent on worthwhile tasks. With ever-growing teams, it's impossible to maintain a project without layers on top of layers of bureaucracy. The problem, of course, is the soul deadening effect that this has on creativity and how the rigidness of those structures goes against the fast-paced industry like ours. So we want to keep teams small. And of course, this should amount to a sense of impending doom. With that comes tears and screaming. Now, on the right side instead, where do we want to go? a world where realizing our creative dreams should be effortless and where we can speed ahead, unafraid to try things out, and knowing that we are able to meet whatever challenges

lie ahead. And that should amount to something like this would be ideal. And we'll see how

close we are. So, let's take a look at some of the current limitations and struggles we face with traditional 3D asset creation workflows. Current workflows that exist within the industry are slow and difficult to master. There are lots of separate steps that lack any real tie to each other, where artists have to juggle and maintain separate assets, often through multiple DCCs. There's also a lot of more or less manually shuffling data back and forth between these programs, and it all combines to create a huge barrier of entry to making content for games. What's probably worse, though, is that this way of working makes iterations cumbersome, and I think we've all experienced that iterations is where quality comes from, since we rarely get things right the first time around. But with this workflow, whenever we want to adjust something at an earlier stage, we have to go through all of the following steps again. And the hesitancy to revisit already completed work also forces us to purposefully slow down to thoroughly analyze our work in fear of having to go back and redo work later, which ends up in that continually just looking at your asset and turning it around and being like am I sure that I happy with this which is just not a very fun way to work

And again, there's that impending sense of doom.

Each step of the chain also comes with their own challenges no matter what approach we take to them. If we take high poly creation as an example, which is often both the first and most difficult and time-consuming step of the asset creation workflow, we can review the current methods that are most commonly used and find them lacking in multiple respects. So, subdivision modeling has been around for a long time and it's still in common use, but it has problems with being difficult to master and to adjust. It requires a deep understanding of topology and if you wanna change shapes, you need to rebuild the topology of the asset. Creases were a welcome addition since they meant fewer like sliding edge issues and support edge loops. But even with creases, the workflow still relies on the topological structure of the mesh. So the issues with slowness in flexibility and remain. This is an old model of mine, so I know the topic deeply and the pains of it. something that happened many years ago now, but it's like Dynameshing assets in ZBrush that got rid of both the difficulty and the inflexibility of subdivision modeling to some extent. It can still, however, be considered difficult since it means that artists need to navigate ZBrush. And especially if you don't already know ZBrush, like getting into ZBrush only to get like, rounded corners on assets is a hassle. And it's still slow and inflexible in that the workflow is destructive. Like, if you want to go back and change something, it's going through that chain again, which is pain. It seems that a lot of hard surface artists have picked up CAD modeling, which is pretty cool. It gives insanely precise results, but to a point that goes beyond what most games would need. So it's a bit overkill. And it's still another piece of software to be learned and incorporated into a pipeline. And as a starting point for low poly creation, it's perhaps the furthest away from any of these methods. And they all suffer from the same deeper issues. They're difficult to master, they're destructive, and you still need to create a separate low poly model

with its own UVs and with a setup for baking down the necessary information.

As anybody who has made games assets will have noticed, only a small fraction of time is spent on actually exploring anything creative. We go through the motions of the necessary steps, but in themselves, they don't allow for any meaningful expression. Sure, there's room for excellence. UVs can be better or worse, and the same goes, of course, for the less technical parts too, like building a high poly model. But humans simply can't compete with computers when it comes to precision of execution. When we've perfected something, like say a baking setup, we want to cement it forever so that everybody has instant access to that setup, preferably without even knowing that they do. It's easy to get into a mindset of, yeah, but there are so many factors that goes into doing X, and we can deal with a lot of factors. It just takes more time to solve, is all.

So, what we are striving for is a tool that's easy to use, gives us fast results, creates

assets of world-class quality, and makes us afford taking chances to experiment. We want something that allows us to reinvent our craft and make it about true creativity instead of dealing with technical hassle. We want the simplest possible input and have it be automatically converted to our desired end result of a shippable game asset.

So enter the asset processor. To solve this, we have our internally built asset processor.

And it looks like something like this instead. Having a single point of input where the smallest possible amount of input is needed gets rid of most of the traditional steps. We start by setting up the input inside of Blender. From there, all of the behind the scenes magical Houdini stuff happens. That's why the Houdini process gears is the only step that doesn't actually have the Houdini logo. Sorry, side effects. But that's the important part. But from a user perspective they don even know and they shouldn care And outcomes and assets ready for texturing complete with UVs bakes and rig ready to be textured and submitted to the game

And there's that touching the face of God.

And this adds up to bringing assets creation time down from weeks to days, and iteration times from days to mere minutes.

I think a brief history of how we got here. And the process had grown really organically. It originated with the thought that automating certain hard surface assets should be possible. You'll see that a lot of that part of the process looks like an automated the ZBrush workflow. It then moved over towards thinking that automating certain hard surface UVs should be possible as well. Mostly the basic cutting of hard edges and automatic layout stuff that a lot of people are using already. And why shouldn't baking be able to be automated as well? Like matching high poly objects to their respective low poly meshes shouldn't have to be a name-based manual task since it's all an issue of overlapping volumes and cage meshes and bake settings should be able to be the same across assets if they only have a normalized size. It took a while before it was clear that the true power came from stringing all of these steps together, and that once such a set up existed, we could attach any additional features on top of that framework. Hence, we needed sort of a purpose built Houdini engine for it all so that the input could easily be set up by artists. It wasn't initially clear that such a set up could run any process, and hence the asset processor was originally called the hard surface processor. Let's start by taking a look at what it looks like in practice on a simple asset in a dress

down way before getting deeper into it. As always, we begin by finding a reference for whatever it is that we want to recreate for our game. In this case, it's a fast food restaurant table.

We begin by building the low poly, much like it will appear in game later. If we run the asset processor now, we'll see that it has already created UVs, a high poly and bakes for us to review inside of Blender. But we're obviously missing some important features from our reference, so let's attend to that next. We create intersection objects that will separate out the wooden parts of the tabletop and seat. If we process again and review the results, we'll see that these parts of the assets have now been separated in the high poly and that that information has been transferred to our low poly. We might have to look really closely for this. This arrow points you to what has changed. Of course, this processing between each step is just for clarity presentation purposes. You don't actually have to do it. Next, we add the slice planes to separate the wooden chunks into individual planks. We process again and we see that this indeed did the trick. There's an arrow again showing you what happened. And next we turn to adding the smaller details, like the bolts along the edge of the table and the welds where the metal parts have been attached. We do this through adding simple cylinders and boxes and if we process again, we can observe the results. So we have the bolt stuff and the little weld thingy. And now we're happy with the asset and we can spend a moment to marvel at our creation. This will have demonstrated some of the basic functionality of our hard surface process,

but it's of course important to realize that this won't only make tables for us. We run the very

same process for all kinds of assets, weapons, vehicles, tiny weapon charms, enormous killer robots from space, and everything in between. Next up, we'll take a closer look at how the asset processor is used for a weapons asset, since those have traditionally been some of the most difficult and time-consuming assets to create. Here's what it looks like inside

of Blender with the asset processor UI open. And let me pause here straight away, because internally we've been discussing the level of fear that a UI should be allowed to instill in users. And I'll actually go through this section by section and explain what it does.

But first, let me take a quick detour, if you'll allow. A quick aside on UI. The way I see it, there are two types of UI. UI that is made for novice users, which need to be instantly understandable and non-threatening, where getting deeper into something is designed to take time so as to ease the time. these users into it. The other type of UI is one that's built for expert users where what matters most is instant access to functionality without having to go through submenus of submenus to find what you're after.

To demonstrate this, consider the common keyboard, for instance, it has a plethora of buttons with very little obvious categorization at a first or even second glance. But since all of us are expert keyboard users, I presume, we've learned that there are letters and numbers and the numpad and the F keys and the special characters and special buttons and other special buttons and arrows and maybe most importantly, the space bar. And it's just to show, people should be scared, but they're not because this is the type of functionality that you want when you're an expert user.

And my favorite example of this is actually the, if somebody's familiar with the Nightshade UV Editor for Maya, which is, this goes way back, but it presents everything for you immediately and it was so awesome to work with, like when doing manual UVs was a thing, it's not anymore. And then when Autodesk went about implementing this into native Maya, they lost some stuff in translation. So the same functionality exists, but they hid it in menus and submenus and it just made working with UVs difficult again for no obvious reason other than probably making sure that novice users weren't afraid by all of the power at their fingertips. Let me get back to the asset processor. So let's go through the asset processor UI properly. Not that I expect you to be using this directly after the presentation, but I think it would be good Anyways, so at the top, we have the scenes that we use to separate out. I mean, it makes dealing with work easier when you're like, here's the input and I get the output in a different scene. Next up, we have the process button, which is what runs the process. You also have a little setting to determine if you want to run all of the assets in the scene or just part of an asset and so on to speed up iteration times. And the log, and I'll return to the log later. And then you have the asset settings, where you set the name of the asset and what type of asset it is and so on with asset specific tags. You have the component section, which is the parts that make up an asset. And then the sub component setting, which is the parts that make up the sub component. And then you have the object settings where you say what type of object and input is. And all of this, of course, works then as a hierarchy within the asset. And at the bottom we have the substance painter to open the automatically set up project and reload all of the resources and so on when you've processed. And then there's some more UI. Where we have the object specific settings. So depending on what object type you've set, you'll have different settings here where you can set the material for instance. In the hard surface process, It's used to set the ID colors on the output bakes, and it's also used to set the level of roundness on the generated high poly with presets like sharp, sharpest, and that's bad naming, so now we also have sharpest plus plus. And then you have object tags. Some of these are absolutely essential, like being able to set what type of Unreal Engine material slot an object gets after the fact, if you need to override that type of stuff. Other things is just, it's my limited monkey brain not being able to figure out how to do certain things automatically yet, but I know it should be possible and I'll get there eventually. Like overriding, getting more subdivision steps on the automatic high-poly generation and so on. Like nobody should have to do it, but currently sometimes we do, and just to make sure that it always works, we have these extra tags to make sure that it does. Then we also have some additional edge tags. I'll get to the, no I won't, but they do stuff. And then there's, we have automatic matching for most things, but that's another step where like, if it fails for some reason, you can override it by setting the matching automatically, and that's like matching a subtract boolean to a mid poly object or whatever. And anytime you want to match an object to multiple other objects, you also have to set up the matching manually, but it's as easy as clicking the object and clicking match too, so that's really nice. And then we have something called the Melt Set, which is, I'll get to that maybe, it's Melt Set. And that's what that looks like. And the log it a tiny window into a black box Since any type of process depends on the input being correctly set up and there only so much that can be done automatically inside of Houdini to try to fix it, we need a way of letting artists know whenever there's something that's either been set up incorrectly or that has gone wrong during the process. This is a log from an asset that wasn't, or that was built before these log messages were implemented. So it showcases nicely the number of things that we can catch now that would be difficult for an artist to notice or even know about before. The log tells users about process time, errors, warnings, and generally information. Some of the log messages also come with operators for either selecting the problematic objects or automatically cleaning up things that the asset processor thinks are likely to be input errors. The log messages themselves are output from really neat SOPs and TOPs HDAs, which makes adding more of them from inside of Houdini super easy. We'll now take a look at what running the process from inside of Blender actually looks like on a real asset,

not a table asset, it's a silly demonstration object. So we have the same low poly input, and I'll just unhide some other object types here. So there we have a cast plane for making those plastic cast seams. And here's some add the booleans to add some details to the front grip and some subtract booleans to, well, subtract. And some intersection booleans on the back of those shell casings to get some additional detail there as well. And then I think it's time to press process. And I'll speed up the process time here for your consideration. But this is, so you have a progress bar, it tells you what's going on in the, and this is where I realized that I can showcase that you can continue working on the asset while you're processing, obviously. I won't do any productive work here, I'll just showcase the functionality. so I'll do some silly edits to the low poly mesh while it's processing in the background, make this grip a bit longer, extend that cast seam a bit to make sure that it still matches up, and then we'll go back to me patiently waiting for the process to run. And it opens up the painter to do all the baking stuff, and if we go to the export scene, we'll see that it has generated a high poly, generated UVs, generated bakes, and output it all into the proper painter setups and everything, and for us to review it inside of Blender. And if we go back here, we see that obviously the silly changes I made, hadn't made it into that round of process, so I'll process again just to show what that iteration looks like. Of course, I could have showcased something more useful here, like adding more details or adding a scope or whatever, but the important thing is seeing that, oh, look at that, it has made a new high poly and new UVs and new bakes and actually a new rig and so on as well.

So that's the gist of it.

And here's what that asset looks like inside of Unreal with textures applied to it.

And I was actually surprised by, like initially I imagined

that we would have to do a lot more, like I mentioned,

that these automatic setups would work in some cases,

maybe half of the cases, but it turns out that I think

this mesh has maybe like one or two actual high poly inputs and everything else is just automated,

and those are like some minor springs, and I'll get around to why that is. Talk a bit about the input that we use,

and what comes out of it. So the main input is the low poly, and there are a number of reasons for this. I mean, the low poly is what matters most, because in games, that's the only thing that actually makes it into the game. The rest is just data. And it's also the thing that's most easy to build. Like if you would have approached it from a different direction, say you build a high poly and you generate the rest, not only would it be difficult, but of course it's more difficult to build a high poly than it is to build a low poly. And then we have the booleans, like I showed, all of the common basic ones. We also set edge tags, which is a major thing, like setting sharp edges to have them act as creases for the high poly generation and as UV splits in the UV process and so on And then the tags that you saw like enabling automatic rigging of facets and so on And we can also, we can input UVs because I can't rely on automatic UVs always doing the trick, and I'll get back to how that works. And then we have the additional input geometry. So you can input an actual high poly or what we call a mid poly, which is, I won't talk about it, but it makes sense. And some of the other details and so on.

And that's the type of input that it takes. Just to go through the edge tags, because they're important, it looks complicated, and it's not, so we use Blender's default, like, edge tags where you can mark sharp, you can mark seam, and you can crease. And it's just the mark sharp does the creasing and the UV splitting, but if you only want one or the other, you use the crease or UV seam instead. And Houdini awakens and does all of the hidden magical things. So we run everything through a PDG net. It looks simple here, but it's subnets in subnets and so on. Most of this is the same for any type of asset and any type of process that we run, with the important thing being the processes right after the import, where it's dynamically spawns processes depending on what processes exist in the thing currently being processed. And we did that because we noticed that since our processes are quite heavy, it took a long time, like additional time to process just because we spawned in all of the processes. I don't know if this has changed. Like something happened in Houdini 19.5 where it shaved off like minutes on the processing just on the opening files, and it's glorious. Like spending a lot of time optimizing stuff and then suddenly just updating Houdini and getting huge optimizations. It's like, thank you. And then it does the export and the baking and so on. And the input, I'll talk a bit about how it's being treated inside of Houdini.

And not a lot of things happen to the low poly because it's close to what it needs to be, but like flat edges get dissolved and so on, and hidden faces get removed as well, so it's just checking whether faces are actually exposed and if they're not, why not remove them, and it's a nice treat for artists where they're like, oh, 200 faces were removed and I didn't even have to care. I'm like, yes, there's more.

And the UVs, it's trickier automating UVs. automating UVs. I know that there's a lot of like automatic UV solutions and I mean Houdini has its own auto UVs and it's not, I mean it gives you UVs but it doesn't give you the UVs you want when you're making games. So this is I think like the most complex part of the setup because there's a

lot of edge cases and I'll go through like a basic overview of what the setup does. So first it It sorts out special types of geometry. So like toruses, googled it, and you can also say tori would be the Latin plural of the torus, and pipes and spheres and so on that have like quite special requirements for UVs. And it's just, it's been a lot of fun finding ways to detect these geometries in Houdini, being like what makes a torus a torus? That's the type of thing that we enjoy talking about at Embark. We've solved it. And you think nobody's ever gonna use this. Like how many toruses do we have on our assets? And then it shows up all the time. And then again, people don't know that this is difficult. They just add a torus and it gets automatically UV unwrapped and so on and it works. And you're like, yes, we got it. And then it does the standardized, like cutting off all of the hard edges, splitting those into, I noticed now that I haven't updated the text for this. So we used to come and add, that's not right. We split up all of the hard edges into separate shells, and then we determine which shells still have a lot of distortion, and then we do some checks to find where the ideal seam location would be for those shells, and we split them and unwrap them, and we determine whether or not that was successful, and so on, and once we have nice shells, we need to make sure that they're properly aligned. A lot of the time they are automatically from the flattened node, but sometimes also they aren't, so if you're interested in this stuff, I mean, you want them to align because you want the pixels to align with the borders of the shells and so on, so what we do is we take the borders of UV shells and we look at all of the edge angles, and we take the accumulated length of all of the parallel or perpendicular edges and we align it to those and it glorious Next up, this isn't actually implemented yet and it's been in development for years now and I saw a post just this morning where somebody is like, shouldn't these be stacked? Yes, they should, I'm sorry. But what it does is it takes a lot of things into consideration like the area of a shell and the number of points and the AO requirements or whether there are any details on it and from what angle you can see them and so on and then it tries to determine what shells you can overlap because this is obviously doing it manually. It's a painful and slow work and people get it wrong and then they have to redo stuff and so it needs to be automated. And then it does the layout which is, I mean the default UV layout node in Houdini is amazing and it's fast and it does a great job. And we just need to make sure that we check for additional things like whether or not it should be a square layout or a non-square layout and so on to optimize for UV coverage. And also determine things like the amount of padding between shells depending on what type of asset it is and how big it is and what the ideal output texture resolution is and what shells should be scaled up and scaled down and so on depending on how much they're seen and from what angle, and there's a lot of that stuff that needs to happen. That's the basic, then you have automatic UVs for hard surface stuff at least.

And then we have some additional UV features, which is like I call them closed strips for instance, which they're not distorted, but we wanna split them anyways and we wanna straighten them so that we optimize UV space and it's one of those things that's very neat. And for a mesh like this that doesn't have perfect grid topology, it's a bit more difficult, but we can still make a medial axis skeleton and then we point deform it and so on. And it's a lot of just trying to do things and then after the fact evaluating it and going back a step. It didn't work for this one, but it works sometimes. So we do that a lot.

And then there's this neat feature, which is like a lot of the time, when people expect automatic UVs, they'll just accept whatever they get, and they shouldn't, they should review work. But the super nice feature is when you have really long shells, of course, the entire layout will be limited by the size of that one shell. So what the process does is it says, it says, wait a minute, this is long, you're gonna get super bad coverage, even with a non-square layout like this one. So I'll split it for you, and then I'll do that, and then you get much better coverage, which is nice. And then the scaling, so we have like input locator, or like empty in Blender, that's like this is the camera position for the weapon, please scale up and scale down UVs and so on.

And then, this is incredible. We also, for weapons and gadgets and anything that needs skins, we get a secondary UV set with tileable UVs. It looks horrible, but if you know about this, it's supposed to. It's difficult to work with because it's so horrible, but computers are good at this stuff once we've figured it out. It's like, you start with the shell and then you get another one and try to align it and match it up, and so you have nicely flowing patterns across assets, actually, and across UV shells and across everything, which is, like, it takes days per asset doing just this UV set, and it's one of those things, like, iteration times, going back, changing this weapon to something else or adding something and then being all like, oh, I have to revisit this UV nightmare. No, no, you don't. It's automated. Beautiful.

But then, of course, we need to be able to keep input UVs because what if there's something that the automatic UVs can't do yet? And see how silly this is. The way that I've thought about doing it, and it's not optimal and it's not intuitive, and I'm ashamed and I'm being vulnerable right now, is it's the only type of input that we're currently setting on a per-face basis. So everything else, I mean, we can set it on the mesh as a tag and so on, but this, since this, I mean, you want to be able to have a large complex mesh and then say, oh, it fails on this one difficult area, I just want to make that one shell manually and then do all of the rest automatically, which means that we have to make that UV in the UVs anyway. So the way that we do it is we set up multiple UV channels on the input. and they do different things. And then depending on where you place those UV shells in the UV space, you either keep them or you make them automatically, or you say, I don't even want any UVs for this thing, so I'll place that shell over here. And it's proven to be a very important thing to have. Surprisingly though, I thought it would be used mostly for shells that just don't unwrap nicely, but it's used mostly for things like having a secondary UV set with decals on it. So it's really like this one phase should just be mapped to the zero to one space in the secondary UV space. And it's like, I can't do that automatically. So we have this.

And next onto the high poly, it's all about volume.

And I'll do the same thing where I just go through the like an overview of what it looks like. First, we need to make sure that we cap all of our meshes since otherwise we can't convert them to volumes. The process tries to cap everything automatically, but since that's also difficult sometimes, what we do is you actually, you can cap the mesh inside of Blender and then we add what we call a delete material to those faces, which just tells the process that for the low poly generation, remove these faces, but for the high poly, we want to keep them for volume conversion. And it does a matching of all of the objects. It creates everything that objects can match to gets converted to a point cloud, and then all of the objects that need to match to something, they just group those points by volume, and then determines which one do I belong to, and which points can I actually be matched to, and so on. And it sounds straightforward, but then it turns out that when you have so many object types that can match in so many ways and so on, it's a bit complicated. In Houdini, not for users, but for me. And then it does a subdivision of the mesh, so it takes all of the hard edges and all of the input creases, and it creases them just to a maximum, and then does a subdivision. And this is also something that I figured that it would fail a lot for these slightly round shapes, because it's, I mean, being a subdivision, it obviously still relies on topology and so on, but since we later turn this into BDBs and polish them and so on. A lot of those, like the pinching that happens and so on gets smoothed out anyway. So it works almost all of the time. And when it doesn't, you just add a few more loops like if you were building subdivision models and those that just get dissolved in the low poly generation anyways. And then we have details. So it's all those boxes that we added for like saying I want to weld here. It generates those welds and so on. I mean, it's simple creating splines and adding things to them. And we have bolts and cast seams, and I'll talk more about those. And then it converts everything to VDB and applies all of the Boolean operations. In the previous talk that I held in 2021, we did the Booleans on geometry, and I applauded Houdini for having such a solid Boolean Boolean system, even on geometry. But then I figured what's more solid? Volumes. And since we convert everything to volumes anyways, why not do it instead of doing the, because what I was doing then was converting everything multiple times to volumes and back and forth, and it doesn't make sense, and this is a lot faster just doing everything with volumes. And then the polishing and so on, and it looks like a high poly. And then of course we automatically as well reduce it and this is mostly because it saves a lot of time on reading and writing those files and we would, especially for like the big robot enemies that you saw, like when those are volumes and converted to geometry and then you try to save those out and even with like 256 gigs of RAM the computer would be upset, and so this helps a lot. Even if it takes time reducing the meshes, it saves time. Taking time saves time. And then we have some, I'll go in a bit deeper on the high poly, how much am I, I'm talking a lot, sorry, Darko. We have Bolt, which is like, I don't know, it's proceduralism 101, But it's, yeah, you make all of the possible bolts with all of the possible inputs. And people set this in the asset processor UI where it's like, I would want this type of bolt. And of course, all of the permutations gives us hundreds and hundreds of bolt types. And so we input the cylinders in Blender to the left. And in the high poly generation, we see that we have. And it one of those things where if you feedbacked on other people meshes and they built bolts and the bolts don look like bolts You wanna fix bolts forever so that people don have to model their own ugly bolts

And then we have cast seams, which is you input this plane and where the plane cuts the mesh, you get these. Maybe it's hard to see here, but it's those subtle details to get like plastic to look like plastic and so on. It's also one of those things where like people would do it in other, like a subdivision model and you add the splits and you just move it out a bit, and it's too wide, and it messes up the volumes. And then welds, what they look like currently is what they look like to the left, and it works most of the time. I did some tests on improving them and making them look more nice and so on, but it hasn't been implemented yet. But it's one of those things, again, where everything is procedural. When I push this, everybody will suddenly just automatically be able to make nicer looking welds forever, which is what we want, progress.

I'll talk a bit about some of the limitations with doing automatic high poly generation with VDBs, which is of course, say we want to shape like this, but we're good 3D artists, so we want to optimize what the low poly looks like. Of course, if we process that, it will look like this, which is wrong. How do we solve this? We input the high poly. That's the way to do it. And then we get a nice baked result because even if we were to process this low poly, since everything is VDB, it would just melt it, right? And it wouldn't look the way it should, so we have the option to input high polys. Another limitation is it doesn't deal very well with the super tight geometry. Ah, it broke. And the way to fix this is, of course, adding a lot of voxels, which is heavy and silly and so on. So it's another good case where maybe you just want to input the high poly instead or make the mesh ticker. Baking, transfer the glorious information. So we've automated like mesh explosion. If you ever baked AO, you know that it has specialty. Duplicate everything and you move it out and you export everything and it's a hassle. So instead we have shown at the top here, we have those two tags for our components, which are parts of our assets, where we say, I want this one to not cast AO on the surrounding components, or I want this one to not receive AO from the other components. And then of course you can enable both of them to say that this acts as an isolated bake, which just makes this super easy. And we also have the option to like, when you've split something, so what happens is of course you duplicate a lot of the asset a lot of the time. This is a very simple setup, but some of them, they go on for miles. You can add additional AO objects. You can actually, like, you can have an isolated bake for something, but then you can say, oh, I still want to fake some AO shadows here, so you add a box or whatever to still get those. And it's easy, finally.

And for the baking, it also automatically creates the skew mesh, and this is done by simply subdividing the UV, the low poly, which works also surprisingly well, like almost all of the time. There are some cases when it doesn't. So say you have a low poly, like low poly, low poly cylinder like this for instance, where you have baked details along the edge. You'll get a fair amount of skewing. So we have a tag for low poly objects where you can enable bevel skew mesh, where what it does instead is it tries to bevel. So this is on geometry, which is always tricky, which is why it isn't on by default, because it will fail sometimes. But it bevels the low poly instead, and then you don't get any skewing. And again, if that doesn't work, you can also do the thing where you just add more geometry to the low poly and you dissolve those edges anyways, but that's of course more manual.

And all of the baking happens in Painter. We tried out a lot of baking softwares, but the Painter just gives really nice, it was tricky from the start because how do you automate to Painter? Nobody can, nobody can, but you hack it a lot until it works, until in their latest update, They've updated the baker and there's a lot more hacking that needs to happen to make it work on the latest version again. But everything goes into Painter anyways and it gives us exactly what we need and what we want and it's super, super fast. So it's, in hindsight, it's an obvious choice. That's not how obviousness works.

And rigging, which was also one of those things where we had this entire setup. All procedural, we can make iterations in a matter of minutes. But then of course our assets are rigged. So even if you made those updates where you just like, I wanna change what the site picture of this weapon looks like, you update it, and then it's like, you gotta tap on the shoulder of a tech animator, and you're like, I've updated it again, and they're like, that the fourth time this morning what are you So we figured why not automate the rigging also So whenever you process you actually create a new rig since we have all of the information already. I mean, everything is split up into the components and we have origins for location. Then if we just read all of those and we treat them as joints and we have some simple tags and settings to set up these hierarchies where we say, oh, this is the bipod. It should have a joint. That should be a jiggle joint. So it does the little tech anime jiggly stuff. And it should be a child of the bipod so that the bipod itself can also move. And then we just figure out the rest in Houdini. And it's been amazing. And it's one of those things where we're like, we can do it, sort of, but what happens when we want soft skinning and what happens when we, it's just luckily we haven't encountered it yet. So currently all of the weapons and so on are actually rigged automatically by the 3D artists by using these tools instead. The only learning thing that has to happen, of course, is that they need to know a bit about where do you place joints and so on. I figured they can learn, and they have. Or they, he, we have one.

And just to showcase, this is what the, I mean, you all know what the rig looks like, but this is what it looks like in Unreal. is an auto rig and me trying to use controls.

And like I mentioned, when we have this entire setup, it means that we can attach more processes to it whenever. So a fun, special example of this was our effects artists were like, we wanna make this cool holographic effect on meshes, can you build, can you build like mesh strips? for the wireframe of the mesh, but also clean it up and also combine it all into one asset, and also, and I'm like, yes. It would have been a pain before, also in terms of iterations, where it's like we make updates to this asset, and then we also have this effects mesh to think about, but now what we do is we enable the effects mesh tag, and with some simple, straightforward Houdini work, it just always outputs that effects mesh. So it's, and again, it would have been problematic. I mean, we could have made the same Houdini process, but it's also the building, and then the artists would have to go into Houdini and run that thing manually. Now it's just that tag is enabled, that happens automatically, and everyone's a winner.

And then we have to scatter something, because it's Houdini. So I've been investigating in my spare time, if my boss is watching this, Scattering of dust particles on weapons, just seeing like, can we push things to the next level? Because I've been, for a long time, super inspired by, I don't know if you've seen those, like, Marek Denko renders of chess pieces with bits of hair on them and so on, and you're like, that's real. And if we can do the same thing in games, it would probably have to be, like, alpha cards and so on. a lot to not only have it in the texture, or in the material rather, but have like fibers and so on, like cross borders and mesh changes and it's amazing. It'll look a bit disgusting

because it's too much. Somebody's cat slept on this AK. But it does a lot to sell the of a piece, if only it's actually visible in game, which is yet to be determined. And now I'll briefly, before I end, go through our other processes

that we also run through the asset processor. So we have Concretefy, now just last week it was, it's no longer Concretefy, it's Edgeware. Yeah, but it does those like concrete structures concrete structures that you saw in the, it's a simple proceduralism in that it's edge damage and it's UV mapping and it's adding edge, I mean, it's not simple, it takes time to develop, but it's straightforward, like how it works, and the fact that we can also run it just straight from Blender, like it has, at one point it was a Houdini engine tool, and at one point we used like a live link to Houdini where we ran it and so on, but now it's just, you work in Blender, you set it up just as you would set up any other asset and you run process and it gives you this.

And then we have the trim mapper, which is just, I mean, you take basic geometry and it just creates UVs, which is pretty straightforward with these types of assets compared to the other things that we've seen. And then maps it to a predefined trim layout and applies vertex colors for inverting the normals, depending on, there's a lot of things going on, but it's there and it works and it's cool.

And then the tiniest process that we have with the cable process. So, we realized that in our creators, we have a lot of cables everywhere because they nice and it makes things look organic But it added a lot of narrow triangles long narrow triangles everywhere So what we wanted to do instead is adding like thin mesh strips and use a spline thicken shader in Unreal instead. But of course, building those thin mesh strips and UV mapping them manually and so on, they're difficult to work with because you basically can't see them because they're tiny. And so instead the artist will input like proper tubes and so on in Blender, and Houdini will take care of the rest. Which is also nice, because then we can also actually, I don't think that was implemented here yet, but we can also, I mean, it's part of the entire asset, so those splines, like those cables, will also affect the AO bake of the hard surface parts and then so on, which is nice.

And then we have cloth process, which is not actually run through the asset processor, but I thought this was a nice image to showcase a lot of the other processes that we run, and the cloth looks good, but it's Houdini. So, Houdini engine in Unreal. And that's it for the presentation. I'll talk a bit about the future and where we're at and so on. And there's still a lot of work left to be done, of course. We have like 10 of our artists, which is basically all of our artists using it now. And some tech artists are using it as well to create art, which they're happy about. And the concept artists as well, which is something that we've been striving for all the time. Like, concept artists are good artists. They just don't want to be bothered with all of the technical stuff. Now they don't have to. So why don't they build games assets? And they do, which is super nice. And we still encounter issues almost daily. I wake up now every morning, doing, looking in the processor channel and being like, what has happened now? And it's mostly because we've ramped up so much in terms of usage. But the issues are, of course, smaller and smaller all the time. It used to be I can't process. And now it's like, why did this UV shell do this thing? And it's like, we can fix it. And the biggest issue that we face is actually one of, like, in terms of setup, where a lot of this needs, Like, you need to have Houdini installed and Painter installed and Blender installed with the right versions and GitHub and pulling things from Perforce. Whenever people haven't followed the documentation on how to set that up properly, things will fail and it's like nothing works! Which is a hassle. But once people have it set up, it works. So it's a super big issue. It's just what you get when you have artists building tools. You don't have the neat batch, exe, set up, everything works. Another struggle that we have is too high user expectations. Whenever you try to sell easy and automatic, people expect super easy and fully automatic.

And it makes, like I mentioned before, it makes people not review the output properly all the time, which again, the log helps with, because it's gonna tell you, like, this didn't work. please investigate. And it also makes it easier for people to get into it knowing that it's not magic, it's just super awesome. And I think what's needed there is just better documentation on the limitations that we still have to manage expectations a bit, because expectations go through the roof. And I think that's it for my part of the presentation. Thank you. Do we want to do questions now, or do we want to do Daku's presentation? I'm sorry, Daku. I'm a timed thief. We're okay. We're just going to talk to the rest of it. Yeah, we can, if there are any questions, can take a few questions, and then Daku can do his stuff. Yes? Yes? Hi, are you using the interface between Blender and Houdini, or are you using Houdini Engine, or is it still a custom? No, Houdini Engine, because Houdini Engine doesn't exist for Blender, because Blender is free to everyone forever and so on, and they can't do any of that stuff. So it's only custom, all internally built, everything. Awesome. Yeah. Yes? How do you do technical artists? We have quite a lot of technical artists. I think we have probably more technical artists than we have actual artists. They're also actual artists, just for the record. But this was actually built mostly, like primarily, with the help of tech artists. But it was built primarily by me and another artist. So it's, but with a lot of help whenever we're like, we're too dumb, and then they help out. We have a lot of really talented tech artists.