How to render 3D model faster?

I'd mess around with my hardware's 3D settings, and turn off a bunch of stuff (eg: performance, not quality) and see if that helps at all.

If it doesn't, then maybe you should update your graphics drivers because I don't think I've seen such drastic framerate differences between textured and non-textured.

Also, how are you loading your texture? What size is it? etc.

start using VBO's and you get a majot boost in rendering speed, and now im refering to VBO on the GPU wich you can achieve through extensions or opengl 2.0.

http://www.ozone3d.net/tutorials/opengl_vbo.php should get you started

Stefan

Thanks for the reply. I found this happens just after I update my ATI graphic cards driver to the latest version. I do this update because I found my old driver has very bad support of point sprite (if I use point sprite after calls to glEnd(), the point sprite wont show.I dont have this problem with the latest drive).
I store the texture with the following setting:
glPixelStorei(GL_UNPACK_ALIGNMENT, 1 );
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
The texture itself is about 400KB.
I will try to use VBO to see if my situation gets better.

Just for information (and maybe a little Off Topic) - frames per second (fps) is not a good way to inform about performance - visit this page http://www.humus.name/ - and look into article performance to see that difference between 1200 fps and 130 fps isn't so huge (though it is not no-difference).

are you using mip-maps? its maybe just because of the amount of texture data you are sending to the GPU.

Quote:

Original post by Veslefrikk start using VBO's and you get a majot boost in rendering speed, and now im refering to VBO on the GPU wich you can achieve through extensions or opengl 2.0. http://www.ozone3d.net/tutorials/opengl_vbo.php should get you started Stefan

He is getting 1200 FPS so using VBOs won't be faster.

[Edited by - V-man on August 2, 2009 7:17:45 AM]

Try using mipmaps. Even modern graphics cards can be surprisingly slow on minimized textures if mipmapping is not used. (The underlying reason is that not using mipmapping kills texture access locality and therefore kills texture caches.)

And apart from that, I agree that when you're in the 1200 fps range, that number usually doesn't mean anything.

Thank you for eyeryone's reply. After switch to VBO, the rendering speed boost :)
Now, by using GL_STATIC_DRAW my FPS is around 1100 with texture enabled. But I still dont know why display list runs so slow on my computer.

I don't want a new topic on this, so:
Is VBO faster than display lists, or it is platform dependent?
I could try it for myself of course, but that would be a lot of work, thanks!

Quote:

Original post by kkjohn But I still dont know why display list runs so slow on my computer.

Display lists are an ancient and deprecated technology - they aren't expected to be a performance path on modern cards.

Display lists (DLs) were faster than VBOs on older GPUs. Many years ago, I had carried out many experiments with VAs, VBOs and DLs. And DLs always gained tremendous speed boost compared to other techniques! Further more, VBOs behaved strangely on different platforms (drivers). Sometimes they worked slowly as VAs, sometimes almost reached DLs speed.

I think the problem with VBOs were in drivers. There were no propositions how to implement them, and parameters were just hints how to manipulate data. For example, paramether "usage" in glBufferData() function call:

void glBufferData(GLenum target, GLsizeiptr size, const GLvoid *data, GLenum usage);

did not oblige driver to store data as it was specified. Whatever, DL must be faster than VBO. But problem with DL is that it stores transformations along with data. DL cannot be modified, just destroyed and created again. And so on...

And for the end, DLs are part of deprecated functionality. If you switch to new shader based functionality, there is no place for DLs, unfortunately.

Quote:

Original post by kkjohn Thank you for eyeryone's reply. After switch to VBO, the rendering speed boost :) Now, by using GL_STATIC_DRAW my FPS is around 1100 with texture enabled. But I still dont know why display list runs so slow on my computer.

You have an ATI video card, ATI's opengl drivers have always been somewhat .. lacking .. and that's especially true for display lists.

>>Display lists (DLs) were faster than VBOs on older GPUs.

I think the case is still true today, one of the top guys at nvidia recently said DL's are the fastest method of drawing static geometry, so if youre using DL + u cjhange over to VBOs dont be surprised if u see no performance gain.

whilst its a moot point today its not so much of an issue as it was years ago, todays cards can handle many millions verts per sec (even billions).
Personally I use VBOs for the sake of uniformity (i.e. static + moving geometry are treated the same)

Quote:

Original post by zedz I think the case is still true today, one of the top guys at nvidia recently said DL's are the fastest method of drawing static geometry, so if youre using DL + u cjhange over to VBOs dont be surprised if u see no performance gain.

I guess the beast is hard to optimize.

Quote:

Original post by zedz >>Display lists (DLs) were faster than VBOs on older GPUs. I think the case is still true today, one of the top guys at nvidia recently said DL's are the fastest method of drawing static geometry, so if youre using DL + u cjhange over to VBOs dont be surprised if u see no performance gain.

I am fairly sure that the NVidia quote aplies only to perfectly formed display lists, where all vertices are specified with matching components (i.e. color and normal must be specified for every vertex if they are specified for even one vertex). I imagine the display list compilation phase basically produces indexed triangle lists from this data, and sticks it in an internally-managed VBO.

However, regardless of display list performance on NVidia, they don't perform well on ATI, so better to move on.