PDA

View Full Version : Get amount of tris being rendered? how!?



bansheeogl
04-21-2005, 04:41 PM
how can i get the amount of triangles being rendered by opengl!?!?

or should i keep track of them at my engine (that should be ugly if opengl didnt had a way of giving me the amount of triangles being rendered!)

Jan
04-21-2005, 10:07 PM
Sorry, you have to do it the "ugly" way. But, hurray, it's only 5 lines of code!

bubbaJr
04-22-2005, 07:53 AM
what are the 5 lines of code?

Overmind
04-22-2005, 11:20 AM
Why is doing it with the engine ugly?

It doesn't really make sense to send some information to OpenGL and then read it back from OpenGL instead of using what you have already, does it?

bansheeogl
04-22-2005, 12:41 PM
eeeeeeeeeeehhhhh and if you use a glu sphere what? should I know how many polygons that sphere has before making it? you made no sense. okey I can know how many polies my loaded meshes has BUT I WANT A REAL NUMBER FROM OPENGL INSTEAD. whats the problem!?

ZbuffeR
04-22-2005, 01:53 PM
A guess : use GL feedback mechanism ?

Jan
04-23-2005, 12:55 AM
1. Nobody uses gluSphere/Disc/Whatever in a real engine, those are just there to get started quickly to learn OpenGL, not to use them in a real project.

2. You can calculate the number of triangles, a gluSphere, etc. has by yourself (granted, you need to know how a gluSphere gets built)

3. An engine typically not only counts triangles/frame, but also polygons/frame (yes, there can be a difference), number of batches in general, number of texture switches, number of shader switches, averages number of triangles rendered with one texture, average number of triangles rendered with one shader, minimum/maximum/average number of triangles rendered in one batch, etc. etc. etc.....

You see, it would make no sense to let OpenGL do that work, because if it counts one information for you, why shouldnīt it do this and that too. Also it would add complexity and especially processing demands, although a lot of people wouldnīt need it. And you know, OpenGL is supposed to be fast, so it does only what is absolutely necessary.
Everything else has to be done by you!

Jan.

UrbanLegend
04-23-2005, 06:56 AM
Taking all the rhetoric away the answer to your question is

Yes your engine will have to count how many primitives it sends to the Opengl Pipe line

One place to do this would during the Cull stage of your engine and simply count the primitives that pass the cull test for that frame etc.

As pointed out Opengl's job is to draw everything you pass it as fast as it can, any thing else is down to you and your application.

____________________

Gordon.

www.3dscenegraph.com (http://www.3dscenegraph.com)
Vega FAQ/Samples (http://www.3dscenegraph.com/vega)
SceneGraph Forums (http://www.3dscenegraph.com/3dsceneBB/)

bansheeogl
04-24-2005, 08:27 AM
And how do I know how many triangles are being rendered per view?? its important to know.

04-24-2005, 09:05 AM
Originally posted by bansheeogl:
its important to know.Because?

As far as I am concerned, this information is completely irrelevant. I count the amount of data I send down the pipeline after doing a coarse object-level frustum culling, I dont need to know how many triangles get clipped or culled by OpenGL.

bansheeogl
04-25-2005, 05:38 PM
then you are either no developer or a very bad one.
YOU NEED TO KNOW how many triangles are being rendered at once at your scene. You cant have 30.000 on a part and then 200.000 on other, said the limit was of 30.000 then you are doing something wrong. you need to limit all this because people with slow systems will suffer very bad frame rates. so or you either give mesh quality options or you try to keep polycount low, by knowing how many poligons are being displayed at once you can debug this and have your scenes with a fairly good number of polygons.

Jan
04-25-2005, 11:55 PM
Originally posted by bansheeogl:
then you are either no developer or a very bad one.
YOU NEED TO KNOW how many triangles are being rendered at once at your scene. You cant have 30.000 on a part and then 200.000 on other, said the limit was of 30.000 then you are doing something wrong. you need to limit all this because people with slow systems will suffer very bad frame rates. so or you either give mesh quality options or you try to keep polycount low, by knowing how many poligons are being displayed at once you can debug this and have your scenes with a fairly good number of polygons.I agree, but where is the problem, again? You need to do it yourself. And you CAN do it yourself. The gfx-cards are not doing anything mystical internally, which increases/decreases the amount of triangles, so every triangle you send down the pipe takes away processing time. Now you only need to count, how many triangles you send down that pipe.

Thatīs it. If you need further explanation, read this thread again.

Jan.

04-26-2005, 12:54 AM
Originally posted by bansheeogl:
then you are either no developer or a very bad one.
You are the right one to state something like this. I dare say that you still have LOTS to learn.

You should start with understanding how a pipelines works and why its a bad idea to read back results from it. Sure you can do occlusion queries but you wont do that on a per triangle basis.

Secondly you need to understand that there is a difference between being transform-, fillrate- and bandwidth bound not to mention the difference between triangles that go into the rasterazation stage and triangles that actually produce visible fragments.

Finally you need to realize that only the amount of triangles you pass down the pipeline and the amount of state/shader/texture changes really matters (something that is easily countable and which I do) and not how many triangles really produced visible fragments.

But if you want to continue to act like a jerk you should not expect too much help here.