View Full Version : is this a decent framerate?
04-23-2001, 01:13 AM
I'm an OpenGL newbie and I was just wondering if the framerate of one of my demo's is acceptable. It's a field of piramids (used a display list), slowly rotating and moving towards the viewer. 2 static lights are used along with Sphere Environment Mapping (or something like that). The number of piramids is now set to 2025. With a resolution of 1024*768*32 I get an average of 30fps on my system (700MHz Thunderbird, 128Mb RAM, GeForce256SDR).
I just wanna know if this is good or not. Nothing is optimized yet (no HSR or other newbie-killing code).
--> OpenGL Projects
--> Piramids.zip (last project)
Warning http://www.opengl.org/discussion_boards/ubb/smile.gif website far from finished and projects may be buggy (don't press F1 when I use scissors http://www.opengl.org/discussion_boards/ubb/smile.gif
Thanks alot! Comments and suggestions are welcome!
If you want to increase the framerate,
I means: disable depth calculations in Init() and remove the 'GL_DEPTH_BUFFER_BIT' in glClear().
This will greatly inprove the framerate but will not calculate the depth, that is which polygons to be drawn first, you'll notice.
It is much faster to do your own depth calculation. You just need some vector and plane math. Do you want help on this?
04-23-2001, 11:40 PM
Thanks for the tip!
If you want to help me with these vectors and planes, I would really appreciate this! As far as I understand I really need to know everything about these vectors before I can do something like clipping? Or like not drawing faces which are behind other faces (HSR?). Any help is welcome!
I don't know how to avoid drawing triangles that are overlapped by other triangles, but I am working on it. That includes my depth calculations.
This might help: Imagine this:
If you draw a cube that has 6 polygons and the camera is looking at one cornor, so that 3 sides are visible, then the other 3 sides are not visible and does not have to be drawn.
Try to rotate your polygons along the y-axis to see what is happening. Then replace GL_BACK with GL_FRONT.
It is still faster to use planes and vectors to determine whether to draw triangles or not. See the Nate's tutorial on "particles example". You'll find the plane.h and vector.h.
04-24-2001, 03:03 AM
Terl, it's glDisable(GL_DEPTH_TEST);
Haven't looked ate the program though.
Try it without debugcode, because i get with debug-mode/code framerates 5 times slower than without !
04-24-2001, 09:54 AM
iīm not sure whether doing your own calculations is faster than the z-buffer. with a board like a geforce256, rendering is the last problem you have. the bottleneck usually is the CPU which has to do all the matrix multiplications and will slow you down if you use lots of vertices, thatīs why games always try to use few polygons. the depth (or Z) buffer is implemented in hardware and therefore dead fast, so your plane calculations (which will be done by the CPU) will probably slow down the whole thing more than just leaving everything to openGL. however, if someone can convince me of the opposite, do so.
04-24-2001, 03:57 PM
All geforce cards has hardware support for matrix calculations. I think that the framerate is decent but if you want to optimize should you look at the developer pages on the nvidia site. (VAR/fence,...)
04-25-2001, 01:09 AM
About the backface culling: I thought that every triangle had 2 faces, front and back, and that enabling backface culling only prevents drawing one of those two faces. In other words: drawing an open cylinder with backface culling turned on will look good, unless you look at the inside of the cylinder. You'll see that no faces will be drawn. The cube example has (I think) 12 triangles with 2 faces each, so 24 faces will be rendered without culling. As far as I know backface culling does not prevent the drawing of hidden triangles. I think that's called Hidden Surface Removal.
Please correct me if I'm wrong!
Thanks again for the help!
04-25-2001, 01:15 AM
T2K: what do you mean without debug code? These are release versions, as far as I know, and they run at the same speed as the debug versions. Debug version is about 5 times bigger, that's the only difference I can find.
i mean the compiled c++ code not opengl and the linked libs/dlls, if you have set your compiler to debugmode( not release)...
you really have problems with oGL.....
the best way to improve speed is to learn lots of things, tricks.....
that is just what i think......
04-25-2001, 02:36 PM
Please Magic Johnson, tell us any of that tricks!!!!!!!!!!
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.