Sorry your browser is not supported!

Hello all,

I am making my first fully animated game character (or trying to, anyway). I just wanted to know, what is the reccomended polygon count for a humanoid character (which will be the player). I realize to high a poly count can slow down things, but again, a low poly count will make a character seem too square. Any advice on this? Thanks.

I think most people say about 3000-4000 for the main character.

good question but that would depend on what type of game you our making. If it's the player then 3000 to 5000 would be best but sometimes you can go higher. such as in fighting game doa style their around 6000. and gears of war where around 6000 so it depends on what your making. the master chief was only 2,900 and something.

I find that 1000 for the head and 2000 for the body works well, and a similar number of vertices as surfaces.

Ok here is the break down.

If you are making a first person game like a shooter or something like that. In this case you don't need but maybe a 100 poly's for the arm or gun or whatever. This is why most FPS games like Halo run so fast and can look so vibrant.

Now say you are doing a third person game. The main character should be no more that 6000 poly's because you have to have room for everyone else. The main bad guys should be about the same count as the main character because you tend to focus on them more. The less least important characters such as all the little monsters that you kill should be no more than 1,000 poly's.

Basically you take a number that you want to use for the whole game. Say 1,000,000 poly's for the whole game. You have 9 levels so each level has 100,000 poly's for each level, this is a vary detailed level on a very fast system hehe. Now you have 100,000 poly's to work with for characters. Say you have 9 bosses, each 6,000 polys, that's 54,000 polys, then you have your little monsters, which can be say 1000 poly's and say you have 40 different types. That 46 different monsters comes out to 40,000 poly's.

So your Polygon Budget would be:

Levels 900,000 P
Character 6,000 P
Bosses 54,000 P
Monsters 40,000 P
----------------------------
Grand Total 1,000,000 P


I hope this helps out. I generally pick a count and start dividing up from there. Now this is just for a very good game, extremely detailed and all. As for DBP I would keep it down to a good 250,000 Polygons to be safe. I haven't tested the limits and all of DBP but I am sure it would do just fine with almost anything you need.

The number of polygons one should use on a given character or object depends primarily on the strength of the platform on which it is to be played. Since Personal Computers span such a wide range of dynamic capabilities, it is difficult to say what would be best.

I generally just try to use as few possible as I can to present the image of what I am trying to portray. In the case of my Otter Character in the Redwall RPG, I used roughly 3000-3500 polys to enable him to express a low level of facial animation. In my Mouse Guard Project the heroes only consist of 314 polys, whereas in The Elder Scrolls 4: Oblivion, the "people" consist roughly of 10,000 polygons and support relatively detailed facial manipulation capable of decent lip syncing, and vast customization for your own characters.

I generally try to use as few polys as possible, while still maintaining a level of detail that remains similar to the concept art and allows the player to be animated using bones with as few "flattening joints" as possible.

I'd suggest picking a video game that you want to imitate the art style of, and then trying to build models with a similar style and polygon count.

Without the specifications of your system, and a description of your game (particularly the number of active characters at any given time) I can't really give you an estimate other than if you want any decent facial expression, you shouldn't hesitate to use more polygons in that area.

At present I'm using a 2.4ghz P4 with a Gig of RAM and an ATI Radeon X1550 (256mb). My Characters are about 3000-4000 polys in my current project (which you can view under the NEW REDWALL GAME thread on the game design theory forum if you wish) and I have set the limit for total characters in any given scene to 20 because my computer starts having serious trouble a bit farther than that. I'm using roughly 50 bones to animate each of them, and they are fully functional down to manipulation of the index finger and thumb, as well as the eyebrows and several bones set to the task of making him speak.

The number of polys and bones really depends on the level of detail and the power of the system it will be played on. In my case, I'm building it to run on a computer better than the one I currently have, because by the time I finish it, technology will have progressed and better computers will likely be a standard (if they aren't already, lol).

Hope my ramblings help a bit.

That's not really a good way, because you won't ever have those 9 levels on screen at the same time, or the 46 monsters at the same time. You only need to worry about the poly count of what's on screen at the same time.

