How many tris can a graphic card handle nowadays??
Author
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.
Author
oh yea, I'm aware "today's hardware" isnt neccesarely a geforce2 mx but I mean its still a decent card 
[edited by - dopeflow on April 30, 2003 8:53:54 PM]
[edited by - dopeflow on April 30, 2003 8:53:54 PM]
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.
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
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
Author
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.
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.
Author
The extension you mentionned must be VERY new, cant find anything about it on google
Probably because it''s actually called ARB_vertex_buffer_object.
vertex_array_object was the ATI extension.
vertex_array_object was the ATI extension.
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" :-)
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
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)
Author
hehe well 200 units on screen is unlikely to happen, but still I would like it if it could run smooth with that many units getting rendered.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
