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).]
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.
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.
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.
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…