Archived

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

dopeflow

How many tris can a graphic card handle nowadays??

Recommended Posts

Ive been running some benchmark test on my engine, those involve a quadtree for rendering the terrain. Frustum culling is used to test the nodes and units against the view. The model is about 600 polys I think and Im not using any lod algorithms and no vertex arrays either for the units yet. In this screenshot, lighting is on (calculating each of the tris normal every frame and setting their normals, only for the models), for an average of 76000 triangles. Im getting a *gulp* 7 fps. http://pages.infinit.net/mnok/benchmarktrislightingon.jpg With almost the same settings but with lighting off, I get 25 fps for ~80000 triangles. http://pages.infinit.net/mnok/benchmarktrislightingoff.jpg Those test were done with my geforce2 mx. Im sure when I add vertex arrays for the models I will get a considerable gain in performance but I definately thought todays hardware could handle > 500000 tris.

Share this post


Link to post
Share on other sites
Well I got 32768 unlit textured polys to run on a geforce2 mx at 200fps with vertex arrays. Today''s hardware like the Radeon 9800, GeforceFX, can easily handle over 500,000 polys per frame. Higher end graphics card these days (like the geforce4 ti and higher) can also easily handle over 500,000 triangles but to get the many, you''ll have to use vertex arrays (and a geforce2 mx isn''t exactly considered "today''s hardware").

I got my terrain engine to render 524,288 multitextured (unlit) polys on the screen at 30fps on my geforce4 ti. Vertex arrays will greatly speed up your engine, as will an lod scheme. Also you should look into the new ARB_vertex_array_object extensions, as that will give even higher speed increases.
quote:

lighting is on (calculating each of the tris normal every frame and setting their normals, only for the models)



As far as I know (but I''m not too familiar with lighting using normals), you shouldn''t be recalculating the normals every frame especially if the model is static. The normals don''t change unless the model is animated, so don''t recalculate the normals unless your model is running through an animation (don''t quote me on that tho...).

Hope that helps

Share this post


Link to post
Share on other sites
Thanks for your response. Well those are just some preliminary tests, I dont think I will keep calculating the normals in real time. If I add bump mapping though I will need to, for the animated mesh.

Is there a limit to how many vertex arrays you can use? Depending on hardware? I will look into that extension, so long as its supported by geforce2 and higher.

I am not going to be implementing lod because the view is top down like in warcraft3 so you will always be from same distance.

My goal is to handle ~200 units of 750 tris each at same time on screen with no slowdowns (so maybe keep a fps higher than 60 fps at all time)

That makes 150000 tris for the units and about 20000 max for the terrain. Not too bad. If I want real time lighting though it will be another story.

Share this post


Link to post
Share on other sites
quote:
Original post by dopeflow
My goal is to handle ~200 units of 750 tris each at same time on screen with no slowdowns (so maybe keep a fps higher than 60 fps at all time)



This makes 9 millions of tris per second, which should be achievable.

Don''t forget that shadowing algorithms (both PSM, shadow volumes or even simple projected shadows) will double that number.

No matter how much you worry about geometric throughput, the sad truth is that the real limit is always the fillrate. Well, unless you make an RTS called "Gouraud Warriors in Flatland" :-)

Share this post


Link to post
Share on other sites
well using vertex arrays for the world and simple glBegin for the characters i get 25000 tris at 70 - 80 fps on my radeon ddr -> almost 2 mil tris / s which is resonable

Share this post


Link to post
Share on other sites
quote:
Original post by dopeflow
My goal is to handle ~200 units of 750 tris each at same time on screen with no slowdowns


with 200 units on screen at once (implying hundreds or thousands of units off screen) i would worry alot more about how many units ai you can process per second ,-)

about 200.000 polys shouldnt be the problem on modern cards (though i wouldnt expect 6mill or 12mill on the gf2 mx.. 12mill would be about the number i can get with my gf3)

Share this post


Link to post
Share on other sites
quote:
Original post by dopeflow
...200 units on screen is unlikely to happen...



Famous last words.
Never underestimate your players and level designers.

Share this post


Link to post
Share on other sites
It''s not so much a question about the geometry a certain 3D card can handle, but more about how much your code can handle. Getting the most out of a 3D card requires a well designed geometric management concept: from memory layouts, over the choice of a good spatial hierarchical structure, efficient data streaming methods, to highly optimized v/p shaders.

Share this post


Link to post
Share on other sites
I changed the way I render my meshes, using glDrawElements now. Im only getting a ~10 fps gain in speed when rendering 100 mesh. I thought the speed increase would be much bigger, but I guess I cant complain

Share this post


Link to post
Share on other sites
Can you just outline how exactly you''re handling the meshes, the structure of your main render code ? It seems you''re getting suboptimal performance: typically, the speed difference between immediate mode and VA''s (or even better VBO''s) is enormeous. If you''re only experiencing a slight performance increase, then chances are you''re doing something wrong somewhere.

Share this post


Link to post
Share on other sites
Sure, I use stl to store my entities (i know, bad start )
so each frame I test all my entities against the frustum, this means going through 100 elements of my vector so maybe that slows me down some, but not much...


