cool subject: tips to how to accelerate a own opengl engine

how i can accelerate my engine…
what can i do?
write everythink you know guys
here is my (hope you can add this):

  • frustum culling to render only objects in screen
  • backface culling on objects who it doesn’t matter!
  • use vertex arrays for fast rendering
  • render objects in order of thier textures…so you didnt need glBindTexture every time
  • use low poly modells and very good textures on it (the last thing if your’e engine begin to die)

have nobody any other ideas how to speed up a engine?
common guys!
wanna see results

Maybe your list is too comprehensive

  • Niko

Depends heavily on what you want your engine to do. If it’s a landscape engine, you could look at ROAM/LOD although it’s not as popular as it once was. If it’s an indoor engine look at BSP’s or PVS’s. You could also look at octrees. What you should probably do is build a prototype engine, then find out where the bottlenecks are in your engine and optimise those away, rather than trying to build everything into your engine from the start. Like I said, it depends on what you want to do …

<edit>As niko said, you already have lots of good ideas anyway. Be careful with the backface culling. If you do it per triangle, it could be very expensive. It may be best to let the card handle it.</edit>

Hope that helps.

[This message has been edited by ffish (edited 08-29-2001).]

i only want to give general tips…
but for special tips LOD is right

Here’s some more - use display lists for static geometry for all cards, use VAR for nVidia cards for dynamic geometry/maybe static too, sort polys front to back to reduce overdraw. Look for a (slightly old) performance FAQ on nVidia’s site. I don’t know if ATI has one too - check their site. nVidia’s general guidelines should apply to all cards.

Hope that helps.

One more thing comes to mind:

Render objects front to back. It makes the most use of the Z-buffer (at least for reasonably intelligent cards).

cool, thanks for these tips…
i’ve some new:

  • use vertex array fence (NV ext.)
  • generally use ext. to get objects fast rendered!

Extensions are a good and bad thing. I couldn’t get my thesis done without them (thanks, nVidia!) but in my case it doesn’t matter whether I tie my implementation to one particular architecture.

If you also don’t care whether your engine only runs on your nVidia hardware, then use GL_NV extensions. If you want to design your engine for a lower baseline, or even older hardware, you will have to be very careful which extensions you use and maybe have alternate code paths for people without the extensions.

Hope that helps.

progressive mesh and occlusion culling may speedup your engine


@ffsish: yes, you’re right…but some NV-Extensions you can use too on none - NVidia Cards (like vertex arrays, which are standard in opengl now)

@rapso: cool…
i will try this…
but at first i have to search at google what occlusion culling does exactly

Originally posted by MofuX:
@ffsish: yes, you’re right…but some NV-Extensions you can use too on none - NVidia Cards (like vertex arrays, which are standard in opengl now)

MofuX, I think you are mistaking nVIDIA Vertex Array Range (VAR) for OpenGL Compiled Vertex Arrays (CVA).

They are quite different and nVIDIA extensions GL_NV_vertex_array_range/ GL_NV_fence are not part of the “standard” OpenGL.



Originally posted by MofuX:
… but at first i have to search at google what occlusion culling does exactly

With occlusion culling, you will use something like BSP/PVS/Octrees to cull objects at a higher level depending on whether they are visible or not. There is a balancing act in trading off culling polygons sent to your card versus overhead in determining which polygons to cull. In its best form, occlusion culling techniques can really optimise your engine but usually only if your engine is geometry limited i.e. occlusion culling will work best if you have lots of polygons spread out well in depth. It probably won’t do much (or even slow the engine down) if you have a relatively flat landscape, like a planet, where you have lots of polys, most of them visible. In that case, you’d be looking at ROAM/Progressive Mesh/LOD type algorithms. That’s what I meant earlier when I said you should determine what type of engine you want.

Hope that helps.

hey… thanks for your replies…
i dont mistakes nv extension vertex array range and the normal vertex arrays which are includet in opengl (since v1.1 i think)
…thanks ffish for your replies…helps me a lot…