optimizing OpenGL

ghettotek
Unregistered
 
Post: #1
i was just wondering if there are any ways to perhaps make OpenGL apps run a little faster. i know i can turn off several of the OpenGL deals such as point, line, and polygon smoothing, and even play around with the depth and color bits in the pixel format, but are there any other optimizations i can make? thanks.
Quote this message in a reply
Member
Posts: 145
Joined: 2002.06
Post: #2
How you get the polygons to OpenGL has a big effect on the speed. Check my results here. Some other things that can improve speed include:
* disable GL_NORMALIZE and do object scaling yourself (you can still have OGL do rotation and transformation for you).
* avoid GL_LOGIC_OP if at all possible.
* if you don't need invariance* with blended polygons, disable GL_BLEND when drawing non-blending polygons rather than setting a non-blending blend func.
* replace stenciling with the alpha buffer (only on some cards, stenciling could be faster on others).
* use the least complex texture interpolation mode that looks good.
* for complex objects that are being statically lit, you can flatten the lighting into color information on the vertices for a significant speed improvement on older cards.

I'm not including the obvious ones like view frustum and visibility culling.

* see the red book, appendix H (page 681 in the third edition).

"He who breaks a thing to find out what it is, has left the path of wisdom."
- Gandalf the Gray-Hat

Bring Alistair Cooke's America to DVD!
Quote this message in a reply
ghettotek
Unregistered
 
Post: #3
what exactly is "frustum". i have it in my code, but its commented because i dont know what it is.
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #4
Quote:what exactly is "frustum". i have it in my code, but its commented because i dont know what it is.


Think of a pyramid with the apex at the camera and the base at your maximum view distance (far clip plane). Now take a slice out of the pyramid. That rectangle is your frustum. Basically, the frustum tells OpenGL the size of your rendering window and the view angle of the camera.

Does that make any sense?
Quote this message in a reply
ghettotek
Unregistered
 
Post: #5
it makes a little bit of sense. but what does it do? do i put it before my projection matrix, after, before the modelview matrix, after, etc? i tried all of them and it doesn't seem to do anything. what does glFrustum have to do with culling?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
Actually, the whole square-pyramid-with-top-sliced-off-parallel-to-the-bottom is called a frustum.

glFrustum doesn't have anything to do with culling, only with setting up the view frustum. Usually gluPerspective is more useful.

Frustum culling is where you manually check whether an object you're about to draw lies within the frustum (and hence is visible); and only draw it if it does. OpenGL is very fast at culling individual triangles, but if you can avoid drawing a few hundred at once, it's usually a good deal Smile
Quote this message in a reply
ghettotek
Unregistered
 
Post: #7
i thought OpenGL automatically culled objects that arent in the view? i mustve been mistaken. anyway, how does one go about culling using frustum? i was originally culling by just getting the distance between the object and the camera, and not drawing the object if its not within a certain range. im sure id get a huge boost of speed if i could cull objects using the frustum. thanks for your help.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
Quote:i thought OpenGL automatically culled objects that arent in the view?

It does.

Quote:how does one go about culling using frustum

http://www.google.com/search?q=frustum+c...8&oe=UTF-8
Quote this message in a reply
ghettotek
Unregistered
 
Post: #9
then whats the point of frustum culling if all objects out of view are already culled?
Quote this message in a reply
henryj
Unregistered
 
Post: #10
The key to fast openGL is to keep the gpu (the graphics card) and the cpu as busy as possible. You have to make sure that each processor is doing what it does best and you have to minimse stalls as much as possible.

As OSC said about the frustum. Don't bother testing individual triangles because the gpu is good at that, but if you can easily cull 100,000 triangles on the cpu then do it.

Part of minimising stalls is getting the info from the cpu to the gpu as fast as possible and vice versa. This involves using the best formats for your data and an understanding of the carnage that can be caused by seemingly innocent gl calls. eg. sending a polygon to the gpu with blending enabled can cause serialisation of the gl pipeline because all pending operations on the fragments covered by that polygon have to complete to get the colour to be blended.
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #11
You could send all your triangles to OpenGL - and OpenGL will cull and only render the ones in your view frustum. While OpenGL is very fast - often you can be faster - because you know things about how your scene is set up that OpenGL doesnt.

