Archived

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

cyansoft

Knowing your limits

Recommended Posts

The other day there was a thread where someone listed the theoretical limits of triangle rendering for each generation of cards, and it got me thinking. One thing I worry about when working on my engine is rendering speed. How am I suppose to know what''s acceptable performance for the hardware? For example, my development box has a GeForce2 MX card with 32MB of VRAM. I decided that this would be my hardware minimum(I figured if it runs fast enough on my card and it''s suppose to be the minimum hardware, then I shouldn''t have to worry). The poster from the other day stated that the GF2 can do a 20 million triangles per second, it theory. He/she also stated that getting 1/4 of that theoretical limit in a game is very good. So going by this information, my triangle limit is 5 million per second. If my desired frame rate is 60Hz, that means I should cap my triangles per frame at about 80k. But there are so many other graphical factors that affect the frame rate, such as: - Fill rate - State changes(textures, colors, shaders) - Lighting - Geometry arrangement(strips, fans, etc) - Rendering method(Intermediate Mode, Display Lists, Vertex Arrays, VBO''s, etc) Right now, I just loaded my first large(58000 triangles) static model(a Half-Life level) in my program, using OpenGL''s VBO extension. With lighting, no textures or lightmaps(but texture coordinates provided), I get between 19 to 34 frames per second. Ignoring any culling and space partitioning, is my performance acceptable? On the surface, it looks like it''s not. If 80k is the cap for 60 frames per second, why do I get 19-34 with 58000 triangles? Changing my resolution from 800x600 to 640x480 makes no difference in FPS. But when I turn lighting off, I get between 45-55 which is closer to the goal. I suppose lighting will not matter since the geometry will eventually use light maps. But then I need to worry about texture state changes! I guess my main question is how does everyone measure their card''s limits so you don''t go overboard with too many features that would kill the frame rate? I''m afraid to move on to culling techniques until I''m confident I''m getting reasonable rendering performance out of the card. Am I worrying about nothing? Bob

Share this post


Link to post
Share on other sites
I say, don''t worry with all the theorical BS the manufacturers will show you. Their tests are usually run on some extremely biased systems in extremely particular situations you wont have in an actual game. You will never reach the theorical limit of your card. This is a bit like the speeds the makers of sport cars will claim...

Games like Half-Life and Quake 2 used lots of calls to glVertex when rendering maps... Some of what you hear just doesn''t apply when making an actual game engine. Half-Life apparently does alot of tesselation for its light maps, this results in very bad framerates considering the actual polygon counts in some maps, yet it still has a decent level of detail, and at its time, it was very playable in single player.

Unless you''re making a demo and trying to impress everyone with amazing amounts of polygons, you should just do your best to design thigns well. You can compare your game to other games of this time: How fast is your game compared to games that implement similar features? The most important is: Are you satisfied with the performance of your games?



Looking for a serious game project?
www.xgameproject.com

Share this post


Link to post
Share on other sites
Your performance is good for your hardware. I have a geforce2mx as well and I get about 70fps with my engine. Frustum culling will help your performance a lot.

My advice is to add all the features you want (Lighting, Texturing, Space partioning + culling, Level of detail, etc..) and THEN optimize. If I were you I would only use VBO''s to render your level, especially since its static geometry. The ARB vbo extension is available on pretty much all hardware and *should* run fast on all vendors.

But keep in mind that real-time lighting on such hardware will be very hard to accomplish, especially when you process thousands of vertexes.

"Premature optimization is the root of all evil", you will hear that a lot, and it can be true

Share this post


Link to post
Share on other sites
ya, but it would be great to have a page where we could check out "benchmarks" for what out engine should be spiting out.

Something with the following data:
- Gfx Card (GForce 2 GTS 64)
- Frames p/Sec (50)
- Processor (P3-1ghz)
- AGP (x2/x4/x8) (4x)
- Unlit/Untextured (100k)
- Lit (55k)
- Textured (35k)
- Lit and Textured (22k)

Weel, something along the example i gave. Then we could see if our engine is lagging behind for some reason, and implement more optimization techniques (frustrum culling, BSPs, etc...).


[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
Stop reading my signature and click it!

Share this post


Link to post
Share on other sites
i wouldnt think of frustum culling as optimization and it wont increase your triangle/s ratio anyway. its one of those absolutely basic things you always do.

and what would those statistics help? i would see that my engine is slower on lit geometry and it wouldnt help a thing, because complicated lighting fragment programs cant be compared to crude opengl vertex lighting. if i use 4 textures and a complicated way to combine them for the end result it will be slower than someone just adding one plain texture, someone using complex vertex programs will push less geometry than someone else, a program drawing huge sets of static date will push more than someone who can only render in small batches.

they would have to write at least 2 pages about what and how their engine is doing just for those numbers to make sense.

Share this post


Link to post
Share on other sites
quote:
Weel, something along the example i gave. Then we could see if our engine is lagging behind for some reason, and implement more optimization techniques (frustrum culling, BSPs, etc...).


quote:
i wouldnt think of frustum culling as optimization and it wont increase your triangle/s ratio anyway. its one of those absolutely basic things you always do.


Actually, frustum culling of the world usually makes use of the space partition you are using, wether its BSP or any other form of tree. You can also implement other techniques with the space partition, like PVS, but frustum culling is a must, there is no reason to render what can't possibly be seen... And in some scenes its hard to count on PVS...

I would tend to agree that those statistics would be useless. Unless everybody implements exactly the same things in the engines they benchmark.



Looking for a serious game project?
www.xgameproject.com

[edited by - Max_Payne on November 18, 2003 1:47:27 PM]

Share this post


Link to post
Share on other sites