View Full Version : How to use multitexture to draw a quad over the scene??
06-15-2005, 07:23 PM
How can I draw a quad over the scene with multitexturing? I read its faster than a non multitextured quad
I want simply to fade in a quad which is all black so I fade out the scene like that but when I put a quad close to the frustum the rendering speed goes so so damn slow!!!! why?!!?! I mean its a QUAD!! not 200.000 triangles!!
1. What do you want to use multitexturing for if you're rendering a fullscreen quad? Do texture "layers" have to move relative to each other or something?
2. Are the textures' sizes powers of two? If not, you may get software fallback.
3. Are you rendering the quad with depth-test enabled?
4. Are you using an ortho projection with the quad? (Not that that has anything to do with rendering speed, but it makes it easier to position)
5. Are you re-uploading the textures every frame?
06-15-2005, 10:39 PM
1) I read in this forums that it would be faster if they had multitexture applied even if it was a black quad and that made me ask here why that would be true
2) of course
3) yes im using GL_LEQUAL maybe thats the problem?
4) im using gluPerspective do you recomend me other way? why?
5) of course not I wont load a texture in a loop thats stupid
06-15-2005, 11:25 PM
One of the reasons is that we clear the buffers-stencil, depth, etc- for more than one time.
06-16-2005, 12:05 AM
Excuse me but why do you need a texture ?
The quad does not need any, just being black, and changing the alpha over time, right ?
Doodlemunch, I did not imply you were stupid, in case you misunderstood.
It's not "stupid" to re-upload a texture every frame if it changes every frame, but it does come at a cost. There are better methods if you want to use wipes (one option is to precalculate the various wipe frames, another is to simply move a quad across the screen).
I think you must have misunderstood that rendering multitextured quads would be faster than rendering untextured quads.
The gains from multitexturing are in not having to send the same geometry multiple times. But if you render a single-color quad, that's not going to be any improvement.
The advantage of using glOrtho is that you can just draw a quad from one screen corner to another, and don't have to calculate any of the coordinates to compensate for the perspective.
Disabling the depth test has two advantages: framebuffer writes will be faster, and you don't have to worry about geometry poking through your quad. It also allows you to render the quad further away from the near clipping plane.
06-16-2005, 02:44 AM
well i just want to fade in a black quad so the screen fades out! im using gluperspective because i like it, does ortho look the same way? (the perspective I mean).
I just think its stupid loading in a loop when you can load and keep in memory if its an animstrip then just load it and go from frame to frame (moving the uv?) but anyway loading from hdd all the time seems stupid to me, because its slow!
Then again, I wasn't referring to loading, I was referring to uploading, i.e. calling one of the glTexImage functions. This also causes a performance penalty because data has to be moved from general purpose memory to the graphics card.
But I agree: that is a lot faster than loading from disk.
You can use different projections for different stuff.
Let's say you want to render three elements on screen:
1. The 3D scene
2. Some 2D overlays
3. A 2D GUI
You would use a perspective view for the first, and ortho views for the other 2. Typically you'd want them rendered in that order, with depthtest disabled for 2 and 3 because you just want them to be drawn over anything drawn before.
glMatrixMode(GL_MODELVIEW);Should do the trick of initialising the 2D projection and should place coordinates 0,0 at the top left the way it is with "normal" screen coordinates.
Just make sure you re-initialise the perspective projection when you're ready to send the 3D geometry.
06-16-2005, 05:41 AM
thanks ill give it a go
06-20-2005, 04:21 AM
When you draw something that covers the entire screen, regardless of how complex the geometry is, keep in mind that you are touching width*height fragments. At best you're just replacing their values, but with a fade you've got to read in the old value, do the blending and then store the new value.
If you have high res and a not-stellar video card, the old fillrate issue comes into play.
Powered by vBulletin® Version 4.2.2 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.