Archived

This topic is now archived and is closed to further replies.

SilverEagle

How many polys ?

Recommended Posts

Hi, We are starting a new project now, in the world of 3D. We are completly aware that we will need a lot of time to learn the API and the limitations of the actual hardware. However, we''d also like to start all at the same time (this is, programmers and graphicians). For this, I need some figures about the current state of the art in 3D, to provide the 3d modelers. The questions are: 1. How many polys (aprox. just a figure) can you use with a geforce 3 / P4 2000 Mhz (let''s say gouraud / phong triple-textured polys ? 2. How many polys should be used in the characters of the game ? (5000, 10000, more ?) 3. What is the current limitation on speed (portal/BSP/other space techniques due to large amount of polys, in screen polys (fillrate), geometry calculus or other (AI algos, sound calculation, etc) ? Any light on this would be great. - Juancho

Share this post


Link to post
Share on other sites
All three depend on how good your programming skills are

I don''t know the quoted rates for the GeForce 3, check the nvidea web-site, they''re bloody high but you won''t get anywhere near them in a real game.

Your character poly-counts sound way to high if you want to have more than a couple on screen at once. For example, the high LOD Quake 3 models have about 600 polys.

In my experience the major limitations on ''speed'' will be the quality of your culling system, for both rendering and collision detection. Basically this comes down to what sort of database you have for your scene. BSP trees are great for collsion detection, but can be slow for rendering. You will almost certainly need some sort of occlusion culling, because overdraw is the big speed killer.

I would tell the artists to use as few polys as possible. Once you have some code working and it''s fast then if your artists are any good they can always go back and add more detail later.

Share this post


Link to post
Share on other sites
First, thank you for your help. What I''d need would be more concrete figures based on experience. If you check the nvidia web site, they say you should be able to render 30.000.000 triangles per second, and that on an ''old'' geForce 2

The artists need a figure to truly work on the models.. Just ''use as few as possible'' won''t do (you know, they always want to know how many, if they are limited

600 polys for the characters.. Well, that''s way below what I expected (is for this that I needed the numbers).. I read somewhere that the new version of Tomb Raider will use at least 5000 polys for the character. That''s a *lot* of polys then..


Regards,

- Juancho

Share this post


Link to post
Share on other sites
Claimed poly rates on PC cards are usually nonsense when it comes to an actual game with lighting, texturing, transformations, AI etc.
50,000 polys max per frame on a 60fps game is what I reckon personally.
On a Geforce 2, PIII, around half that.
On a TNT2, as many ppl still have - well dont ask...

I think you''ll find next-gen console games are getting much higher poly throughput, because of their custom architecture, than PCs.
But if anyone can prove higher poly rates I want to see it!

A

Share this post


Link to post
Share on other sites
Andy is talking sense. 30 mil triangles per second is 500,000 tris per frame (at 60fps). This is ridiculous. You simply cannot generate the vertex data that quickly in real time.

In terms of concrete figures:

I think Quake 3 Arena generally draws between 2000 and 5000 tris per frame for static geometry (depending on the level and which node your in) though a lot of this is overdraw. Add another couple of thousand for entities. Then add 600 polys for each player (though the further away the player is the less poly''s are used, and the same applies for curved surfaces). I think your looking at around 10,000 poly''s per frame for the entire scene, yes *everything*

Quake 3 Arena runs between 30 - 50 fps a second on my PII 450 with a GeForce2 MX.

Quake 3 was written by John Carmack. You are not John Carmack. Think carefully about how many poly''s you really need. After all, it''s gameplay that''s important. In my opinion good texturing has a far greater effect than poly count on the final percieved quality of the render. But that''s just me

Galgiel.

Share this post


Link to post
Share on other sites
quote:
Original post by Someone1
[quote]Original post by AndyM
50,000 polys max per frame on a 60fps game is what I reckon personally.



This number is after texturing, lighting, game calculations, etc.?


Yes, its just a guesstimate though...
And only on a geforce3 super-machine, which I don''t have


Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hmm. You can get more out of your machine. By highly optimizing your engine and fine tuning every aspect of your vertex transfer pipeline, figures are a bit higher than that.

On my engine, I get around 150,000 tris/frame at 50FPS on an actual game scene. On a GeForce2 GTS, AMD 1.2GHz. Using all the tricks, VARs, fencing, AGP DMA, cache optimizations and handoptimized ASM on some parts.

- AH

Share this post


Link to post
Share on other sites
Using my Radeon32 DDR I can attain 4M triple textured, vertexlit tris / sec. A GF2 could probably do that too, if you sacrifice a texturestage.

Anyway, make your engine scalable and you don''t have to worry about it.




Share this post


Link to post
Share on other sites
not to detract from the topic at hand, but galgiel, can you explain to me why a BSP tree would be slow to render.

I was under the impression that they could be very fast, as you are doing a form of collision detection (nodes with the view frustum) to determine what is visible... and surely the combination of front-to-back rendering and hardware z-buffering is fairly decent at combatting overdraw (although admittedly very late in the process)

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Hmm. You can get more out of your machine. By highly optimizing your engine and fine tuning every aspect of your vertex transfer pipeline, figures are a bit higher than that.

On my engine, I get around 150,000 tris/frame at 50FPS on an actual game scene. On a GeForce2 GTS, AMD 1.2GHz. Using all the tricks, VARs, fencing, AGP DMA, cache optimizations and handoptimized ASM on some parts.

- AH


That certainly sounds good - but then I don''t know all the tricks or use ASM. Perhaps you should do a doc on the subject...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
> That certainly sounds good - but then I don''t know all the tricks or use ASM. Perhaps you should do a doc on the subject

Perhaps, yes But nVidia has already done a good job, so have a look at http://developer.nvidia.com/view.asp?IO=Using_GL_NV_fence
This paper presents all you need to know about really high performance vertex streaming. But be aware of the fact, the high transfer streaming is only one part of the problem, the other one is your vertex pipeline in your 3D engine.

Just a few points to get more speed:

* Always use VARs, don''t mix them with standard vertex arrays, CVAs or even glBegin/End pairs. Some 3D board revisions need to flush their complete AGP transfer buffer, if you call one of those while in a VAR transfer. You can call them after you rendered your main geometry, to do things like HUDs or stuff, but not inbetween.

* Use AGP DMA.

* Use fencing on double buffered VARs, you can perfectly synchronize your CPU and GPU, having them work in parallel. While your GPU is pulling vertices and rendering faces, your CPU is building the next chunk of VAR buffer, at the same time.

* Always use the fastest available data format for vertex arrays. Floats, unsigned bytes, int''s. Never use doubles. Put your FPU in reduced precision 32bit mode (don''t worry, it''s still accurate enough), you''ll gain speed on some FPU commands.

* Use interleaved vertex arrays where possible. Use DrawRangeElements, whre possible.

* NEVER EVER repopulate your VAs every frame. Lethal for performance. If you have to update them, because geometry is moving, keep in mind that you can only update the vertex positions in the VA, texcoords and index arrays stay the same, no need to recalculate them. You can also update one part of your VA, while the 3D card is already pulling and rendering another part. Requires perfect CPU-GPU sync, though.

* Have efficient data structures to store your 3D data. 4 byte aligned, size must be a mutliple of 4. Better waste a byte or two, than killing alignment.

* Use lazy VA updating. Now, that''s a very important point. If you want dynamic geometry, you have to update vertex positions, normals, perhaps texcoords and vertex colours (eg. for DOT3 bumpmapping). That''s time consuming. But why updating geometry in parts of the scene, that are currently invisible ? So you have to design a system, that will only update parts of the geometry that the user can currently see, eg. what is in the view frustum, not occluded or behind portals. Everything else is ignored, not updated. As soon as the user moves, the system will catch up with the lastest state, and update the geometry accordingly.

* And, of course, all the other standard optimizations tricks, review your algorithms, optimize your data structures, use ASM if really necessary, etc.

- AH

Share this post


Link to post
Share on other sites
Bad Monkey - I''m no expert, just a student, and your right traversing BSP trees is very quick. But from the experience of writing ''my first bsp renderer''(tm) of the leafy 3d variety I found that deciding which nodes you want to render is quick, but the overheads of actually rendering from all those little pieces of data can be relatively high, (at least in DX8).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:

Ah ha OpenGL, I''m using DirectX... interesting
Anyhow thanks



The same rules apply to D3D, it''s the same hardware behind it.

Though, I don''t know, if you''ll be able to use the newest vertex streaming modi and CPU/GPU sync, since those techniques came out after the last DirectX version was released. So you would probably need to wait for the next DX.

- AH

Share this post


Link to post
Share on other sites