Video Game Artists Hygiene. Theory and practice.
polycounter lvl 14
Extremly laconic exposition of the following text, which I figured Might be usefull to have in one place:
If you're interested in more details, I suggest you just take it from the top. And ready yourself to spend sometime reading.
top
Hey.
I felt like doing this paper, because.
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.
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 (especially from you guys), 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. I also tried to be pretty thorough, because I want to translate this paper into russian for all those artist, who can’t get useful knowledge due to not knowing english. I won’t be able to link them to all the great articles and forum threads, which means it had to be pretty much all in one place. So please pardon me if this won’t become a discovery for you. 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.
Aaand. I have one last thing to ask of you. Providing people with knowledge is a very responsible task. I don’t pretend to know everything and, least of all I want to provide somebody with false information. This paper here is just how I came to see things. But things vary so much and change so fast, that I am worried. So if you encounter in this text something you feel doubtful about and can clearly explain why, please don’t hesitate to point this out. I didn’t write this for the sake of writing it, but for the sake of people using it, so feedback would be really appreciated. And now on to the paper:
Video Game Artists work is all about efficiently producing an incredible looking asset. In this article I won’t speak about what makes an asset look good, but only about what makes it’s 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, and I suggest you don’t forget that. 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. Let’s get rolling, people=)
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.
There’s sure an endless amount of stuff you could do to save your or colleagues time, so I wont even try to cover them all, but still I’d like to throw some in as an example (which I may expand upon until it becomes worthy of some personal space):
- Check everything Twice when you’re done.
- Use your UV for selection while making LoD models, if your model has a lot of repetitive parts.
- Your texture artists would thank you if you’d make that UV seams someplace hard to spot. Plus please take some time and try to straighten your lines and keep them mostly perpendicular or parallel, to “utilize the square nature of the pixels” better.
This incredibly adds to workability, while distortion usually goes completely unnoticed. And don’t forget some padding, especially if your piece will be seen from a distance a lot.
- Level designers would think you’re the best guy to work with if you’ll keep to the grid (if you game uses one) and always place the pivot point in the most comfortable place, which you can ask them about.
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 any thing 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.
And I’m sorry we have to do this again, but here comes programmers stuff. Keep it together, people=)
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:
Vertex structure
{
Vertex Coordinates;
Vertex Color;
Vertex Normals;
UV Coordinates;
};
Very simplified.
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 percents. 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.
[size=+1]
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 wheter 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 guidline overrules all the others.
[size=+1]
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 bureaucrtical.) 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.
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.
[size=+1]
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.
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 millions 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 then 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.
[size=+1]
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 then 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.)
You can grab the other about "things you'd want to do" right here.
Things to keep in mind:
It’s not the tri count that matters, but vertex count. Smoothing Groups(Soft/Hard Edges), UV seams and Multiple Materials increase the number of verts, so you want to have the least number of those possible. Vert counts hardly matter, if they don’t add another drawcall, so feel free to find them a proper use. Uberlowpoly models are bad for performance.
Triangulate using “Max Area” or “Shortest Edge” principles.
Materials(Shaders) are the most fruitful thing to optimize.
If you know you’re going to have dynamic lighting, then break bigger objects into smaller ones.
Lightmap static meshes and make them lightmapping ready if your engine supports it.
Workability and Beauty is still king.
Make shure you've aquired all the specific knowledge you need out of the one responsible.
Things to check upon:
- Deleted History, Frozen Transformations/Reset XForm, Collapsed Stack
- Inverted Normals
- Mesh splits/ Open Edges
- Multiple edges/ Double faces
- Smoothing groups/soft-hard edges
- UV splits
- Triangulation
- Grid Alignment/ Modularity/Pivot point placement
- Material Optimization
- Lightmapping possibility
If you're interested in more details, I suggest you just take it from the top. And ready yourself to spend sometime reading.
top
Hey.
I felt like doing this paper, because.
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.
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 (especially from you guys), 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. I also tried to be pretty thorough, because I want to translate this paper into russian for all those artist, who can’t get useful knowledge due to not knowing english. I won’t be able to link them to all the great articles and forum threads, which means it had to be pretty much all in one place. So please pardon me if this won’t become a discovery for you. 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.
Aaand. I have one last thing to ask of you. Providing people with knowledge is a very responsible task. I don’t pretend to know everything and, least of all I want to provide somebody with false information. This paper here is just how I came to see things. But things vary so much and change so fast, that I am worried. So if you encounter in this text something you feel doubtful about and can clearly explain why, please don’t hesitate to point this out. I didn’t write this for the sake of writing it, but for the sake of people using it, so feedback would be really appreciated. And now on to the paper:
[size=+2]Video Game Artists Hygiene. Theory and practice.[/size]
Video Game Artists work is all about efficiently producing an incredible looking asset. In this article I won’t speak about what makes an asset look good, but only about what makes it’s 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, and I suggest you don’t forget that. 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. Let’s get rolling, people=)
[size=+2]Things you'd want to know[/size]
[size=+1]
[size=+1]
Brain Cells Do Not Recover
[/size]
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.
There’s sure an endless amount of stuff you could do to save your or colleagues time, so I wont even try to cover them all, but still I’d like to throw some in as an example (which I may expand upon until it becomes worthy of some personal space):
- Check everything Twice when you’re done.
- Use your UV for selection while making LoD models, if your model has a lot of repetitive parts.
- Your texture artists would thank you if you’d make that UV seams someplace hard to spot. Plus please take some time and try to straighten your lines and keep them mostly perpendicular or parallel, to “utilize the square nature of the pixels” better.
This incredibly adds to workability, while distortion usually goes completely unnoticed. And don’t forget some padding, especially if your piece will be seen from a distance a lot.
- Level designers would think you’re the best guy to work with if you’ll keep to the grid (if you game uses one) and always place the pivot point in the most comfortable place, which you can ask them about.
[size=+1]In the beginning there was Vertex.[/size]
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 any thing 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.
And I’m sorry we have to do this again, but here comes programmers stuff. Keep it together, people=)
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:
Vertex structure
{
Vertex Coordinates;
Vertex Color;
Vertex Normals;
UV Coordinates;
};
Very simplified.
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 percents. 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.
[size=+1]
Connecting the dots
[/size]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 wheter 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 guidline overrules all the others.
[size=+1]
Eating in portions, makes for a fuller stomach.
[/size]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 bureaucrtical.) 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.
[size=+1]
Vertex VS Pixel[/size]
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 millions 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 then 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.
[size=+1]
The most important thing[/size]
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 then 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.)
You can grab the other about "things you'd want to do" right here.
Replies
Some really good info, very nice write up. Look forward to reading some more!
break it up a little with some pix maybe.. please?
I'll read it and get back to you, but I'm looking forward to reading it and I'm hoping that it's something that you'll continue to expand upon and add to - maybe with some pretty pictures.
So, for now, thank you for taking the time and effort to write this for everyone.
Same applies to huge wall of texts
absolutely this. and i still thought so after reading through the introduction.
now that i've finished i can honestly say that it has nothing to do with personal hygiene, but it's still a interesting read.
Not. Enough. Pictures.
Sorry, you obviously put a lot of effort into this post, but I'm way too ADD to read a forum post formatted like this
[edit] okay more seriously. There is some good info but some of it I find confusing, like that chapter on edges. The fact is, one can be very strict about edge placement in theory ; but what really matters is where the seams fall on the model, how they play for texturing, and so on.
Because at the end of the day, anal asset optimization matters *less* than asset workability. Chances are, redirecting edges will not affect framerate much (Kevin's example tells that) but carefully crafting the asset certainly will save hours when it's time to texture it, especially if the task is given to another artist than the original creator. You really don't want to paint straight lines at an odd angle, that sort of things.
So the old rule, "model for UVs" still remains. Also, "Concept for model". it was true for older game art and is still is.
Unfortunately it is widely ignored by concept artists and modelers ... even more so in our next-gen age.
I find that many game artists get caught in the technicalities instead of focusing on the art... Making cool stuff and posting it here will most likely build alot of knowledge and experience. But maybe I am biased because that's how I learned. Textbooks are fine but experience is the key. I think!
Also this should be in the introduction of your paper in my opinion :
http://itchstudios.com/psg/art_tut.htm
Artists should understand this first, then move to technicalities. Then again just my opinion.
thought it was some long metaphor about stinky co workers Lol
I, like many others, clicked because I thought I was going to enter a funny thread about stinky people who need to shower. Instead I was greeted with a wall of text. Highly misleading.
I don't even feel like reading because to much random people on the internet think they have something important to say, the thing though is that I can judge better with pictures instead of text that takes ages to read (ages = more than 2 min).
fart on viks chair
For example you linked Guillaume Provost's "beautiful yet friendly" articles - note that they actually tell an artist the exact same info that you spent about 4 paragraphs on, except he's done it using valid picture examples that any game artist should understand, and using concise and clear wording.
I think in general this applies to the whole article - you could say the same things with less words and more clarity, and therefore make the article more efficient (and more likely to be fully read and digested). I think at the moment most game artists would run scared from blocks of text like that (sad but true
I'm fairly sure that this is wrong, I've been playing Crysis recently and I noticed that their grass is all alpha-tested (like the foliage) because it doesn't get anti-aliased properly, presumably because of how their renderer works. Screenshot here (although not the best example, it's pretty clear that the grass in the bottom left is alpha-tested).
Totally agree, Pior. That's the sort of thing that it's hard to boil down into text and simple examples - when you're working on a complex asset, a good and efficient (and by extension probably very experienced) game artist will instinctively know while they're modelling, how the UVs are going to work.
They will add edges here and there where a casual observer might say "why are you doing that?" and in the end it turns out it was so that you can mirror a whole UV chunk cleverly, or re-use another piece of texture there.
Same with the concept thing - a good concept artist will know how a modeller can build a piece, so they will design it with that in mind - rather than going crazy and then having to spend ages on the asset at the model stage trying to figure out how it is all built and fits together.
In summary: There's more at work here than simply optimising vertex count and fill rate. You also need to work smart and build your assets in a clever way to make the best use of you and your colleagues' time.
It was a good read, learnt a few things and helped understanding others.
as Mop said, this is wrong. Also small triangles (grass blades) would be really bad for performance (shading works on group of pixels, thin triangles are not good for this). You don't draw grass billboards alone, but plenty of them, and in case of many games it's not even simple grass blades anymore, but a few triangles arranged in 3D as grass instance mesh. That way your drawcall at the end will have thousands of tris again, rendering plenty instance meshes.
Be really careful with stuff like this. False knowledge is worse than ignorance. Even if you say you "might not know" but still explain "possible" things in detail, people will not remember it was actually speculation.
anyway, as mentioned too much inefficiency in the presentation. You try to make it sound like a "story" when you should go for a compressed presentation, bullet points, images, snappy pregnant statements. I do agree so that the optimisation and other threads could need a "compression" some day hehe... then again self-education is part of everyone's market value
That's what I thought too, lol. Then I saw a wall of text, and was like
while I enjoy a good read every now and then for the sake of feeding my mind... I do need to feed my eyes as well.
danshewan, thanks, I hope you found it good. or at least not bad)
Hey,pior, thanks a lot. Your comment has been really usefull. I hope you don't mind, that being reminded by you about the whole "workability" thing, I've added a chapter about it. Thanks again.
About being to carried away be technicalities I absoltely agree with you. And I hope the afterword is capable of delivering that message.
Btw, the link you suggested is great. I've read it couple of times before, but unfortunately that was not exactly my subject=(
Frump, it's called that way, 'cause I see that stuff as nescessery to keep things "clean". Not exactly the vivd kind of logic but still...
On the other hand, if it had some boring tech talk name people would ignore it, so it's a plus?=) So next time I create a topic I I'll try calling it "cute kittens" or "megan fox blows some dude" and wait for the results.)
But still you make sense about headlines, so I'll try to figure something out. Thanks a lot. Really.
Thanks for thanking me,MoP. And thanks for pointing out that stuff about crysis. It was totally my bad relying on the things I've heared and not even bothering to check. So beg your pardon and thanks.
And yeah I totally agree about workability with you too.
Thanks everyone for your feedback.I'm sorry I've put this up in parts, but I still feel that it was a good thing to do, since I've been able to gather some feedback before I decided it was was finished so it was psycologigaly easier for me to get back to stuff and correct some.
So the second part is now up. I hope you enjoy. I'm pretty tired of writing and my hands are itching to get down to som real work, so I'll probably won't give much more refinment until sometime, maybe when there'll enough crits or something. And I still have to translate it to russian=(
I'm sorry most of you guys considered it had too much text. But on the other hand I'm really glad for you, that you have such an opportunity.)
and thanks for all the comments and crits.) c ya
With weight transfer tools, it's actually the opposite. You could very well pass an early, non finished version of a model (but with correct proportions) to the rigger so that you can see if it has the correct range of deformation. Then adjust your model accordingly. Another non linear approach to game art.
As a matter of fact I find that, when stuff are made in a very linear manner, things tend to get locked down way to early (like, a rig) and passed to the net person without proper evaluations. Lets say you finish a model, pass it to the rigger who rigs it very quickly and efficiently, then he passes it to the animators. A week later you review the anims but realize some bone placement were not the way you imagined them to be on your model. Well the rig would have to be redone, and anims aswell. If this had been checked much earlier on a crude version of the mesh this wouldnt happen.
Less text more rocks!
You know you COULD make a video instead of typing, and it would probebly be much easier to translate too!
BTW this is an interesting read, I learnt some new stuff, so thanks.
I was too used to seeing our animater running arond the studio and all like "where is this m*therf*cker!? I wanna show him what he did and then probably brak his leg.".)
I guess i'll correct it right away.
EsotericAgenda, Cyrael, I'm so very glad you found it useful. Makes me happy.)
BULLSHIT.
Small triangles are bad. If anyone uses PIX - turn on overdraw and check something out that has very small triangles - and there will be overdraw all over the edges of the small triangles. Especially when triangles get to 1-to-1 with pixels. Do not do that! I'm not sure the ideal triangle/pixel ratio, but bigger tris are better on fill & ROPs.
LODs are essential - yes, there is a memory cost, but that is small. Yes, there is CPU cost to check the distance to make it switch, but that is small also. There is no GPU cost to switching models though, except the savings you get from better sized tris on screen.
Some exceptions of course, like grass, particles, etc, but for standard geo, build LODs. Use as many verts as needed.
There are no hard and fast rules - guidelines only. A lot of the doc is helpful, some useful info in there. But beware spreading incorrect info. Test stuff yourself - ask programmers to debug & profile it.
And as many people have said - workflow is more important than anything. I'd rather have twice as many slightly inefficient objects in the game than half as many perfect ones!
I'll correct it right away.
I am afraid to spread false knowledge. And least of all I want to do this. I've had the paragraph about it in the first post.
Sorry but I unfortunately have no one to turn to debug and profile it(except fellow polycounters), so thanks again. And I'm glad you found some of the info useful.
Good luck.
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.
So, while making and asset or a character you’d want to keep these things in mind all the time:
It’s not the tri count that matters, but vertex count. Smoothing Groups(Soft/Hard Edges), UV seams and Multiple Materials increase the number of verts, so you want to have the least number of those possible. Vert counts don’t matter at all, if they don’t add another drawcall, so feel free to find them a proper use. Uberlowpoly models are bad for performance.
Triangulate using “Max Area” or “Shortest Edge” principles.
Materials(Shaders) are the most fruitful thing to optimize.
If you know you’re going to have dynamic lighting, then try to break bigger objects into smaller ones.
Lightmapping is more efficient then vertex lighting, so try to lightmap static meshes and make them lightmapping ready if your engine supports it.
Workability is still king.
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 its 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.
- Triangulation
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.
Afterword
Everything said, there’s still one more thing left.
Please remember,
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.
Cheers.
Very helpfull links which I owe most of my information to(I suupose most you know them though)
Beautiful, Yet Friendly Part 1: Stop Hitting the Bottleneck
Beautiful, Yet Friendly Part 2: Maximizing Efficiency - a series of deep and easily understandable articles by Guillaume Provost
Unreal Developer Network - contains a ton of usefull information.
Hummus on the triangulation - some amazing tests.
Too much optimisation thread at polycount thats where I first encountered most of the termes I've been talking about...
I've added some minor tweaks to the rext too. Hope it's a bit more readable now.
If there's anything in the text still bothering you please speak up.
Cheers,)