speed: glRotatef vs. glMultMatrix
Author
Hi,
I'm writing a particle engine, and I'm going to be rendering a lot of billboard sprites.
In order to get the sprites oriented correctly, I'm going to have to rotate them to face the camera. Now, here is my question: Would it be faster to compute and save the rotation angles, and then call glRotatef once or twice per billboard, or should I compute the matrix once and call glMultMatrix every time? (I intend on using the same rotation for all sprites, because I don't think it would make a noticeable difference if I compute the billboarding separately for each little sprite.)
Would it work if I put the rotations in a display list? Would that be faster than calling the glWhatever? Or maybe I should put the rotation+render in a display list?
I'm a bit new to OpenGL, please help me figure out a fast way to do this.
Thanks everyone!
Displaylist data is static. Whatever the rotations end up behind when you compile them will be what they are everytime you call the list.
glrotatef
1) creates a rotation matrix
2) multiplies that matrix with the current active matrix.
so if you're calling it over and over with the same arguments(ie building the same rotation matrix every time) then you're wasting time. just remember what it's doing 1 and 2 and use that to determin if what you're planning to do is faster. I'd say if you're constantly using the same matrix, then just build it once and use glmulmatrix it has to be faster then glrotate. but if you're building different matrix's all the time then glrotate takes basically the same time for the above stated reasons and might even be more efficent.
Tim
1) creates a rotation matrix
2) multiplies that matrix with the current active matrix.
so if you're calling it over and over with the same arguments(ie building the same rotation matrix every time) then you're wasting time. just remember what it's doing 1 and 2 and use that to determin if what you're planning to do is faster. I'd say if you're constantly using the same matrix, then just build it once and use glmulmatrix it has to be faster then glrotate. but if you're building different matrix's all the time then glrotate takes basically the same time for the above stated reasons and might even be more efficent.
Tim
Author
Thanks for the replies!
I had a suspicion glRotatef would be doing something like that, but I thought maybe the graphics card had a way of computing and multiplying the matrix really fast, and that sending the matrix from the cpu to the graphics card would be slow.
I'm going to be using the same rotations for every frame. Basically, in each frame, I want to compute the rotations, and draw all of the sprites with the same rotation. Would it make sense to recompute a display list at each frame, call the display list for the hundreds of sprites, and then destroy the list?
Something I wonder about:
If your particles are meant to always be facing the screen, and they are little quads with a texture projected on them, why do you not just draw them as quads? translate to their position and draw them. Why rotate?
If your particles are meant to always be facing the screen, and they are little quads with a texture projected on them, why do you not just draw them as quads? translate to their position and draw them. Why rotate?
Quote:Original post by Code-RIf the quads are always meant to be facing the screen, simply translating to their location and drawing a quad is enough. There is nothing to rotate. They already face the screen.
the "facing the screen" part ;)
Quote:Original post by Vampyre_DarkQuote:Original post by Code-RIf the quads are always meant to be facing the screen, simply translating to their location and drawing a quad is enough. There is nothing to rotate. They already face the screen.
the "facing the screen" part ;)
That wouldn't quite work. Particles that are at the edges of the screen would look incorrect (due to perspective skew) - as they'd be facing in the direction of the -normal of the near plane, rather than towards the camera like it should be.
Quote:Original post by python_regious
That wouldn't quite work. Particles that are at the edges of the screen would look incorrect (due to perspective skew) - as they'd be facing in the direction of the -normal of the near plane, rather than towards the camera like it should be.
I draw all my particles using my above mentioned method and I've never encountered a problem, or even seen what you refer to. Even when they are right close to the camera. Got a pic so I can see the effect? [grin]
No pic sorry, I'm at work at the moment and my engine has been out of action for a while. I'll try to find one, though essentially you can see the particle from a more "edge" on perspective, rather than looking directly at it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
