Sign in to follow this  

tris

This topic is 4518 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hello I know following questions have been asked plenty of times and that it is not possible to provide a defintive answer. However hardware is in continuos evolution and I need just a rule of thumb So - How many tris per frame can be reasonably displayed at 60 fps on an avarege system? - Any substantial difference beetwen static and dynamic meshes? is it possibe to provide a coversion factor, something like : 1000 tris of a dynamic mesh are equivalent to 3000 tris of a static one ? - Any substantial differece beetwen sleleton and morping (.md2) animation again, for example a 1000 tris human character with skeleton animation is equivalent to a 1500 tris human character with morphing animation Thanks a lot

Share this post


Link to post
Share on other sites
You're right that there is no definitive answer. There is so much more going on than straight-up rendering triangles, and lots of factors (like number of lights, textures, indices, how many drawprimitive calls there are, complexity of shaders, etc etc)

But just to give some input, I have found from personal experience that somewhere in the range of 5000 (give or take several thousand !!) textured and lighted triangles rendered will run at 60fps on my computer.

Share this post


Link to post
Share on other sites
Quote:
Original post by bjle
You're right that there is no definitive answer. There is so much more going on than straight-up rendering triangles, and lots of factors (like number of lights, textures, indices, how many drawprimitive calls there are, complexity of shaders, etc etc)

But just to give some input, I have found from personal experience that somewhere in the range of 5000 (give or take several thousand !!) textured and lighted triangles rendered will run at 60fps on my computer.


I have no stats of my own to provide, but it'd probably be more helpful to the OP if you included your specs as well.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
An old Radeon 9700 (R300 based chip) had a maximum triangle throughput of 300 million tris per second. This assumed 100% vertex cache hit rate and no pixels rasterized (aren't marketing numbers fun?).

At 60Hz, you'd be looking at 500000 tris per frame absolute max (before you laugh too hard, to not exceed numbers are usually good things to have in mind in order to work out orders of magnitude complexity that you have to deal with).

That being said, assuming an optimisitic 50% hit rate on the vertex cache, and assuming that the vertex program is ~30 cycles, this means you'd get a theoretical triangle through put of around 155 million (this drops you down to 258000 tris per frame).

Yeah, I know this stuff is "BS", but if you know how marketing numbers are created, it is actually very easy to reproduce. How practical those numbers are is another story (just knowing how they get them really helps you grasp what is really possible).


Most of the time game type things are fragment limited rather than vertex limited, so you have to take into account the projected triangle area, complexity of your pixel operations (i.e. fragment shader length), zbuffer coverage, hiz effectiveness, memory clock, etc.

Balancing the pipe is hard... the key tools to help you out are back face culling and rendering resolution. Turning on cull for front and back face allows you to kill all primitives before they are rasterized, giving you your vertex bound performance numbers. Testing if you are fragment bound is as simple as reducing the resolution of your rendering (if you normally draw to 1024x768, try rendering to a 64x64 and check your frame rate).

In summary, there are no hard rules or numbers, only guidelines. Dynamic buffers will be no faster than static buffers (but dynamic and static may be the same speed, it depends on the internal driver implementation and perhaps even number of surfaces allocated!). Having the CPU touch the data for any purpose is usually slower than not touching it.

Your only path to success is to try stuff out and keep around your experiments as what may be fastest today may not be the fastest thing tomorrow.



Share this post


Link to post
Share on other sites
Sign in to follow this