I've just started the minor optimizations of my rendering engine and need some guidelines about "renderable objects": how many meshes, by average, does one of your complex model (like a house or a vehicle( contain and how many faces does these meshes, by average, contain?

Usually, each object is one mesh, and the number of triangles varies. If you have good skinning and animation, you could probably get by with a lower poly model, since it will still look pretty good. It really dependson what you are making, too. A house will not have as many faces as a person, just because a house is big flat walls, while a human is very irregular and curved.

Is your engine really slow currently, or are you just trying to squeeze a couple more FPS out of it?

What do you mean by one object? you won't (probably) pack each part of a car like doors and tires into one mesh (or group or whatever they're called in your favourite editor) because that'd be... stupdid?

instead of creating a vertexbuffer for each mesh, i'm experimenting to pack as much vertex data I can into several bigger vertexbuffers to that i won't get any overhead by changing streamsources. At the moment i get a slack of about 16 bytes for each 400k vertexbuffer and i need to find the perfect relationship between facecount / vertexbuffer size.

Quote:Original post by Metus
What do you mean by one object? you won't (probably) pack each part of a car like doors and tires into one mesh (or group or whatever they're called in your favourite editor) because that'd be... stupdid?

What is wrong with it all being in one file?

Do you mean one mesh as in a "*.x" file, or do you mean something else. I see no reason to have multiple file for each little part of the car. Most 3D modelers will let you split your model in various pieces (called subsets) that DX can deal with seperately...

Typically, I want everything that renders with the same material to be in a contiguous triangle list. For anything that's soft skinned, that's the only way your modeler will keep sane in something like Max, too. Thus, I don't understand why you're saying "keeping all triangles together for an object is stupid."

Thus, for a typical tree, I might have two or three meshes; one for trunk/limbs (with bark), and one or two for foilage/twigs. The second would typically be alpha blended, too.

Poly counts vary all over. Literally, I've had meshes that are 50 polys, and meshes that are half a million polys -- although the latter get split into ~8000 poly chunks for culling and LOD.

If you're optimizing you should first profile. Is it clear that you are vertex throughput bound? What does VTune say about CPU usage? How about if you make your window really small, does the frame rate increase? (i e, fill bound?) Don't optimize somewhere where you won't actually get much gains.

Stupid might be the wrong word, inconvenient might be a little bit better. The problem is that the expression "mesh" seems to have several definitions. My definition of a mesh is as hplus0603 descripes his tree; a subset of "material-bound" contiguous triangles.

As I can see, there'd be better to have a physically destroyable object (like the car) separated into several meshes just because the ease of transformations; if a tire can be torn apart from the car body, it's a separate mesh.

This is nothing i proclaim is better than anything else, it just suits me and my needs in my game engine. As I may have stated, this is actually *not* a real optimization, just a mere experimantation of the impact of using a high-count vertexbuffers instead of a low-count. My application is not bound to fillrate at the moment