View Full Version : Big frame drop with one more poly !!!
08-20-2002, 07:29 AM
I face a strange slowdown (70 fps down to 50 fps) when I add a single big polygon (GL_QUADS) just in front of the camera, thus "covering" the whole scene.
Please note I've disabled depth testing, lighting and blending as I draw this poly.This poly is GL_LINEAR/GL_NEAREST textured ...
Do you have any idea about how to avoid this frame drop ?
08-20-2002, 07:38 AM
don't draw the rest of the scene when the big quad is displayed
[This message has been edited by coredump (edited 08-20-2002).]
08-20-2002, 07:51 AM
Yes, It would no longer frame drop.
Nevertheless, the point is that I must draw this poly with blending turned on (I want to make an aircraft head up display), so the scene must be drawn too.
My question is : Why does this frame drop occur ? Is it the size of the drawn poly that matters ?
08-20-2002, 07:56 AM
you are hitting your card's fillrate limit, it can only rasterize so many pixels independant of how much geometry it calculates, thus having to fill the entire screen with pixels twice is causing a slowdown
08-20-2002, 08:00 AM
Depending on your screen resolution and graphics card, that might cause a fill-rate problem. Reduce the size of the poly to relatively small and check the fps - should be higher if your problem is fill-rate.
Ideally, you should use the stencil buffer for this kind of thing - to reduce overdraw (stencil test is generally free) and, depending on your head-up display config (usually, its based on lines with numbers), use several small polygons rather than one huge one.
You might be able to improve performance by using the alpha test instead of blending ( if you are rendering a HUD, this should work fine ).
08-20-2002, 08:38 AM
Is such a slowdown on a PIII 500, Creative GeForce 1 DDR 32 Mo, relatively normal ?
If I understood fill rate limitation well, If I subdivided my big QUAD into, let's say, 6 smaller quads, it would be quicker. So this slowdown is merely due to fill rate limitation. Am I wrong ? Do the latest video boards perform better with this stuff ? How much ? In fact, when I see some video boards technical specs, fill rate is rarely(if not) mentioned...
Thanks a lot.
Yes, 6 smaller quads would be better ( unless they still cover the entire screen ).
08-20-2002, 08:46 AM
if you draw 6 quads wich fill the same area than the one big quad, you don't get any speed boost, as you draw the _SAME_AMOUNT_OF_PIXELS_
and yes, for a gf1 its quite normal (cpu doesn't mather, just the amount of pixels count for fillrate, and you have a maxamount of pixels at 50fps for example, and you get that max..)
a) lower the resolution of the screen
b) use alphatesting to drop completely transparent pixels instead of letting them got blend (blending is quite slow, lots of framebuffer accesses per pixel)
c) don't fill the whole screen, but cut out the visible parts of your hud, only draw there some polygons, and let the rest open, don't draw there at all.. that saves the most..
d) do a polygonal mesh as cocpit, looks the best anyways.. (and there, your mesh normally has windows, wich you don't have to draw, as you want to see through)
08-20-2002, 10:28 AM
It sounds clearer with you... But one thing remains : the field of view is totaly drawn, and when I add a single polygon, there is not at least one more pixel drawn : the AMOUNT_OF_PIXELS drawn remains constant ... Does this amount of pixel correspond to the total number of pixels drawn foreach polygon, or to the corresponding resolution pixel number, i.e. 800 * 600 = 480 000pixels ? My point is that with or without the big polygon, the amount of pixels drawn is 480000.
Thanks for your answers.
Jeffry J Brickley
08-20-2002, 11:37 AM
Okay think of it this way, your screen is 800x600 and the associated number of pixels therein (either 16bit or 32bit). But you are doing two paint jobs on the screen. A) drawing the background scene with all the 3D terrain, etc and then B) painting over it with the HUD. Now you may only "see" a portion of that HUD, but OpenGL and your card has to "test" every one of those pixels for your HUD that has already been drawn once and decide if it wants to draw over it again.
Your choices are:
A) get a faster painter (why do you think those power rollers on commercials sell so well?) or in other words get a faster card. Generally this is considered overkill, because you are doing more work than you need to.
B) use stencil operations, a little more work to set up the stencil test, but it is more daunting to look at than to really do and works great.
C) use smaller squares. this does not mean to just divide up the screen into 9 parts of the same area and fill it again, that is still painting the screen twice. BUT, imagine putting transparent tape on the screen where you want your HUD. A square in the middle of the screen (not all of it) with just the pitch/roll ladder (if you are doing an aircraft HUD), a small strip on the side for altimeter, etc. Then you are only testing the "useable" area of your HUD, reducing probably 60% or more of the work of drawing twice. This is less efficient than stenciling, but very modular and easy to code, and if you keep the sizes down reasonably fast. Treat every HUD object as an individual paint task ONLY in it's small portion of the screen, not the whole screen.
I've done HUD's both ways, and on a decent graphics card and with some effort to minimize overlap, you can get an alpha-test HUD at near the speed of a stencil test; though in reality the coding work evens out either direction.
08-20-2002, 11:56 AM
Thanks a lot Jeffry http://www.opengl.org/discussion_boards/ubb/smile.gif .
08-20-2002, 12:10 PM
Why are you drawing the HUD as a textured quad?
Huds require high quality vector graphics and this can be done by drawing directly over the scene either in 3D or with an orthographic projection.
Doing this will tend to require geometry but much less fill performance than your full screen texture. If you need some eye candy modulation of the scene beyond the HUD sonsider an outline that writes the minimum number of pixels and cookie cut your polygons to cover only non transparent portions of the region being filled.
Jeffry J Brickley
08-20-2002, 12:22 PM
Dorbie is correct, I forget that I am an oddball and just assumed you were doing something like my system. In most cases vector graphics or geometry pieces are better for most HUDs. I use photo-textures and hand-alpha convert them so that our HUDs are extremly high resulolution, but most people don't need that. My moving parts are still mostly geometry and you could get away with everything being geometry if you planned it out.
I don't supposed you have a screen shot to let us know what kind of effect you are trying to achieve? it would make it easier in telling you the why's and the how's.
08-20-2002, 02:04 PM
btw, RCMaster, its called OVERDRAW.. that means you can draw several times over one pixel.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif
if you don't want to have overdraw, you would need to raytrace, but oh well, thats another topic http://www.opengl.org/discussion_boards/ubb/biggrin.gif..
rastericer just draw, draw 1000 triangles over each other and you will have drawn 1000x that much pixels.. and fillrate is very low on older hw (its doubling all half year, so think about how much faster you _could_ draw just the pixels http://www.opengl.org/discussion_boards/ubb/biggrin.gif)
08-20-2002, 04:50 PM
Yes, I do have one screenshot :
Features of this HUD :
- heading (top) is a textured quad
- artificial horizon is GL_LINES based
- fonts are small textured quads
- the "glass" effect is merely made of GL_TRIANGLE_STRIP
As soon as I disable the "glass" effect, woof 30 fps boost http://www.opengl.org/discussion_boards/ubb/eek.gif !
Any comments about all this ?
08-20-2002, 08:13 PM
Comment: Your big blended triangle strip causes lots of overdraw and slows down your frame rate. Sound familiar? :-)
Also, I prefer to draw text using GDI and upload a bitmap of the text as a texture, rather than piecing together a word of itty-bitty little quads. GDI does much nicer kerning than I ever could.
On the subject of zero overdraw: With a fully split BSP tree, you can render your BSP geometry with zero overdraw. You don't even need a depth buffer! If you want to add meshes, you'd probably want a depth buffer, though. And who splits their geometry these days?
[This message has been edited by jwatte (edited 08-20-2002).]
jwatte, have you tried the freetype library ? This is quite good ( antialias, kerning, etc ) and it lets you use itty-bitty little quads http://www.opengl.org/discussion_boards/ubb/smile.gif.
08-21-2002, 05:51 AM
Unfortunately, I don't think freetype supports unicode does it? So that might be an issue for some (like mois).
Freetype2 supports unicode but I haven't used that. A lot of Quake3 engine games have used freetype for fonts ( I don't know if it's used at runtime or as a pre-processing step to create texture maps ). Medal of Honor is a good example ( look at a wireframe shot to see how the quads are placed base on the font properties ). The fonts that I have used, have no kerning but it does allow you to extract this infomation.
Jeffry J Brickley
08-21-2002, 11:24 AM
Okay, the glass effect that you are trying to achieve, have you considered brightening the overall light within the scene to equivalent of the "glass area" and then darken the borders instead of the main area. By reversing the logic, you'll have about 70% less overdraw (just an eyeball estimate, don't take it as law). So you would sample the outside of glass area and dim it with transparency rather than brightening the center. The effect is near the same, but less work for the card. Just my two cents worth.
Powered by vBulletin® Version 4.2.2 Copyright © 2015 vBulletin Solutions, Inc. All rights reserved.