pixmaps, glRasterPos, and rotation....help please

OpenGL OpenGL: Advanced Coding
1

Hi…I am having a little problem with the implementation of rotating a pixmap rendered to the screen using glRasterPos3d().

I am using the FTGL font library, which uses FreeType font libary, to make fonts within my program. The type of fonts that I am currently having trouble with are Pixmap fonts. I chose to use pixmap fonts because they looked the best for the application that I am doing. I have created the font with no problems and can even render it fine. At first I tried to use glTranslatef() to move the font to the position that I wanted but found that this didn’t seem to work very well, at least the way that I was doing it. So I then started to use glRasterPos3d() to place my font and this works great. The font renders right where I want it to. It appears to me that the pixmap font is automatically billboarded to the camera, which is perfect. But what I am wanting to do is to render the font to the screen with it rotated and still facing the camera. I believe that this would be rotating it around the Z axis, the axis that goes into and out of the screen. I am just using glPushMatrix() before my drawing code.

I have seen some mention of glPushAttrib()/glPopAttrib() but I am not sure of their real purpose and if they would help me in this situation. Does anyone have any suggestions on how I can rotate my pixmap?

I thank you in advance for any help you can give.

2

I don’t know the library, but if you can set the position with glRasterPos it is either using glBitmap or glDrawPixels to draw the font. Both are always pixel aligned and can not be rotated.
You need to use a font texture and render textured quads to be able to rotate the letters freely (and with texture filtering you get antialiased fonts, too).
Search the forum, this had been discussed before and I bet there are links with libs doing this.

3

Ahh thanks Relic. I was afraid it was something like that. :slight_smile:

4

Just for completeness:

Originally posted by Rectless:
At first I tried to use glTranslatef() to move the font to the position that I wanted but found that this didn’t seem to work very well, at least the way that I was doing it. So I then started to use glRasterPos3d() to place my font and this works great.
That’s because glRasterPos transforms the coords you supply by the current (at the time of the call) modelview and projection matrices. It’s the same as what happens to vertices. In fact the raster position will even go through a vertex program, if you have that enabled.

If you want to translate pixel transfers by using the matrix functions, you must call glRasterPos anyway, and you must call it after glTranslate.

5

Originally posted by zeckensack:
If you want to translate pixel transfers by using the matrix functions, you must call glRasterPos anyway, and you must call it after glTranslate.
So what you are saying here is that if I wanted to do a translation of the pixmap I would have to first do a glRasterPos call, like glRasterPos2d(0,0), which I believe would render the pixmap in the lower left corner and then I could do a translate of the pixmap to another location by doing a glTranslate call, like glTranslatef(50,50,0). This would then move the pixmap to the location of 50,50,0…is that correct?

6

[quote]Originally posted by Rectless:
[b]

glLoadIdentity();
glBegin(GL_TRIANGLE);
  glVertex3f(...);
  glVertex3f(...);
  glVertex3f(...);
glEnd();

glTranslatef(0.5f,0.5f,0.0f);

Same thing. The translation doesn’t affect the triangle, because it has (conceptually at least) already been transformed.

glBitmap and glDrawPixels (which are in all likelihood what’s used by those pixmap fonts of yours) will use the already transformed(!) current raster position. They will themselves in no way be affected by matrices (or any other vertex processing state). Only RasterPos cares about that. Thus modifications to vertex processing state in between glRasterPos and glBitmap/glDrawPixels are irrelevant*.

*deliberate over-simplification. Of course the matrix will be modified, but this modification will not in retrospect affect the earlier RasterPos call, and it will not affect glBitmap/glDrawPixels calls that are made later. I may be stating the obvious here, but it does of course affect geometry (vertices) and RasterPos calls made later.

**or one of its younger friends as defined in the ARB_window_pos extension.

7

Thanks zecknsack…that makes sense.