I have added a terrain to my scene. But now when i go near the objects that use from the blending, i see a decreas in the frame rate–from 85 FPS to 40 FPS.Before i add this terrain, i had no problem with blending. What’s the problem?
-Ehsan-
Is it 42.5 FPS?
In other words: maybe your terrain requires a lot of heavy lifting, which means your render loop no longer finishes in the amount of time it has to get 85FPS. If you’re using vsync, and your monitor refresh rate is 85Hz, that would make your FPS go from 85 to 42.5, since only half of the monitor refreshes can be used to swap the buffers.
Of course, if it’s really 40FPS, the impact of rendering that terrain is even worse.
You may have to think about how you can speed up your terrain rendering. And that depends on how you do it now:
If you are rendering direct-mode, try a vertex array (maybe even with VBOs) or a display list.
If you’re already doing that, you’re probably sending a very large number of triangles. And that means you’ll have to go for something like geomipmapping.
Yes. you’r correct.I have used from the display lists. but i should use from the vertex arrays. i’ll try that and i hope that it solves my problem.
thanks
-Ehsan-
But now when i go near the objects that use from the blending, i see a decreas in the frame rate
in general, per pixel blending operations will kill your fill/frame rate. the nearer you are to your blended objects, the more screen real estate they occupy, hence the added fill demand.
If the geometry is static, display lists are the simplest fastest option.
Do you disable blending when you’re not using it to blend (z.b. opaque objects?)
If the geometry is static, display lists are the simplest fastest option.
personally i think vbos are very simple to use and extremely efficient, especially for terrains (indexed triangle meshes). later when you explore level of detail i think you’ll find display lists to be quite unwieldy. i admit however that i’ve never used them. should i for anything other than a mac?
VBOs are efficient and neato but not the easiest things in the world to do, plus you need to depend on that extension being there. Nowadays you can guess and hope that it will be there but keep in mind it might not. Display lists, on the other hand, are part of the core OpenGL specification. And using them is absolutely simple.
Even if you are implementing levels of detail, you could use display lists. If your world is large and you store your geography in “tiles” you could have your entire world geometry stored on disk at maximum detail and then at load time generate your other levels of detail, storing each one in a display list. Then at runtime, while rendering, use whatever algorithm you use (distance, whatever) to determine what LoD a given tile will have and then just call the respective display list. If you have n levels of detail (including the “actual” geometry, that is max detail), for every tile you’d just call:
Tile->ListBase=glGenLists(n);
And then when rendering, assuming “LevelOfDetail” is the value you decided to render a given tile with, where a higher value indicates a lower detail:
glCallList(Tile->ListBase+LevelOfDetail);
Of course as with any programming problem, there are many ways to do it, and you could use VBOs of course, but I just like display lists for static geometry.
Good points.
I don’t see the point in display lists for this particular application, for terrains.
What commands would you put into a display list for drawing terrain “tiles”?
The glPointer commands and their glClientState couterparts are executed immediately, so I presume you mean a bunch of glVertex commands.
I see your point about display lists and things that are basically static in nature, but I think (V)BOs are the future for OpenGL.
As for ease, it only takes 3 lines of code to create and initialize a VBO. What could be easier?
Hlz 
BTW, I think VBOs are core as of 1.5.
Hlz