The rule of thumb is '3D detail only where necessary' otherwise convey your detail in textures, in that sense so long as your game world and characters look impressive in their level of detail, then you needn't worry about going over the polycount.

A good idea is to think about the easy minimum you can 'get away with' without making your game look sub-standard (say around 100,000-150,000), in this way, once your game is up-and-running at a good frame rate you can than push the boundaries by increasing the polycount by about 50% (200,000) adding in better models, more action on screen and better visual FX... Usually leading to more immersive gameplay. Doing this process in the reverse order , that is to say, making a beautiful - but slow - game will give you no leeway whatsoever and all that'll happen is you'll dilute your gameplay. A good example of this is PGR2 on the Xbox360 which is forced to run at an appauling 30fps.

idissectionxk5.jpg

For an example on how high poly 3D can be avoided and still produce absolutely future-proof graphics, look at high-end PS2 games like Soul Calibur III (Highly recommend you rent this, if just to dissect how Namco have used intuitive efficient graphical techniques) Tomb Raider Legend and Valkyrie Profile : Silmeria.

Further to a point made by someone else on the forum about developing for more powerful systems than your own, you do not really want a Crysis situation. This would be a situation where as a developer you limit your audience to those who have the best of the best graphics cards at the point in time. Doing this makes your game appeal to an audience but the audience is miniscule which can be frustrating considering the time and effort you put in and you as a developer will need to constantly test your game, so this is not a practical option.

A crucial aspect of graphics is the consistency, balance everything, don't allow your environments to suffer by having an astounding-looking character, or vice-versa.

Note: Leeway is actually 16% not 6%.

Other things to ask yourself:

Q. How big does the environment need to be? Can I portray this part if the game with a smaller environment?

A. Make it suitable to the point in the story and relative to the level of detail you want in the game, smaller environments mean a more concentrated area to fill with great graphics [more polys to play with]. A larger area means less frequent loading and more seamless gameplay, but may suffer from 'blandness'.

Q. If I do need an expansive world, what interesting landmarks should there be without exceeding the polycount?

A. Try something relatively unique, we've seen waterfalls and trees thousands of times already. Push the imagination, for example if your making a FPS game and your at a factory; ask yourself, what is the factory mining? Who owns the factory? What's the history behind the factory? What would be the most exciting way to play through the factory? Is the factory functional? Would it be better if it was on fire/delapodated/a secret hideout/about to collapse.

I think that 6000 polygons for a character is too much. Additional detail can be accomplished with normal mapping. My limit is 2.5k polygons, which looks quite good if done correctly. I try to keep the characters down around 1200-1500 and monsters at 1000. Good textures and normal maps can't be beat.

Something to consider - model file size is very important. If you have a 1000 polygon model but the file is 6 mb in size your game will perform poorly. Take a 2.5k polygon model that is 1 mb and it will run circles around the 6 mb model. This is evidenced in Dark Matter 2, where the models are inflated in frames and size by a factor of 160. If you re-rig them with 500 frames of animation then they shrink down to around 250k and are amazing as NPCs.

Good animation is very important. People tend to add too many frames. A typical animation should be around 20 frames, not 100. DirectX will interpolate between frames. Increasing the number of frames directly impacts the size of the model. I just re-rigged the FPSC thug model with my own skeleton. It has tons of bones and 2400-ish frames of animation, all of which are FPS focused. I changed it to 500 frames of quality RPG animation and fewer bones and he shrunk to 250k. I love it Now I can have tons of NPCs on screen and still have a playable game.

Moral of the story - polygon counts are important, but not the only factor to consider. You need to take into account file size, number of textures (nothing beats 1 good UV mapped texture), texture tiling (the more you tile a texture the slower it will run), and number of limbs (each limb gets a draw call of its own)

Someday I'll get around to actually making a proper thread on this subject given it returns like a half-brick to the skull every couple of weeks now.

A couple of things said in this thread are sorta right, most can very easily be ignored due to just well plain ignorance on the subject from those dishing out the information.

