Jump to content
  • Advertisement
Sign in to follow this  
Halma

OpenGL speed: glRotatef vs. glMultMatrix

This topic is 4760 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, 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!

Share this post


Link to post
Share on other sites
Advertisement
Displaylist data is static. Whatever the rotations end up behind when you compile them will be what they are everytime you call the list.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Quote:
Original post by Code-R
the "facing the screen" part ;)
If 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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Vampyre_Dark
Quote:
Original post by Code-R
the "facing the screen" part ;)
If 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.


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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!