What is an achievable way of setting content budgets (e.g. polygon count) for level content in a 3D title?

Question

In answering this question for swquinn, the answer raised a more pertinent question that I'd like to hear answers to. I'll post our own strategy (promise I won't accept it as the answer), but I'd like to hear others.

Specifically: how do you go about setting a sensible budget for your content team. Usually one of the very first questions asked in a development is: what's our polygon budget? Of course, these days it's rare that vertex/poly count alone is the limiting factor, instead shader complexity, fill-rate, lighting complexity, all come into play.

What the content team want are some hard numbers / limits to work to such that they have a reasonable expectation that their content, once it actually gets into the engine, will not be too heavy. Given that 'it depends' isn't a particularly useful answer, I'd like to hear a strategy that allows me to give them workable limits without being a) misleading, or b) wrong.

Answer 1

From my understanding its much easier to reduce the complexity of a model than it is to add detail for a model that has been skinned and rigged. I know some companies take advantage of this by pooling very detailed assets and scaling them down depending on the situation.

Valve does this with their NPCs. The NPC are modeled in extreme detail without any sort of mapping and then scale down the detail to a level acceptable by the current technology and tricks such as various mapping techniques applied based upon detailed models (or even automatically created).

This also helps with future proofing as you will never need to recreate the assets, only tweek them for each new project. This also has the advantage that there is no need to wait for a team to perform benchmarking that is context specific before the assets can begin to be developed. The artists can be fully involved from day 1.

Answer 2

Okay, so our strategy is:

• Make up some placeholder geometry, of roughly the right scale for the final content. That can be buildings or characters. It doesn't have to look anything like the final content, it can be boxes / spheres / etc., but it should be tessellated so that it has a decent number of polygons. If you're doing characters, make them have a representative number of bones.
• Alternatively, use someone else's geometry. If you have a title whose quality level you're trying to match, find some way to grab their models (perhaps using a DirectX scene grabber).
• Make sure your geometry has a representative shader on it. If you're expecting to blend several textures, do that, even if the textures are all single colour. Make sure the textures are non-trivial resolutions, even if they are all one colour.
• Put in a sensible number of lights.
• Put the camera in a realistic place, pointing at the largest amount of geometry you can (e.g. standing on a hilltop looking over the level)
• Load the scene on your slowest and fastest target hardware, and measure FPS.
• Vary the amounts of geometry / lights / shaders / texture resolution up or down to get a sense of what the trade-offs are (e.g. you can have a dozen extra lights but you'd have to cut the poly count in half).

Finally: be conservative with your numbers. Rendering is not the only thing your game will have to do, so decide one what proportion of your frame you want to spend rendering, and make that your target. E.g. if you want to spend two thirds of your frame at 30fps rendering, then target 1s/22ms (45 fps) in your tests.

Out of all of that, you should be able to give example scenes. E.g. here's a scene with 200K polygons, 5 static lights and no more than 3 dynamic lights per model, with 15 characters of 50K polys and 30 bones, and it runs at 60fps and occupies 30MB in memory.

Answer 3

Vertex Count

I have researched "Polygon Count" for over 15 years. There is no strict way to tell how many is your limit, especially with more modern software and hardware. Limits were much more useful in engines that only supported 4,000 triangles for an entire level. Now, you will find most objects in the game environment will exceed that individually.

What ultimately matters is what the engine is doing with the polygon strips.

When the engine renders each model, it takes your UV mapped coordinates, the texture/material represented on the triangles, and creates triangle strips. In most cases, a triangle fan is broken up into separate triangle strips per triangle. This increases the number of triangle strips, decreasing performance.

A prime example of fixing this is the flat top of a cylinder. 3D packages generally set up a triangle fan with a vertex in the centre. I delete the edges and the centre vertex, then create quads across the face. This should then triangulate into a single triangle strip instead of multiple single-face strips, without changing polygon count.

Take the polygon count as a guide, and take care of how you model, and UV Map the mesh. Less splits in the mesh when UV Mapping can often be more beneficial.

Next, consider what can be faked with normal maps. A flat face with a lot of detail case usually be normal mapped. Curves only need to be round where you can see a silhouette. When looking at the curved faces front-on, you should not notice the difference between your high-resolution assett, and the game-resolution assett. The silhouette is what makes the difference in your model when normal maps are involved. Silhouette can now be modified with DirectX 11, using tessellation and displacement mapping.

Game Design

Consider the following when designing your game:

1. Define game type (eg. action/adventure/racing/scroller)
2. Define view type (eg. first person/third person/orthographic)
3. Define computational power for your market. (eg. enthusiast/casual gamer)
4. Create a visual style you wish to achieve. Do you want it to look like, for example, Crysis 2, Borderlands, Bloodforge or Gears of War?
5. Define important objects to the player. Are your props going to be a centre of focus or merely backdrop?
6. Are the visual meshes also the collision mesh?

Using the game and view types, decide what the depth of view will be. Are you going to see distant objects, and with what clarity? Are you making something with limited view, such as a corridor shooter? (eg. Gears of War) Are you making something free-roaming with open landscapes? (eg. Skyrim)

Once you know what it should look like, you can research the games which are similar.

Animation will then limit your ability to increase polygon count. Static meshes, anything that remains in the same position is cheapest on the GPU and CPU. Especially if they are not physics objects. For physics objects, you can often create simple collision hulls, and complex visual meshes. There is not enough interaction in most games to notice the difference. Animation moves your model 3-Dimensionally, with several bones per vertex, blending between the weighting from each of them. This can be expensive on CPU time, which can clash with AI and software-based physics. The more vertices being affected by the number of bones in the entire model will decrease CPU performance. This is the other reason game characters are considered "art". It is very difficult to define a polygon limit.

My Example

I use the UDK, making a slow-paced third person shooter, with limited numbers of players and NPC's on screen at any time. For this, I am aiming for approximately 10,000 triangles per player, 5,000 triangles for typical, generic enemies, and if I were making a "boss" style character, around 15,000. Additionally, weapons for the third person around 4,000 triangles will come up highly detailed. Vehicles around 10,000 triangles. Everything will require Level of Detail, because I require long view distances.

If making a first person, I would base the arms on around 2,000 triangles, weapon around 5,000 triangles, with normal mapping for each.

Conclusion

This is what "It depends" probably means, but I thought it might clarify some things that people often wonder about.

1. Use polygon count as a guide.
2. Look at areas which could be normal mapped instead of modelled.
3. Be careful when placing triangle fans, if possible, create a strip.
4. Use less splits on the mesh when UV mapping, keeping strips in mind.

Answer 4

One method I can think of is using automatically constructed scenes to generate statistical data from which you can decipher the information you're looking for.

1. Get a large volume of assets (could potentially be automatically generated).

2. Create a tool to generate scenes which can be loaded by your engine using the asset pool.

3. Run a bot which will move your camera around the scene. You may also want to run some other bots to make the scene more dynamic, including lights.

4. Collect as much information as possible and throw it into a database; fps, poly count, shader changes, number of lights, draw calls etc.

5. Make/get some tools to display the data in your database in as many ways as possible.

This link may provide some more ideas: Dead Rising Tools