TL;DRThe hardest parts are the organic shapes on a hard-surface asset and making animated mechanisms work without parts intersecting, which they address by blocking out and rigging early to test in-engine.
I know that already. I've had to tackle it a bit. And it's this area around here, all this kind of gubbins, because if I focus on the concept a sec, not only have you got these really difficult organic shapes in a hard surface asset, they're all very slightly turning in.
Yeah, that's one of the biggest... One of the problems we need to tackle while doing it is that everything needs to be animated, it needs to work, the magazine needs to rotate out, it has a mechanism and all that needs to work, and the parts shouldn't intersect, shouldn't move into each other and have that ugly intersection. That's something we need to prevent while doing it.
And of course, that's something that concept artists know to look out for, through metrics and stuff like that. But you don't always discover every single edge case and issue during the concept process.
That's why we're doing a block out. We're doing this block out in this state and already do a rig. A rig is basically a skeleton that an animator can use. The animator then tests it in engine. While doing it, we usually run into issues and see how this works out. Here we can see that the mechanism is pretty nice. We can test all that in-engine and reiterate on it, because in this state it's really easy to rebuild something or change something. But if it's final and we have already made textures and so on, the more we've done on it, the harder it gets to change. So in this state, it's still pretty easy to change around shapes and rebuild it.
TL;DRA tool to automatically bake concept models into game assets isn't realistic now, as the workflow is too specific and changeable; automation helps artists but doesn't replace them, and full automation might be 10 to 20 years away.
Yeah, I think there's a lot of automation that can be done for 3D modeling, but I think it's just due to the fact that we've got such a specific workflow. It would be very difficult to get a computer program or an algorithm or something to actually reproduce those results perfectly. We do use, for things like LODs, in some of the workflows we have systems that generate our LODs for us. We have a lot of scripts to automate parts of the process, but as a whole, because we have this focus on optimization and we have a lot of different requirements that really, for a human, once you know the rule set, it's quite simple, but for getting AI or some sort of program to do it, man, I think maybe in 10 years, maybe in 20 years or something, we might be closer to that.
It would also require a longer concept period, because all of those absolute things, the functionality, would have to be completely, totally and utterly worked out in the concept phase. And while we certainly target that and we certainly take those things in mind during the concept phase, anybody that's followed the development over time knows that sometimes things just have to change from concept because metrics change. The scale and scope of development changes. The lessons we learn along the way as we make each one of these improve. It's a lot easier for a human to adapt than it is for some automated tool.
Yeah. I think if you look back at a lot of the workflows that we had even 10 years ago for video games, it has changed. We have seen a lot of changes in that there are a lot of workflows that do rely more on procedural generation or computer-assisted stuff. But yeah, I think it's a conversation, obviously, as we have a lot: how long is it until our jobs are going to radically change because of things like deep learning algorithms and stuff. I think NVIDIA has done some interesting stuff like landscape generators and things, right? When are they going to make a landscape generator for 3D art? I think with hard surface assets, because they're so organized in their structure, it's really hard to get a computer to make them, if that makes sense. I know that sounds counter-intuitive, but when you have an organic asset, it doesn't really matter if the topology isn't perfect. You can just munch it. I think things like photogrammetry and stuff generally work better on rocks.
One of the core tenets of Star Citizen is that we use automation and tools and everything to help our workflow and to assist artists, but not to take over the work from them. Some games would use procedural generation and spit out the finished product. We use procedural generation in our planets and stuff to provide a base from which artists then go and do their work after the fact. We use scripts and that kind of stuff to help us along the way, but not to do the work for us. At least today, there's no substitute for that human touch.
TL;DRA weapon usually takes about two weeks if all goes well, up to around a month if problems surface late, such as the shotgun magazine and barrel clipping the character and needing changes.
It depends on how many problems come up while doing it. In the optimal case, you can do it in about two weeks, I would say. In a non-optimal case, where we need to change a lot, where problems come up and we realize them pretty late in the process, and that sometimes happens, sadly, it can take up to a month or so. So sometimes when problems come up super late in the process, that eats up a lot of time. But usually we try to plan it pretty well and get it done as fast as possible.
That's the main reason for the block out phase. What we normally do is we get the concept mesh running through some optimization processes and get that in game. And then we can see the character holding it. We can say, does this work on the male rig? Does this work on the female rig? Does it tick the boxes for the hand grips and stuff? Jake will probably show you another weapon later where we had to make some adjustments to the weapon from the concept because the grip wasn't quite working. While the concept artists are very aware of the application of a weapon, like a human holding it, they can't necessarily test all the use cases. Sometimes we do come back and we get it in and we're like, okay, this isn't working, tweak the proportions here, make some changes, just purely because it needs to be used by a character.
I can show that now. One of the problems that came up, for example, with the shotgun here is that the magazine actually stuck a little bit too much into the armor of the character. And we had to address that. And that's something, while doing the weapon itself, sometimes you can't even think about: the possibility that the magazine, because of the shape it has, clips too much into the body of the character. And therefore we had to change the orientation of it so that the flat side is on the body and not the round side that you can see here. If that makes sense.
So some of those changes that you guys are mentioning, if I change over to the shotgun concept, this was the concept that we were given. I can't really show them side by side, so I'm just going to quickly flash between the two of them. But if I point it out in the concept here, we've got this trigger and then this nice angle here that leads into the magazine, and then it leads out into this really nice long barrel. And this area is where most of the change happened. We were having issues with what you said, David, like the character's arm clipping with this barrel. We're limited, right, by how big this barrel needs to be, because we want it to specifically contain, I think it was 12 shotgun shells. So I had to make this thicker. This has to be sitting right up against the trigger now. And this whole nose area had to be brought way back. And because there's a pump action as well, if you look here, the handle's quite slim. And if you were to grab that and drag that back and forth, you'd probably break your fingers on this or something.
TL;DRThe weapon's polygon count is high, but their custom-normals workflow means vertex count matters most, and weapons use LODs like ships, trading extra geometry for much less texture memory.
Yeah, I think I can say something about that. So you can see this one, together with the magazine, is around 52,000 polygons, which sounds like quite a bit, but you need to consider we have a different workflow than most other studios have. So our workflow is custom normals. So all these, at the front... oh, Jake is showing it with the cube here. So yeah, this has 12, and if you bevel it, it already has 44. But if you select the vertices on it now, if you can select all of them, you will see that it's 24. And that's because of the hard edges here; the hard edges basically split the object into multiple faces on the left cube.
Exactly. And the vertex count is actually the same for them, or nearly the same. So what actually matters in the end is the vertex count. And another thing that matters is small polygons, but we are using levels of detail on the weapon. So after about one meter or one meter fifty, it's already getting rid of the small little bevels here at the side. So basically after one meter fifty, you see the left cube instead of the right cube.
Right, so our weapons use the same LODs that ships do, so that way when we look up close at it, we can see all the full crazy detail. And then everybody else who's running around in-game, they're seeing a lower LOD version until they get really up close.
It's also worth mentioning, and I'm not an engineer or a graphics programmer, so this is going to be a layman's explanation, but the advantage of this workflow where you're putting a lot of detail in the geometry: of course, it will increase your triangle count, your vertex count. However, in a lot of games, like I said earlier, they actually bake the high poly information into a lower poly version, and they create a texture for that called a normal map, which essentially per pixel will give you the angle. Say you have 200 props or weapons in a scene and you're loading in 200 of those unique textures, it's quite a lot of texture memory. Whereas with our workflow, we do use textures for some things like POMs, the materials themselves and so on, but we don't have a lot of unique texture memory taken up per asset. We're basically taking up more overhead in terms of poly count, but we're also reducing the amount of texture overhead in a way. So it's swings and roundabouts. I think hardware is a huge part of that, and that's not really a topic I'm hugely educated on, actually, what modern specs are for graphics cards. It's a difficult one to really explain as an artist, but essentially we're prioritizing reducing texture memory versus the amount of triangles we have.
TL;DROnly the top rounds in a magazine are fully modeled, with deeper ones simplified or left undrawn, since capacity is stored as a value, all to save performance and texture memory.
We need to trick it a little bit so we don't have too many polygons. So the top round is usually modeled completely. And the one under it has a little bit less detail than the top one. And if you go even deeper into the magazine, you maybe even have a cylinder with the red stripes. So if you have a glimpse from the side... in this case, you can still see it pretty well. But on some magazines, the shadow is actually taking away the detail anyway, so you can use less detail the deeper you go in.
Yeah. Things like grenade launchers and such, where all the, well, not bullets, but rounds are visible, they'd have to be modeled in. But in terms of the capacity and stuff, that's stored as a value somewhere, so they're kind of there, but sometimes they're not drawn.
That's true for most video games, I think, or at least it should be. Yeah, even though we use more polygons, the workflow we do is still optimized quite a bit. We're not using a heavy load of textures, like Cory said before, which, in some cases, if you use a 2,000x2,000 resolution or 4,000x4,000, you can easily get to 100 megabytes per weapon. And if we have 100 weapons in-game, it gets too heavy and we had to think about ways of reducing it. And our workflow with the custom normals is really scalable. You can use it on weapons, you can use it on buildings. It doesn't really matter what you do with it, it all works. That's why it's so strong, in my opinion.
The scalability is really important, especially for props, for instance, where you have an absolutely obscene amount of them. We want them to look good, we want them to have a lot of detail, and we also want them to be fairly cheap.
TL;DRSoftware matters little; keep practicing, use reference, seek feedback from communities, pick a field you like, and learn game-specific techniques, since real-time game art is technical and differs from film.
For starters, the software really doesn't matter that much, I would say. You can use Blender, it's free. Or you just try to get a version from your uni or so; if you're using Maya or Max, that's also good. Most of the people in the industry use Maya or Max, so that's always a safe bet, I would say. But what's most important is that you keep doing work. Even if it's not good in the beginning, just continue, don't stop doing your work, try to improve. Try to get into fields that you're interested in. If you like characters, go into characters. And if you go more for weapons, then try to do a lot of weapons, right? Try to learn more about weapons, how they work. Because, for example, on weapons, you need to understand the mechanics behind it a little bit at least. So, yeah, it's always helpful to have a proper mindset for what you're doing. And that's really important.
Yeah. I think using reference is a very important thing when you're starting out as well. Also, there are tons of communities out there for getting feedback and stuff. You'll find that there are a lot of communities where you'd have industry veterans in Discords and stuff. You can get feedback from them. They can tell you where you're making mistakes with your modeling. I think reproducing a shape is quite easy. Reproducing a shape elegantly is where the challenge is in what I would call production art. We're not necessarily concept artists. We're not designing these forms ourselves, but we're reproducing them with a set of criteria. If you think about it like pixel art, if you're a pixel artist, you're employing a bunch of techniques to reproduce something in that sort of style. This is sort of similar. If you're interested in video games specifically, getting into being a 3D artist for video games, definitely learning about the techniques that we employ is going to get you a long way. Or if you're interested in CGI, like film and stuff, they use a whole other bag of tricks.
Probably modeling for them looks like the concept you showed before. So for film, of course, they need to look that they don't use five million polygons for a screw, but they don't care too much about the polygon quality. That's more for game art, that we have to look at how optimized it is. For example, for this piece we have 200 polygons, and for films you could use a couple of thousand for this piece alone here.
Real-time rendering means we're rendering the asset 60, 120, however many frames per second. So it's very specialist hardware doing a very specialist task. For films, they chuck it on an offline render, you have a server farm, it'll just be absolutely chugging away, so they can render an hour of footage over 20 computer weeks or whatever. I'm not sure what the ratios are. I'm not too up to date on the film industry specs. But for games, it's got to run. It's got to run at a frame rate that is sufficient for people to actually interact with it.
And that's why when you're working on games, you're really a technical modeler. So a big part of our work is not, I would say, art in the traditional sense of just doing nice things. It's also a lot of work that goes into learning the techniques. And for games especially, you need to know how to do your stuff. And then with the knowledge you have, you can do art. But coming to a point where you're so good that you basically know it in and out and can just do content over and over, that's a hard way, definitely.
You've also got to consider the fact that hard surface modeling, like what we're doing here, is creating machined, industrial things. That's only a single facet of what it can mean to be a game artist. You could be an environment artist, in which case you're making terrain, you're making rocks, you're making that kind of stuff. We do a bit of that on the props team. Or you could be a character artist, studying anatomy, learning about how muscles and faces and stuff work.
TL;DRThey generally don't bake unique assets, using custom normals and small reusable POM detail textures instead, and bake only for special Squadron assets or organic ones that geometry can't do justice.
Yes, that's all our work is. So what Jake's doing now is... basically we use this thing called custom normals or weighted normals where essentially, on your big flat faces, you point the normals straight, and then you'll have a single 45 degree angle edge and the normals will be facing towards the larger surfaces, and it'll fake a curve, essentially. So we don't bake any of our assets, because I've got, I don't know, a thousand props, and if each one had its own texture and you were like, okay, load all the props into this level, it would just go and then it would die. So yeah, we only really bake unique assets when it's either something really special for Squadron or it's an organic asset that you wouldn't be able to throw enough triangles at to do it justice anyway, and it would end up cheaper just streaming in a texture.
We didn't quite talk about POMs before. It's a way we do details. So POM is short for parallax occlusion mapping, and we use it especially for stuff that goes in. You can see these indents here, and what we do is we model a high poly. That's the only case where we use it. So you can see that it really has perspective. It really goes in. And that is because it has a height map. Basically, everything that's low is black and everything that's high is white. Even if you zoom in, it still looks super cool, because it's really giving the perspective we need for screws and so on.
So it's basically putting a sticker on it with the detail, and you can use the stickers as much as you want, basically. And it's kind of like baking a map, but just for the little part where you want the detail to be, right? For screws and indents, it's not worth it to model them. It's really easy for us to just... oh yeah, Jake is offsetting them.
So just to make sure folks are getting this here: the screws and everything, a lot of those indents, they're not actually modeled. It's a sticker that goes on.
And the beautiful thing about having it as a sticker is it's not unique to that single set of pixels. You can place it wherever you want on the weapon. So you can have a bolt that is, I don't know, 64 by 64 pixels of texture memory, and you slap it on 90% of your asset, on 1,000 props. You're streaming in that one set of displacement maps, slapping it on hundreds of props, and you're just streaming that in. The second you stream one prop in, it'll stream in that texture. And then you bring the rest in, and it's like, eh, that's fine, we've already got that texture. So performance-wise, it's real nice.
And in some cases, it can be, I don't know, 200 kilobytes or something, because it's a really small texture that you're using over and over again. It just needs to be these really small pieces. And the traditional way of doing it in a lot of games, which is still done and has been done before, is doing basically this technique, but for the whole weapon, even in places where it technically doesn't make much sense to have it, because on a flat surface we just don't need it, right? We don't need to tell the engine that a flat surface is flat, because it's already flat. If that makes sense.
TL;DRAssets generally get up to five LODs, switching automatically when small triangles reach a certain on-screen pixel size, so it scales regardless of asset size without manually set distances.
The answer is generally up to five. The way our LODs are calculated... so for anyone who doesn't know, LOD stands for level of detail. It's essentially another version of the mesh, the geometry, that is cheaper, has fewer vertices or fewer triangles. We basically take the average size of the small triangles, and we say when that is a certain amount of pixels on screen, switch to the next one. So it doesn't matter if your asset is the size of a space station or the size of a coffee cup. Once those small triangles are a certain amount of pixels on the screen, it will say, OK, use the next LOD. So it's a really lovely scalable system. In a lot of game engines, what you'll have is you dictate the distance at which you transition to an LOD manually, which obviously, when you've got many, many assets, is a bit of a pain. And it's just a really elegant system.
And you can kind of see what's happening here. Usually what I tend to do is, you've seen it before, you basically have the parts of the weapon with the hard edges. And usually I leave those parts with the hard edges. Yeah, it's a really low polygon area. And if you go to a distance of like 20 meters, you can't tell the difference between them. So if you're zooming out, the one without LODs is disappearing on the right, but with the LODs, you can't see a difference.
TL;DROn weapons the first LOD is usually generated automatically and the rest are made by hand; they are exploring Houdini automation, but one speaker is skeptical it will beat human artists soon.
It depends on what the asset is. More organic assets you can get with automation. On weapons, because they're so dense, doing them by hand is quite challenging. So we tend to do, I think, the first LOD automatically, and then after that, we do it manually. Is that right?
Yeah, that's how I tend to do it, because it still has enough detail to usually look really similar to the first one if you do it automatically, but after that the software doesn't know how to do it anymore. And this is the lowest version, where it's just the basic shapes, and it maybe doesn't look too good to you now, but at a distance of, let's say, 25 meters or 50 meters, you can't tell the difference.
Yeah, but you need to realize we don't have unique textures, so we can't make it have the texture on it, and we need to do everything with polygons. And that looks like Nintendo 64 style.
Yeah, I know we are exploring more automated workflows for LODs using Houdini. That's quite exciting. I'm a bit of an automated LOD skeptic. Personally, I think that human beings will be better at it than computers for the foreseeable future. Obviously, it takes a long time, and it can be automated, but the results often are not as good. So in some games, you have more obvious popping when you're moving away from an asset; you might see it deform wildly. We try our best to make our LODs unnoticeable.
TL;DROne speaker has put an abbreviated name in a few serial numbers, but they stay cautious with Easter eggs to avoid breaking immersion, and serial numbers usually have no meaning.
I've put my abbreviated name in a few serial numbers, but that's pretty much the most fun I've had. I'm very pedestrian; some people have snuck slightly more memes and things onto decals and stuff. We don't want people to see something that takes them out of the game, because if you see a decal that's got some meme in it, you know a developer's put that in, right? You've got to be careful that your Easter eggs are not too immersion-breaking, I think. Also, if someone sees them and it's a naughty Easter egg, you might get in trouble.
You also have to be aware not to send folks on random goose chases and stuff, because they think it's a clue in some ARG game and it's actually just the locker combination that you had in high school or something. It doesn't mean anything.
Yeah, so we have an item port system. We place helpers on the weapons. In this case, you can customize it. And you have the points there, the attachment points, where you can actually put a different model. So you can put a laser pointer on it or a flashlight at the front. Not every weapon supports suppressors or muzzle brakes. But in this case it works, because it's a ballistic weapon. But some weapons are just too big, or are not the kind of weapons you would put a silencer on.
Oh, yeah, I like that. It was one of the more complicated weapons. So for us, if it's a static weapon, we just need to model it. It's always straightforward. We know what we're doing. Just get the weapon and do it right. But in this case, a lot of stuff is moving around. It's unfolding. You have moving stuff, rotating stuff; all the little parts at the front, the round stuff, are actually moving or rotating out. So yeah, I would say the more that animates on a weapon, the harder it is for us to do. And the more we need to consider how stuff actually behaves and whether it intersects, like I said earlier.
Mine is actually the shotgun. I'm fairly new to the weapon pipeline. I've made that pistol and that SMG, but the shotgun's the third one I've made, the fourth being the sniper rifle. But this one was the most fun, because I had a bit more control over it, since there were a lot of things that did have to change thanks to things clipping with the animation. So for me, that's why it was more fun.
For the normals on the vertices... So usually what I tend to do is I try to have everything soft and have a chamfer or a bevel on all hard edges. So yeah, that's how I usually work; I don't leave a lot of hard edges. But of course, sometimes you need to do it for certain reasons. And then you can just select all the edges, harden them and leave them in that state.
An edge case for having a hard edge amongst custom normals is when you've got a super thin face. Actually, I can show it with the shotgun here, because this is super thin. I haven't actually beveled the edge on the inside, because it doesn't need to be. It's just a bit where I can save some memory.