newbie questions...

[webosk]

Hi all,

I'm currently attempting my first forray into the world of 3D graphics and I have a few general questions:

1)  On average, how many polys are drawn each frame in modern, commercial games?  I'm just looking for a ballpark/order of magnitude estimate here (i.e., a thousand, ten thousand, etc.)  I basically just want to get a feel for how well my rendering engine is performing...

2)  When I profile my app, it seems like most of the time is spent swapping the buffers (as i would expect), and the other largest chunk of time is spent in the method that draws my vertex arrays.  What percentage of time should be spent swapping buffers (if there even is a general answer to that question) and is there any way to speed up the swaps?

3)  When animating objects (for example characters), is it better/more common to do so by having a set of "pre-rendered frames"-- that is, a different set of vertex information to describe each frame of an animation-- or by modifying the base geometry of the object within my code (e.g., using some sort of skeletal animation)?

Thanks a lot in advance...

[princec]

1) Not entirely sure but likely to be around the 10k mark these days. But - it's the end result that counts, not how you got there. If you can make a fantastic scene in 1,000 polys it doesn't matter.

2) SwapBuffers calls can't be made any faster. When you call Window.paint() it has to finish all the pipelined OpenGL drawing that you've set up, which is where a large chunk of the time goes; and then it'll sit in there and wait for the monitor vsync if you've enabled it. This artificially skews the CPU time into paint(). To find out how much time you're really spending doing things, disable vsync, and call Gl.glFinish() before Window.paint() which will finish all the GL commands waiting.

3) Prerendered frames are a lot faster. If you're dealing with, say, only 5-10 models on the screen then skeletal animation will be possible (if rather hard!); but if you're dealing with 100-200 models on the screen the overhead is generally too high to do skeletal animation. The very latest graphics cards might be able to cope by cleverly distributing the load between the CPU and GPU by various means.

Cas

[oNyx]

Q3's default maps were build with a 10k tris guidline (within PVS) the absolut maximum was set to about 15k. Usually you have about 8k tris on the screen.

Doom3 won't have much more. Details are done with bumpmaps. High polycounts would be kinda bad btw - collision detection is poly-accurate (no big fat hitboxes ).

HL2 on the other hand just does more of the old stuff... so it will have incredible high polycounts (and a bunch of shader effects).

However, usually you won't reach critical polycounts in a hobby or semi-pro project.

Oh and there is also something simpler than skeletal animation - (key?) frame interpolation. Quake1 for example looks quite odd nowadays... running at several hundret fps and the models are animated with 18 (or less) fps. (There are several QuakeWorld clients wich have frame interpolation)