then each mesh is rendered like such :

glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, posVB);

glDrawElements(GL_TRIANGLES, m_numTriangles*3, GL_UNSIGNED_SHORT, m_testTriIndex);

glDisableClientState(GL_VERTEX_ARRAY);

I dont have huge overheads for the class hierarchy tree, a CUnit is derived directly from CEntity...so each frame I just call m_entities->Draw(); of course if the i element passed the frustum test.

I asked my bro if vector would slow my app he assured me that a vector is fast unless you change its size a lot, which I dont.

Share this post


Link to post
Share on other sites
std::vector should be pretty fast, so I doubt this is a problem.

A couple of things to try:

* glEnable/DisableClientState(GL_VERTEX_ARRAY): don''t enable/disable the vertex arrays for each entity. Enable it once before you draw all geometry, and disable it when done. Or, even better, keep it enabled all the time.

* How much is m_numTriangles, on average ? You said something about 600, right ?

* Try to comment out glDrawElements(), and profile your app. Does it give you a large speedup, or does the performance stays more or less the same ?

Share this post


Link to post
Share on other sites
Ok, i now enable vertex arrays only once in my app, during initialization. No gain in speed that I could notice from that.

The triangle count for the mesh im using is 730.

Commenting only the glDrawElements line boosts my speed from ~30-35 fps to ~90-95 fps. I am rendering 100 meshes.

Share this post


Link to post
Share on other sites
quote:

Ok, i now enable vertex arrays only once in my app, during initialization. No gain in speed that I could notice from that.


Not with standard vertex arrays, but it gets more important, if you want to switch to VAR/VBO later on.

quote:

The triangle count for the mesh im using is 730.


That''s OK.

quote:

Commenting only the glDrawElements line boosts my speed from ~30-35 fps to ~90-95 fps. I am rendering 100 meshes.


Hmm. Well, 95fps without drawing a single face seems a little low. Are you doing any AI on the CPU side, or is it just culling ? In the later case, you should definitely profile and redesign the structure of your high-level culler, or you might have no CPU time left for AI and game logic

On the other hand, you seem to get a serious drop on the rendering itself. That can have a lot of different reasons. First, you should check if you are fillrate limited: the GF2MX has very little fillrate. Reduce resolution as much as you can, eg. render to a 160x100 window. Does this get you any performance gain ?

If not, then you''re geometry limited. Do you have any special states enabled ? Things like hardware lights, texgen, etc, are heavy on a GF2MX. Try to disable everything, and measure performance again. What kind of textures do you use, raw RGBA or compressed ? Also make sure to enable mipmaps (very important for speed).

If all that doesn''t help, then the next step is to try VAR/VBO. If everything is cached in VRAM (and that should be easy in your case, as all the units are the same), then this should give you a nice performance boost.

Last but not least, keep in mind that the GF2MX is a somewhat lightweight card, don''t expect too much from it.

Share this post


Link to post
Share on other sites
90 fps rendering my quadtree only. Which means between ~6000 to 10000 tris. Not a lot.

I am not doing any ai or any sort of treatment that would take a lot of cpu time.


Reducing resolution suprisingly doesnt give me much of a boost in speed. Went from 320X240 to 1024X768, and I got like maybe 10 fps more at 320X240. Im using lights but im disabling it via console and speed still sucks , I dont specify normals for the meshes yet anyway. All textures are generated with mipmaps. The meshes are not textured either right now.

My terrain texture is 3 megs, but I dont think loading only 1 big texture is such a big problem??

Ive set up a small build, maybe you guys with better gfx card could give it a shot??

http://pages.infinit.net/mnok/Release.zip

W,A,S,D to move around (all the entities are on the lower right of where you start.
~ to bring up console, and type help for commands

try enabling /disabling entities rendering see what it does for you. Turning off lighting doesnt do much since I dont specify normals for anything right now...

Maybe just tell me a bit about what kind of fps you get.

Share this post


Link to post
Share on other sites
I would say that there is something that is going on in your CPU that is taking a lot longer than it should... I''d say an optomized frustrum culling technique would probobly help a lot, but just profile and see where all your CPU time is going to.

Dwiel

Share this post


Link to post
Share on other sites
I got 450 fps without entities and 130 with. Just a thought, check that you don''t start from the beginning every time you look for something. That would be quite slow. Try and batch everything to be drawn in one go. It is hard to say what you could do to improve without actually seeing your source ;-) Size does matter with textures. Check your card capabilities to make sure.

____________________________________________________________
Try RealityRift at www.planetrift.com
Feel free to comment, object, laugh at or agree to this. I won''t engage in flaming because of what I have said.
I could be wrong or right but the ideas are mine.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I''m running an NVIDIA GeForce4 TI 4200 with AGP8x and with no entities running I get 60 to 61 fps. With the entities running I get a solid 12 to 15 fps. The entities are really killing it on the draw. It is mostly likely the culler. Of course, I still need to update my video drivers.

Share this post


Link to post
Share on other sites