Jump to content
  • Advertisement
Sign in to follow this  
CelticDaddio

Determining FPS vs Triangles Rendered

This topic is 3757 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

I have asked a similar, more specific question before, but I am posting this additional question to request more help. To recap: I have been given the task of determining an application's frame rate as a function of triangles rendered. The specification of the objects is done by tri strips. The object input file has a section which lists vertices, for example a quad:
vertices
1.0 1.0 0.0
0.0 1.0 0.0
1.0 0.0 0.0
0.0 0.0 0.0
and a section which lists the tri strip indices:
indices
4 0 1 2 3
Where the first number is the number of indices, followed by the indices. There are similar sections for surface normals and texture coordinates. This is a custom in-house (i.e. stupid) format. My plan was/is to make a single quad, with an increasing number of tri-strips, and determine the frame rate for each quad. The problem is that for any significant number of tri-strips, the creation of this input file becomes extraorinarily tedious (at least for me it does). The main thrust of this post is to basically ask: Is this a dumb way to do this and if so, what would be a better approach? There are some parameters which are immutable and these are as follows: 1. The end parameter I seek is fps vs tris. 2. The input format of the file. 3. The FPS is calculated by the app under test, and that is the parameter I must report, as opposed to an offline gl debugger. Alternatively, I would like to know if there is an easier way to generate the input file vertex index list. Creating the vertices is easy... I can whip out some C code to do that in about 5 minutes. The issue is generating the tri-strips from the vertex data. Will NvTriStrip or tri-stripper do this for me, without generating a tri-strip of only two triangles? Thanks for your patience and help, CD

Share this post


Link to post
Share on other sites
Advertisement
NvTriStrip or tri-stripper have the target of creating as few strips as possible, but they can't guarantee that there are strips of only 2 triangles. NvTriStrip, however, has a parameter that let's you say: create a single strip by inserting degenerate triangles (processed but not rendered), i.e. "stitching" the strips together.

Share this post


Link to post
Share on other sites
That's fine but in the end it's a meaningless test. FPS has vastly more to it than # of tris rendered. For instance, render the tri's with no overlap between them: super fast because no overdraw. Render exactly the same # of tri's stacked from far to near clipping plane: horrible framerate because of overdraw. In the first instance you're touching each pixel of the frame buffer once, in the latter you're touching it # of triangles times.

There a at least dozens of factors leading to FPS, generally least of which is # of tris. Very few applications these days are limited by # of triangles.

context switches (are you changing shaders, materials, lighting, etc)
overdraw
fill-rate

-me

Share this post


Link to post
Share on other sites
Good info, and I understand, but...when the customer asks for something, you give it to them...then explain why they need additional information....So I must forge ahead.....
CD

Quote:
Original post by Palidine
That's fine but in the end it's a meaningless test. FPS has vastly more to it than # of tris rendered. For instance, render the tri's with no overlap between them: super fast because no overdraw. Render exactly the same # of tri's stacked from far to near clipping plane: horrible framerate because of overdraw. In the first instance you're touching each pixel of the frame buffer once, in the latter you're touching it # of triangles times.

There a at least dozens of factors leading to FPS, generally least of which is # of tris. Very few applications these days are limited by # of triangles.

context switches (are you changing shaders, materials, lighting, etc)
overdraw
fill-rate

-me


Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!