I felt like doing this paper, because becoming a video game artist isn't all that easy. And information unfortunately isn't all that widely available. I learned a lot from the materials other people were so kind to provide and being incredibly thankful I see no other way to repay them, but to spread the knowledge. It's a pretty big ride so brace yourselves. Get yourself a cup of coffee or tea and maybe get a brake after the first part, to refresh your ability to perceive.
Information is too much of a valuable resource and it's pretty much the only thing, except confidence, that separates a nooby from a professional. As time went buy I've managed to accumulate some amount of information, which I've never seen being presented in one place and somewhat carefully systematized. It's just stuff that I've picked up all over internet, and that came out of my personal experience crammed together. This paper is aimed at people, who are almost totally unfamiliar with technical aspects of videogame artists work and, will hopefully help them paint a much clearer picture, once they are done reading. Even though this goes out to those, who need knowledge most, I hope, that even some hardcore veterans might find something small but useful in here, or just have a place where they can link somebody, when they encounter some familiar questions.
Video Game Artists work is all about efficiently producing an incredible looking asset. In this article we won't speak about what makes an asset look good, but only about what makes its production efficient.
But before we proceed speaking about efficiency it is crucial to clearly define, what term efficient actually means, related to videogame asset production:
1. Your practice, whether you realize it or not, is all about learning to spend less of your resources to do more work. And speaking about resources spent to have things done, the most significant and valuable one would be time. And not even in your work, but in your whole life. This, without any argument I hope, concludes, that saving asset production time is efficient.
2. On the other hand, video game graphics, being displayed in real time, have to face certain restrictions. With each project each team tries to surpass the others and hopefully themselves, but the amount of memory and the processing power consoles can offer doesn't get no bigger until the next generation hits the shelves. So in the name of making better, prettier games we need to make our assets engine-friendly. In other words, we could say, that saving asset render time is efficient too.
From here this article splits in two parts. The first one will be about things you need to know to produce an efficient asset. The second one will be about things you need to do, to make sure, that the asset you've produced is efficient.
Even though most the of things to follow, are about making your models more engine friendly, please don't forget, that this stuff is just an insight on how things work, that you should use a guideline, to know which side to approach your work from. And all of this shouldn't be time consuming at all. It has to come naturally while you're working.
Saving your or your teammates time is much more important of a guideline. I would say if your optimization would cause an additional hour of work for you or anyone further down the production pipeline, than you probably don't want it. (provided you've been building your assets with following information in mind from the start). Extra hundred of tris won't make fps drop below the floor. If you ain't gonna save another draw call for an object, which is going to be heavily instanced or onscreen all the time, than it's not worth it. Feeling work go smooth would make for a happier team that is able to produce a lot more stuff a lot faster. Don't turn work into struggle for anyone including yourself. Always take concern in needs of people working with stuff you did.
Remember geometry for a second. When we have a dot we, well, we have a dot. A dot is a unit of 1 dimensional space. If we move up to 2 dimensional space, we'd be able to operate with dot's in it too. But if we take two of them, then we'd be able to define a line. A line is a building block of 2 dimensional space. But if you take a closer look, you can see that a line is simply an endless number of dots put alongside each other according to a certain rule or a linear function as you would've said in high school. Now lets move a level up again. In 3 dimensional space we can operate with both dots(or vertices) and lines. But, if we add one more dot to the previous two, that defined a line, we'd be able to define a face. And a face would be a building block in 3 dimensional space, that forms shapes, which we are able to look at from different angles.
I think we are all used to receiving triangle count as a main guideline for creating an asset or a character. And I think the fact of it being a building block of a 3 dimensional space has something to do with it. )
But. That's in human way of thinking. We, humans, also have numbers from 0 to 9, but hardware processors don't. It's just 0 and 1 - binary - the most basic number representation system. In order for a processor to execute anything at all, you have to break it into the smallest and simplest operations that it can solve consecutively. And I am terribly sorry for dragging you through this little technical and geometrical issues, but it was necessary, to make you see that processors work the same way in order to display 3d graphics – from the basics. And even though a triangle is a building block of 3 dimensional space, it is still composed of 3 lines, which in their turn are defined by 3 vertices. So basically, it's the not the tris that you have to save, but vertices. Someone by now would say “Who cares? The less the tri count the less vertices there are!” And he'd be absolutely right. But unfortunately, the number of tris is not the only thing affecting your vert count. There's also some a bit more subtle stuff going on.
A 3d model stored in memory actually presents itself as a number of vertex structure based objects. Structures, speaking object oriented programming language(figuratively), are predefined groups of different types of data and functions composed together to present a single entity. There could be tons of such entities which all share the same variable types and functions, just different values stored in them. Such entities are called objects. That could be a lousy explanation, but there's much more depth to it programming wise. Here's a simplified example of how a structure would look like:
If you think of it, it's really obvious that vertex structure should only contain necessary data. Anything redundant could become a great waste of memory, when your scenes hit a couple of millions vertexes mark.
There are a great deal of attributes that a vertex structure incapacitates but, I'll speak only about artist related ones (since I don't know anything about the others). As far as I know, a vertex structure has enough variables declared for only one set of arguments. What does it mean for us, artists? It means that a vertex can't have 2 sets of uv coordinates, or 2 normals, or two material ID's. Now that's odd, ‘cause we all have seen how smoothing groups(soft\hard edges) work, or applied multiple materials at objects and everything was fine. Or at least it looked fine. How is that possible? Well, it appears, that the most affordable way, to add that extra attribute to a vertex is to simply create another vertex right alongside it!
Speaking a bit more unrelated to technicalities, every time you set another smoothing group for a selection of polys or make a hard edge in maya, invisibly to you, the number of border vertices doubles. The same goes for every UV seam you create. And for every additional material you apply to your model. If you want to create engine friendly pieces you just have to take this into account. The guys at bigger companies sure as hell know this. Epics Unreal Development Kit automatically compares the number of imported and generated vertices on assets import and warns you if the numbers differ for more than 25 percent. Those a pretty tight shoes to fill, but no one said producing efficient art was easy. If Epics programmers consider it an issue serious enough to be checked upon import, I suggest you should think about it.
This small chapter here concerns the stuff that keeps those vertices together – the edges. The way they form triangles is important for an artist, who wants to produce efficient assets. And not only because they define shape, but because they also define how fast your triangles are rendered in a pretty non trivial way.
How would you render a pixel if it's right on the edge that 2 triangles share? You would render the pixel twice, for both triangles and then blend the results. And that leads us to a pretty interesting concept, that the tighter edge density, the more rerendered pixels you'll get and that means bigger render time. This issue should hardly affect the way you model, but knowing about it could come in handy in some other specific cases.
Triangulation would be a perfect example of such a case. It's a pretty known issue, that thin tris aren't all that good to render. And that could be right while talking about modeling. But talking about triangulation, if you're saying you've made a triangle thinner would mean, that with the exactly same action, you've made another one wider. Imagine if we zoom out from a uniformly triangulated model: the smaller the object becomes on screen, the tighter the edge density and the bigger the chance of rerendering same pixels will be.
But, if you neglect uniform triangulation and worry about making every triangle have the largest area possible(thus making it incapacitate more pixels), so in the end you'd get triangles with consecutively decreasing area sizes then once you zoom out again the amount of areas with higher edge density would be limited to a much smaller number of on-screen pixels. And the smaller the object becomes on screen, the smaller amount of potentially redrawn pixels it'll have. You could also try to work this the other way around, and start with making the triangle edges shortest possible. This would make for a more efficient asset and save you some render time on doing multiple passes for the same pixel.
In case you'll find yourself wondering whether to add some neat chamfers, make it all one smoothing group, but inevitably increase small traingle count or just leave it a bit rough, I suggest you go with what makes your model look better first of all. This guideline overrules all the others.
Exactly the way your engine draws your object triangle by triangle, it draws the whole scene object by object. In order for your object to be rendered – a draw call must be sent. Since hardware is created by humans it's pretty much bureaucratical.) You can't just go ahead and render everything you want. First you've got to have some preparation done. CPU(central processing unit) and GPU(graphics processing unit) share the duties somewhat like this: While GPU goes ahead and just renders stuff, CPU gathers information and prepares next batches to be sent to GPU. What's important for us here, is that, if CPU is unable to supply GPU with the next batch by the time it's finished with the current, the GPU has nothing to do. From this we can conclude that rendering an object with a small amount of tris isn't all that efficient. You'll spend more time preparing for the render, then on the render itself and waste the precious milliseconds your graphics card could be crunching some sweet stuff.
A frame from NVidias 2005(?) GDC presentation
The number of tris GPU can render until the next batch is ready to be submitted significantly varies, but here are some examples. I've seen it somewhere in the UDN that for Unreal Engine 3 numbers are in between a 1000 and 2000 triangles. While working with BigWorld engine we've set the barrier at 800 even though some of the programmers said that it could be around a 1000.
Defining such a number for your project would be an incredible help for your art team. It would save a real ton of both production and render time. Plus it'll serve as a perfect guideline for artists to solve some tricky situations completely on their own.
You'd want to have a less detailed model, only when there's really no point in making it more complex, and you'd have to spent some extra time on things no one would ever notice. And that luckily works the other way around – you wouldn't want to make your model lowpolier than this, unless you have your specific reasons. Plus the reserve of tris you have could really be well spent on shaving of those invisible vertices mentioned earlier. Add some chamfered edges and fearlessly assign one smoothing group to the whole object(make all the edges soft). It may sound weird but by having a smother more tessellated models you could actually help the performance.
If you'd like your game to be more efficient try to avoid making very low polygonal objects a single independent asset. If you are making a tavern scene, you really don't want to have every fork, knife and dishes hand placed in the game editor. You'd rather combine them into sets or even combine them with a table. Yeah, you would have less variety, but believe me, when done right, no one would even notice.
But this in no case means that you should run around applying turbosmooth to everything. There are some things to watch out for. Like stencil shadows, instancing and even vertex lighting, to name a few. Plus some engines combine multiple objects in a single drawcall, so watch out. But I'll speak about that in the very ending of “Things You Need To Know” part of this paper.
If I'd ask you, as an artist, what is the main difference between art production for last and current generation of consoles, what would you say?
I'm pretty damn sure, that the most common answer would be introduction of per texel shading and use of multiple textures, to simulate different physical qualities of a single surface, becoming standard de facto. Yeah sure polycounts have grown, animation rigs now have more bones and procedurally generated physical movement is everywhere. But normal and spec maps are the ones contributing the most visual difference. And this difference comes at a price. Nowadays I hear terms “fill rate driven engine”, “fill rate bound engine” and “fill rate oriented engine” thrown around more and more. All those terms didn't come out of nowhere and the reason behind there appearance is, that, in modern day engines, most of objects render time is spent processing and applying all those maps based on incoming lights and cameras position.
Complex/Simple Shaders in UDK
From a viewpoint of an artist, who strives to produce effective art this means following things: Optimizing your materials is much more fruitful, than optimizing vertex counts. Adding an extra 10, 20 or even 500 tris ain't as nearly as stressing for performance as applying another material on an object. Shaving hundreds of tris off your model would hardly ever bring a bigger bang, than deciding that your object could do without an opacity map, or glow map, or bump offset or even a secular map. Kevin Johnstone of Epic Entertainment once said, that while working on Unreal Tournament 3 he optimized a single level by 2-3 million triangles just to gain somewhat around 2-3 fps. I think this example makes it obvious. It's not the tri count, that affects performance the most. I'd say it's the number of draw calls and shader and lighting complexity that counts. Then there are vertex transformation costs when you have some really complex rigs or a lot of physically controlled objects. And post processing.
Surely, as an artist you have a lot more control over your materials, rather than the lighting, but there are still some things you can do, depending on your engine.
If you know you're going to have dynamic lighting in the scene, then you don't want to have huge object only a small part of which will be lit dynamically at a single moment of time. Break it into smaller pieces. Or for example if you are doing a haunted hotel scene, where the player will have to navigate dark hallways, lighting his way with a flashlight, you'd rather have every chandelier on the wall a separate object. Even if its like 30-50 tris. It's may seem logical, in order to optimize things, to go ahead and attach all the chandeliers into a single object, since they are pretty low poly and share the same material, but, all the profit that comes of it, wouldn't compare with the stress ‘caused to process dynamic lighting every frame for an object so widely dispersed across the level.
Even though I am speaking off my Unreal Engine 3 experience, I believe those guys know what they are doing, and their knowledge could be taken into account. If your engine gives you a choice between vertex lighting and lightmapping you'd want to go with the second. First of all, because in case of vertex lighting you need to store in memory the data for every single vertex you have, and that kinda makes you wish you had less vertices, but, since we've figured out that we have them for free until the next batch is ready, we'd rather use them for good.
You could use a 128 or 64 or even a 32 by 32 light map in some cases that would still look smoother then vertex lighting but eat up a lot less memory.
Plus, since a lightmap is pretty much a usual bitmap you can weave it into your texture streaming pipeline and not affect the overall texture memory budget. And I can hardly think of a way to make vertex lighting almost free memory wise, so lightmaps for the win. If you want to make your asset a bit more engine friendly and your engine supports lightmapping, then I suggest you don't hesitate to make a second uv set, for the lightmaps.
After all the things said, there's still one most important thing that you need to know. And that is that things differ. Sometimes dramatically. As with everything in life, there's no universal recipe and the best thing you can do is figure out what does your specific case look like. Get all the information you can from the people responsible. No one knows your engine better than the programmers. They know a lot of stuff that could be useful for artists, but sometimes, due to lack of dialogue, this information remains with them. Miscommunication may lead to problems that could've been easily avoided, or be the reason you've done a shit ton of unnecessary work or wasted a truckload of time that could've been spent much wiser. Speak, you're all making one game after all and your success depends on how well you're able to cooperate. Communication with programmers could actually be the work of your lead or a tech artist, so you could just ask them instead. Asking has never hurt anyone and it's actually the best way to get an answer.
Dalai Lama once said:
“Learn your rules diligently, so you would now where to break them.”
And I can do nothing, but agree with him. Obeying rules all the time is the best way to not ever do anything original. All rules or restrictions have some solid arguments to back them up, and fit some general conditions. But conditions vary. If you take a closer look, every other asset could be an exception to some extent. And, ideally, having faced some tricky situation artists should be able to make decisions on their own, sometimes even break the rules if they know that the project will benefit from it, and them braking the rules wouldn't hurt anything. But, If you don't know the facts behind the rules I doubt you would ever go breaking them. So I seriously encourage you take interest in your work. There's more to video games production than art.
If you're doing freelance work and you feel like your model would really benefit from that extra tris, than I'd say you ask. For it is in the best interest of the people you're working for. Plus, if for some reason, they are unaware of all the stuff listed above then there's a big chance, that you've helped them a lot – and that's some respect points for you.)
So I hope this wall of text up here made some sense for you guys.) I find all this information on how stuff works really useful, but it's not exactly what you would use on a day by day basis. It's nice to read once, but I doubt I myself would want to go through this again in case I forget something. And though I think “whys” are important, as an artist(or as an artist wanna be), I'd love to have a place where all the “hows” are clearly stacked, without any other distracting information. And the “whys” section would serve as a reference you can turn to, in case something becomes unclear.
Now lets imagine you're finally done with an asset. You'd want to make sure things are clean and engine friendly. Here's the list of things to check upon consecutively:
- Deleted History, Frozen Transformations/Reset XForm, Collapsed Stack
Transformation information stored in a model could prevent it from being displayed correctly, making all further check useless. Plus it's simply unacceptable for import into some engines. And even if it does import, objects orientation and normal direction could be messed up.
In Maya, don't forget to select your object.
- Inverted Normals
While mirroring(scaling by a negative number) or performing a ton of other operations actually, your vertex normals could get turned inside out. You should have the right settings set in your modeling application in order to spot such problems. In 3ds Max you can go to object properties and turn “Backface cull” on. Then examine your mesh.
In Maya you could just disable “Double Sided lighting” in the lighting tab(if it's missing hit “shift+m”), then make sure, that in the Shading tab “Backface Culling” is disabled. Then If you'll check out your model with shading all the places with inverted normals will be black.
- Mesh splits/ Open Edges
It sometimes happens, that while working we forget to weld some vertices or accidentally break/split some. Not only this could cause some lighting and smoothing issues, but it's also a waste of memory and pretty much a sign of a sloppy work. You wouldn't want that.
Open edges are an issue you want to think twice about. And not only because in some cases they could be an additional stress for computing dynamic lighting, but because it seriously reduces reusability of your asset. If you simply close the gap and find a place on your texture you can throw this new shell on, that would still be more preferable.
To detect both those issues in 3ds Max simply choose border selection mode (“3” by default) and hit select all (“ctrl + a” by default).
In Maya you could use a handy tool called “Custom Polygon Display”. Choose “Highlight: Borders” radio button and apply to your object.
- Multiple edges/ Double faces
This double stuff is a nasty bugger since it's almost impossible to spot unless you know how. And sometimes when you modify stuff you can get very surprised with things behaving not the way they should.
I could hardly remember having them in max, but just to be sure I always apply a STL Check modifier. Tick the appropriate radio button and check the “Check” checkbox.)
In Maya “Cleanup” tool is very useful. Just check “Nonmanifold geometry” and “Lamina faces” and hit apply.
- Smoothing groups/soft-hard edges
For this one you'd want to have as less smoothing groups/hard edges as possible. You might consider making it all smooth and just adding some extra chamfers, where bad lighting issues start to appear.
Plus there's one more issue to watch out for, more in Maya then in 3ds Max though, since max utilizes the Smoothing Group concept: Edges on planar surfaces would appear smooth even if they are not. To see which edges are actually unsmoothed “Custom Polygon Display” tool comes in handy again. Just click “Soft/Hard” round button right alongside the “Edges:”
- UV splits
You would like your UVs to have the least number of seams possible, but, as long as it is nice to work with. No need to go over the top with distortion here, just keep it clean and logical.
Broken/split vertices are a thing to watch out for too. 3ds Max would indicate them with different color inside the “Edit UVWs” window.
While in Mayas “UV Texture Editor” window you have Highlight Edges button, that simply checks “Highlight: Texture Borders” checkbox in the “Custom Polygon Display” tool for you.
While checking triangulation up, first of all make sure, that all the triangles accentuate the shape you're trying to convey, rather than contradict it. Then a quick glance, to check if triangulation is efficient.
Plus. Some engines have their own triangulation algorithms, and will triangulate a model on import themselves, with no concern about how you thought your triangulation looked. In trickier places this could lead to a messy result, so please take caution and investigate how your engine works and connect the vertices by hand If necessary. Btw, Maya more or less helps you find such places if you check “Concave faces” in “Cleanup Options”. In 3ds Max you'll just have to keep an eye out for yourself.
- Grid Alignment/ Modularity/Pivot point placement
Since the last generation of videogames, graphics production costs has increased significantly, so modularity and extensive reusability are now a very common thing. Ease of implementation and combination with different assets could save a lot of time, maybe not even yours, so don't make your level designers hate you – think about it.
- Material Optimization
Evaluate your textures and materials again, since it's probably the biggest source of optimization. Maybe the gloss map doesn't deliver at all and specular is doing great on its own? Maybe if you used a twice smaller specular the asset would still hold up? Or maybe you can go with the diffuse for specular, since it's a just a small background asset? Maybe that additional tileable normal isn't necessary at all? Or maybe you could go with a grayscale spec, and use the spare channels for something else?
- Lightmapping possibility
If your engine supports lightmapping make sure you have a spare set of uniquely unwrapped UVs, which totally met all your engines requirements.
Everything said, there's still one more thing left.
no matter how technical and optimized your model is, it's meant to look beautiful first of all. No optimization could be an excuse for an ugly model. Optimization is not what artists do. Artists do art. And that's what you should concentrate on. The beauty of technicalities is that they can be precise to a pretty big extent. Which means you can write them down, memorize them and don't bother thinking about them again for quite a while, just remembering instead. But it's art where you have to evaluate and make millions of decisions every single second. All this text is not important and that is exactly why it is written down. Really important things aren't all that easy to be expressed with words. And I hoped, that maybe, if you didn't have to bother thinking about all the tech crap at least for some time, you'd concentrate on stuff much more important, and prettier I hope.
P.S. Some helpfull links on the subject:
Beautiful, Yet Friendly Part 1: Stop Hitting the Bottleneck by Guillaume Provost
Beautiful, Yet Friendly Part 2: Maximizing Efficiency by Guillaume Provost
Unreal Developer Network
Triangulation info by Humus
Too much optimisation thread at polycount