Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

valterc

OpenGL opengl performance (display lists and multitexturing)

This topic is 5157 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone, I just have a question... I''m displaying a rather big mesh (~500000 vertices) on a Radeon 9500 using triangle strips, the mesh could be just lighted, textured or multi textured (for detailing). I got the following fps: with display list: notex 122 tex 90 detail 3 (!!!) without display list: notex 3.6 tex 3.6 detail 3 ok, the question is: is it normal? that difference of rendering speed between DL or no DL and between simple texturing an multi texturing? hope that someone could give me an answer... bye.

Share this post


Link to post
Share on other sites
Advertisement
yes, this is normal, in case you used display listed glvertex3f vs. immidiate mode glVertex3f...

with multitexturing things are slower beacause you have to do the texture calculations multiple times..

what is `detail''?

Share this post


Link to post
Share on other sites
"notex" is just lighted polygons (one infinite light source and normals)
"tex" is just one texture for the whole mesh (no extensions at all)
"detail" is multitexturing (using ARB extensions), two textures.

I also noticed that the slow down between tex and detail is due to
a call to (*glMultiTexCoord2fARB)(GL_TEXTURE1_ARB, u, v). I mean, with this call everything will slow down (from 90 to 3fps!!!) even if I don''t actually draw the second textures...

This sounds pretty strange to me...

Do you think things will go better with vertex arrys?

Share this post


Link to post
Share on other sites
I have a feeling it''s because glMultiTexCoord2fARB is a function pointer defined by you, and that somehow prevents OpenGL from storing the display list in VRAM. Effectively this makes the display list act (almost) exactly the same as immediate mode, thus the same bad performance. You should probably use VBO instead and fall back to vertex arrays if VBO is not supported.


Share this post


Link to post
Share on other sites
Ok, I will try using VBO (my hardware should support it).

Anyway, you''re probably right (thank you), but is it generally true
that I cannot use extensions inside display lists? I''m using glut so the only way (as I know) for using extensions is doing something like: include glext.h, check for availability and then

static PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB = NULL;

glMultiTexCoord2fARB = (void *) wglGetProcAddress("glMultiTexCoord2fARB");


Is there a better way to do that?
bye.

Share this post


Link to post
Share on other sites
the more i think about it, the more i dont think thats the problem.
A Display list doesnt compile the C function calls into a list, it saves a command buffer which is generated by calls into OpenGL, so the fact that you are calling an extension shouldnt matter at all as it will still setup an instruction/group of instruction in the command list when its created.

Granted this doesnt help you, but I dont think your problem is that its an extension...


[Phantom Web | OpenGL Window Framework ]
"i wonder why i do that... type words which are nuffin like the word i wanted every now and badger"

Share this post


Link to post
Share on other sites
I was able to track down the problem to a single issue...
I have the same bad performance if (without activating multitexturing at all) I duplicate the tex coord functions.

Which is: if I do, for every vertex
glTexCoord2f(u, v);
glTexCoord2f(u, v); /// I know... this is stupid...

I have the same (bad) perfomance as

glMultiTexCoord2fARB(GL_TEXTURE0_ARB, u, v);
if(tDrawMode == T_TEXDETAIL)
glMultiTexCoord2fARB(GL_TEXTURE1_ARB, u, v);

Remember that I''m inside a display list.
Ok, any hints about this?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!