Is there a command or easy way to tell exactly how many poly's your vid card is rending during a given frame? glHowManyPolys^() ? or would I just have to count them as their rendered? I could imagine that being difficult as you dont know exactly what the card is culling and what its not.

There is none... but you can count of course how many polys ur sending to ur card... and do your own culling

hmmmmm...so the answer is pretty much no. you can count how many your sending to the card to render but that doesnt help.

o-well....

But that's pretty much what people do. If you read something like 15M tri/sec it's the number of polys they send to the card per second, not the number of polys which is actually rendered. I think this is feasible to measure performance since culling also takes some time. So if you send a lot of polys to the card which are actually culled, the performance will drop also.

Why do you need this anyway? Just to measure performance? For benchmarking?

If it's for benchmarking your card, you might write a program which just draws masses of polys which are all on the screen (so none is culled).

Quote: Original post by Lutz
But that's pretty much what people do. If you read something like 15M tri/sec it's the number of polys they send to the card per second, not the number of polys which is actually rendered. I think this is feasible to measure performance since culling also takes some time. So if you send a lot of polys to the card which are actually culled, the performance will drop also.

True. This is why most culling algos are coarse-grained.

Quote: Original post by Lutz
Why do you need this anyway? Just to measure performance? For benchmarking?

If it's for benchmarking your card, you might write a program which just draws masses of polys which are all on the screen (so none is culled).

It's useful to know this at runtime. The most obvious advantage is that it will be a real-world test.
Syntetic benchs are good to a single degree, we all know why.

How to do that?
If you use vertex arrays, you could just divide your number of indices by the number of vertices per-primitive. This gives you a number of polys-per-frame. This is useful info. Once you have that, jumping to polys-per-sec is pretty easy (I wonder if this information is really needed however).

Yes pretty much im just looking for a means to bench mark a given program for the sake of optimization. Also a bit of a learning process. Figure out what codeing produces what results.

If I could write some code that produces your 15m tri/sec at 30FPS then find a better way to do the same for 35FPS it seems that would be worth my while.

Also, being able to see how the performance changes as the poly's per frame/second increases seems like good info to have in the course of writing a graphics engine.

Quote: Original post by Cannibal_Coder
If I could write some code that produces your 15m tri/sec at 30FPS then find a better way to do the same for 35FPS it seems that would be worth my while.

You can draw less triangles per frame to increase your FPS! #tris/sec will stay 15M. So FPS is not a good measure.

The number of tris per sec takes into account the frame rate AS WELL AS the tris/frame: #tris/sec = #tris/frame * #frames/sec
So actually the #tris/sec is already a good benchmarking indicator.

If you draw half as many tris per frame, the frame rate will (approx.) double but the #tris/sec will stay (approx.) constant.

If you, however, improve your graphics engine (by using VBOs for example) the number of tris per frame will stay the same (since you still draw the same things) but the frame rate will increase. So also the #tris/sec will increase. Thus, #tris/sec is good for benchmarking purposes, I guess.

Uhhh...isnt that pretty much what I said? I know the difference between #tri/sec and #tri/frame but in the end its a matter of performance. And knowing how to check this to gage the performance of a bit of code is exactly what im looking for.

As an example we'll go back to my fav space RTS Homeworld 2. If I can draw the Projenitor Dreadnaught, 2 Hygaraan Battlecruisers, 2 Destroyers and a shlew of flak and torpedo Frigs with some asteroids, a planet in the background and the world sphere (im assuming thats what they used) and get 60fps then optimize my code with LOD'ing, maybe some culling, VBO's( what are/is VBO's exactly?) and whatever else and can get 70FPS...kudows to me.

So I suppose what im REALLY looking for is a way to count my tri's for the sake of optimization.

Vertex Arrays seem to be what I was looking for. (Thx Krohm)

Im working on a quake3 clone but the Furstum & Culling is generic and should work well in both indoor/outdoor/space scenes

Consider this, standing at the one side of the map looking at the wall...This is the map

-------
-
- <- -
-
-------

And there i look at the wall so after culling there is like only 10 polys possible after backface 5.. and ill get a fps of 380

Then standing in the same corner looking towards the other side is see about 1500(out of 2039) polys,backface - 700. Then i get a fps of about 120.....

Ofcourse i havent used any extensions so thats why it makes such a diffrence...

Consider this...

In Homeworld2 You simple check furstum culling by the Vehicle(objects) center and Radius... already u have technically cut out about 7/8 of the objects. Now consider that each object has 1000 poly's
Thats 1000 Polys two 8000.

But it goes further, take collision detection. a q3 map has 2000 polys +- but checking 2000 * 10 Players = 1 fps.

And so further you must Sub Divide (Octree-BSP tree) any static Polys.