Lets say you are writing a space fighter game. You have spaceships that have 10,000 polygons. In addition to each spaceship geometry you keep some simple bounding volume - like a sphere or a box. This is useful in many ways. Lets say you now want to know if Spaceship A has collided with Spaceship B. Do you test all 10,000 triangles of A against all the triangles of B to see if they collide? Not likely. First you test to see if the bounding sphere of A intersects the bounding sphere of B. If they havent then no collision is possible since each sphere completely encloses the model geometry. If the spheres collide then (maybe) you do a more accurate test.

So bounding volumes are useful - but what does this have to do with view frustums? Well you can do an extremely fast test to see if a sphere is excluded from a frustum. So if you test your spaceship's model's bounding sphere against the view frustum and find that it doesnt intersect then you dont have to send it to OpenGL. If you did send it - OpenGL would end up excluding it anyway - but only after testing each one of the 10,000 triangles individually. So by utilizing your 'higher knowledge' about how your scene graph is organized you can make some key optimizations that the graphics card is unable to.

hth,
Codemattic
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #12
Not only culling objects outside your view frustum - but culling objects that are obscured. If you are writing an indoor game - you could use portals or BSP or Octrees or some type of space partitioning scheme so you can discount large parts of your geometry quickly and concentrate on only that parts that have a chanec at being rendered.

Only sending to OpenGL the triangles that are in your view frustum is one thing you can do to speed up your animation. But also - *how* you send those triangles to OpenGL is another. Using trangle fans and strips - as opposed to sending each one seperate will speed things up. Using compiled display lists can also greatly speed your animation up.

Using models with multiple LOD (or real-time LOD) can be used so that you draw a model with fewer triangles when its farther away. Or even billboarding a model when its far enough away - like if you have a forest - maybe the trees past a certain point are rendered by billboards where in the forground they are actual tree models.

hth,
Codemattic
Quote this message in a reply
ghettotek
Unregistered
 
Post: #13
great idea codemattic. sounds like the whole real-time LOD could really speed things up. im not sure what portals, BSP or Octrees are, but i think they may be the same as my system of "sectors". anyway, im still confused with the frustum thing. how would i go about actually getting values from the frustum to test against objects in my scene? or does it not work like that? thanks.
Quote this message in a reply
ghettotek
Unregistered
 
Post: #14
nevermind, i finally found a frustum culling tutorial that actually makes sense to me. thanks for all your help, i really appreciate it.
Quote this message in a reply
henryj
Unregistered
 
Post: #15
Quote:sounds like the whole real-time LOD could really speed things up.


As per my previous post, dynamic LOD will only speed things up if you can process your meshes quicker on the cpu than you can on the gpu. This isn't easy.

From a pure geometry standpoint, it is usually cheaper to send 100,000 triangles to the gpu than try and decimate the mesh down to 10,000 triangles.

LOD also means you need to know a LOT more about how your whole system works because you can get into problems with cache coherency, memory bandwith etc that are very hard to fix.

Modern gpus can pump huge numbers of polygons so triangle throughput is rarely a problem these days. Where most apps stall is either getting the data to the card or fillrate.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Optimizing CGLFlushDrawable Nick 3 3,869 Nov 27, 2006 06:48 PM
Last Post: OneSadCookie
  Optimizing rendering. jorgemonti 15 5,861 Apr 6, 2005 04:05 AM
Last Post: jorgemonti
  Optimizing for OpenGL on OS X aaronsullivan 3 3,452 Mar 22, 2005 02:36 PM
Last Post: Puzzler183
  Optimizing Terrain Drawing? Blake 10 4,471 Jan 25, 2004 03:44 PM
Last Post: Blake
  optimizing dynamic geometry arekkusu 15 7,188 Nov 27, 2003 12:29 PM
Last Post: OneSadCookie