I'll very quickly cover the subject on the whole though, which could easily take up several posts at maximum size.

Q: How many polygons can I have in my game?
A: How long is a peice of string? Seriously that is basically what you're asking with that.

The number of polygons your game will be able to handle is entirely dependant upon, the minimum system you wish to run it on; and how well that system handles your code.

A good example would be the system I'm currently writing this on is:
Athlon64 X2 3800+, 768MB RAM, GeForce 6100 256MB RAM

Now theoretically, this setup should be able to handle roughly 1.2million polygons (triangles) per scene at 60fps textured and lit (by a single light source)

Realistically in DarkBASIC Professional with nothing else running, I've found it's far more likely to handle closer to 600,000 polygons (triangle) per scene.

This might seem like a lot, but when you start breaking that up in to more objects (not just one), animation, adding shaders, etc... this figure starts to drop dramatically.

So even if you can gauge what your system will handle, there is certainly no given you'll be able to keep that throughout.
It's not likely but let's for arguments sake say you're minimum system is the same as this setup, and again for arguements sake we'll say that you can use 600,000 polygons (triangles) on-screen at once even with your shaders and textures (which I'll cover in a bit).

Q: Alright so I have my polygon limit, how complex should I make everything?
A: As rules of thumb, even if you know exactly the limit you have you should always aim below that when initially creating your media. Given yourself some headroom here, as you never know exactly how many polygons will hit the screen at once (not that polycount is really your biggest consern tbh).

So we'll say, 100,000 out of 600,000 is our headroom. Leaving us 500,000 to actually play with.

The question is how do you really divide this up effectively?
Well this is done by determining what sort of game you're working on and what you need to have on-screen during this.

We'll use a first person shooter as an example because they generally have the most diverse numbers you'll see.
Here we can take a couple of case studies to show the different decisions made.

Not first thing to remember, is that number you have above that you've "discovered" your minimum system can handle. Yeah ignore that.. like completely for now.

I'm sure during your design phase you've decided what sort of game this will be (yeah it's an FPS, but believe it or not there are different types of FPS), for this we can bring out come case studies of potencial situations for your game.

Gears of War, Halo, and Serious Sam.
Now Gears, is strictly aimed at more technical and calculated action. So generally speaking there are never huge numbers of enemy on-screen at once. Focus is more around the environment and your useage of it. Another big factor of this game is you have team-mates along with being able to see yourself, as such a big part that has been taken out of the equasion is the visually represented weapon.

Let's say we 4 team members (including yourself), 16 possible adverage enemies, plus the environment which is split into playable area and background area.


As focus is on the environment we want to spend around 50% on that total. This leaves you to share 50% between 4:16 (or 1:4) .. so 10% on team, 40% on enemy. As far as the environment goes, again you want to split this between what you can see and as the distance objects are still a huge part of the atmosphere 15% to that and 30% to the playable terrain seems like a good enough compromise here. We're left with 5% that covers pick-ups.

So let's break this down in to the sections we've decided from what your refined max is:

- Characters Total - 250,000
- - Team (4x Character) - 50,000 (if we say 10,000 each this leaves 2,500 free for equippment)
- - Enemy (16x Basic) - 200,000 (again we'll say each is 10,000 so we have around 2,500 free for equippment)
- Environment Total - 250,000
- - Playable - 150,000
- - Background - 75,000
- - Items - 25,000
Total - 500,000

I mean for the enemy, you basically have 200,000 to share amongst all of them for on-screen at once. So you might half what their count is to double the number you can have on-screen... or double it for a boss but still have enough for a handful of little monsters.

For the most part you design the set-peices you're going to have and then decided how many can be on-screen at once and of what sort. If you want bodies to remain throughout the game, then scaling back often is the only real option.

After breaking it all down however it becomes obvious you really don't have anywhere near as much as you'd probably liked.

As was said above those, the best thing after figuring all this out; is to really work to a lower number for everything the enhance later if you can squeeze enough speed out.

Usually once you set on a character/enemy polygon count that'll never really change; instead you'll increase the world detail. Often this is a better scenario as it's much easier to do without quite a fair bit more work.

Q: Yeah this is all well and good, but what are the main causes for slow down causing low-polycounts?
A: Everything really. I mean remember the game in general has more going on than just the visual aspect. You'll probably have AI, Networking, Collision, Dynamics (Physics), Shaders, etc...

each of these things can take quite a bit of processor time, and affect the loop speed that in-turn affects the graphics potencial.

Also remember that, you don't only have a polygon limit, but also a pixel limit, and memory limit. While textures of 1024x1024 might look really nice and give high-resolution to your models detail remember they take up quite a fair bit of graphics and system memory, take longer to move between the two and generally take more power to render as they eat up your pixel throughput.

So using lower resolution textures, helps.
Also keep track of what texture is doing what... for example Shaders now generally use a Diffuse (colouring), Normal (lighting) and Specular (Highlighting); so that's 3 textures for a single model. This uses a lot of graphics memory for multiple objects, especially with high resolution models.

You'd also be good to not that a single texture = multiple draw passes for the entire model just to do a single material area (especially with Shaders)

So splitting up your textures into several smaller ones often you can get more detail, waste less space and be able to then set each aspect in it's own draw queue. This will cut down on the number of draws (which the less the better performance!), memory space, and often overall processing power needed.

Animation wise, less bones = less cpu power needed; although more keyframes = less cpu power needed for interpolation. Flip side being the model requires more space in memory.
A very good idea is to actually let a physics system take over the animation and only use basic keyframes... something good to remember is that DirectX Skin&Bone animation allows you to set time-indices for each keyframe.

So a walk animation only needs about 4 keyframes, combined with a physics ragdoll and IK you retain a fairly realistic walk at very little memory overhead and more reliance on the CPU during the physics calculation cycle (if TGC ever sort out DarkPhysics to be MultiThreaded, this means that it'll end up pratically no cost either over normal physics).

If left to a simple interpolation system though (believe DBP uses a Bicubic Interpolation) then we'll you'll need to set keyframes at regular intervals.

Try to keep all animations to around 6-15 keyframes across every 30-seconds.

If you're using Shaders, then make sure you know their rough throughput values. For example, anything using vertices (even just reading) will mean you can only use half the polygons you originally wanted to. As far as the pixel aspect goes, remember the shader will be running the same number of times as the rendered frames per second.

So if you have a full-screen shader, on an 800x600 resolution doing something like bloom. Then you'll find you'll render:
28.8million pixels/second (at 60fps) just doing that on everything; and depending on how well it's written it might take double that doing 2 passes for blur, plus a few nanoseconds calculating. The more complex the more calculation time.

If you have say a shadow shader on all 20 characters on-screen at once... and you're doing say shadow mapping; then you'll probably output to a 512x512 texture in order for it to be smooth enough.

So you'll be doing 512x512x20x60 (315million pixel/second) when you have a budget of 1.1billion/second, and you've just blown 1/3rd on shadows alone.. you can start to see how careful you have to be if you're actually thinking about it.

All of this is just really theoretical more than anything else based on Gears of War as a case-study. It's quite ironic really but atleast half if not more of that games possible polycount is lost purely due to what it can do pixel-wise.

I mean after all while yeah, the cards have a 1.1billion/sec pixel fillrate; on the flip-side that's if there is no 3D going on. So the fillrate also affects what you can draw and use.

Most of the time trial and error is just frankly easier. Microsoft DirectX PIX will go a long long way to showing you bottlenecks and what is happening, but on the whole you'll be just fumbling after you have your preliminary figures in a T&E fashion to get the best out of your engine.

In my opinion and experiences, the magic is all in the textures. A basic 3d model can totally be transformed by the textures. If you want an example, go check out some of the 'Best of the best' FPS Creator games. As I know, FPSC is crippled by its poor rendering capability, which has led to some really creative workarounds and texture tricks. If you only get to play one, though, try demon sun. Or the space one was amazing, but I can't recall the name...

-Junk