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

Faster Transformations

This topic is 5893 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

Hullo. I''m trying to make a starfield populated with textured and blended quads. The stars get bigger when you''re close by, and the blending makes lots of stars together seem a lot brighter. Overall, the visual effect is pleasing, so I don''t want to change that. Although it looks good enough, it''s quite slow. On my K6/2-450Mhz w/Voodoo4, I can get around 1000 stars at a reasonable framerate. I haven''t measured it, but I''d guess it''s around 30. However, I''d _like_ more stars: 3000 or 5000. I can do that, quite zippily, if I forgo some of the transformations. Here''s a summary of what happens atm:
Translate the field away from the viewer.
Rotate the field.
For Each Star:
  Translate to The Star''s Position
  Rotate the star so that it''s facing the viwer
  Draw It.
The trouble is that the transformations in the loop slow everything down. I''m using three glRotatef calls for each iteration (and a glTranslatef), and it seems to me that there must be a way of converting three rotations around the canonical axes into one rotation around a different axis. If I don''t do the transformations, the stars don''t face towards the viewer: when the starfield is rotated 90 degrees you''re looking at the quads side on and the effect is not pleasing, to say the least. So I have to do the transformations in some form. I''ve tried without the matrix stack operations - just reversing the rotations and translations at the end of each iteration.
  Translate to The Star''s Position
  Rotate around x, y, z
  Draw It.
  Unrotate around z, y, z
It''s a little bit slower. If the six rotations can be condensed into two operations, that''d probably be better. It just occured to me that using the second method I could precalculate the translation from one star to the next, and thusly avoid the untranslate.
One solution I tried was creating a display list of the star field. The list was made just fine, but when I play it back, it ignores any rotations I''ve applied to the modelview matrix. Is that how display lists are meant to operate, or must I be doing something wrong? Just Plain Wrong

Share this post

Link to post
Share on other sites
Just out of interest, do you have a screen shot?

I'm doing a very similar thing, but using points rather than quads - 10,000 stars produce very exceptable framerates.

I'll probably use some textures for really bright stars, but I think the points look pretty nice.

Edited by - Shag on November 28, 2001 2:35:01 PM

Share this post

Link to post
Share on other sites
Original post by terminate
Also, try using 2 triangles instead of a quad.

Or maybe just one triangle...

No game will ever rule more than CBT!

Share this post

Link to post
Share on other sites
The problem with that method is that you are effectively combining a large number of transformations, accumulating numerical errors : rotating then ''unrotating'' will not return exactly to the same position.

That''s one of the reason why you get a stack of matrices.

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
optimize many same rotations across a dynamic particle system or how the heck do i get massive framerate with massive particle counts?

first off, never guess yoru framerate, add a real frame rate counter and get real numbers. At 320x240 in full software renderer optimized in MMX assembly i am able to get ~512 particles/second on a pentium II 266. When using single pixel particle (removes bandwidth overhead of drawing the particles) i can get 1000-2000 at 30 frames/second easy (mayeb more not sure since i have not tested it recently since i am concentrating on use hardware acceleration now)

tip #1: Realize that all the particles will face towards the same direction at all times (including at initialzation) which means they all rotate around the same axis at the same degree. You probally know this already, but did not think that you could use it to any advantage. precompute the rotation matrix and just apply this matrix to each star instead of using glrotate (which is very slow for things like this). in fcat try to precompute as much as the matrix as you can.

tip #2: Why transform vertices? Instead just deal with the centers and then create the stars form the center at render time (which should use a vertex array).

star center postion is already in world space (no need to rotate to face veiwer or translate evry frame to its position)
1. translate centers to camera space
2. rotate centers to camera space
(steps one and two should be a single matrix muliply)
(also only push at top of loop and pop at end of loop (unless that happens to break things))
3. now star centers are correctly positioned. create the quads for rendering (WARNING the stars must not be projected to screen space yet or things will get borked).
topLeft.x = starCenter-halfWidth;
topLeft.y = starCenter+halfHeight;
topRight.x = starCenter+halfWidth;
topRight.y = starCenter+halfHeight;
... etc;
4. star vertices can now be projected and then rendered. reducing overall rotations by half, and with precomputed matrices (precompute before entering the loop) you get even better results (less cos/sin calculations) you should then get 5000 particles easy.

beforewarned this has not been actually tested fully (as i am just starting on my hardware accelarated particle system), but should work quite well. The matrix precomputations for the rotations is a MUST though. NEVER rotate/unrotate as Fruny said. just leads to very small inaccuracies jittering your entire star system into chaos (unless that is what you want). Remeber function calls can kill if you call them 5 times per loop at 1000 times per frame.

Share this post

Link to post
Share on other sites