We have an inhouse app that shows a 3d object’s dimensions, along each of the sides. We are using GLUT for text rendering.
When rendering to a window, this 3d text appears in the proper position, moving in front of the image and behind as the image is viewed from different angles.
When rendering to a bitmap, using exactly the same code, the text is always printed behind the mesh. The mesh will obscure the text where ever the two may intersect.
We are using the glutStrokeCharacter function to display the text.
Is there some workaround to this issue? I’ve tried rendering the text and meshes in two seperate bitmaps, to combine later, but then the text doesn’t even appear.
I am not sure if I understood you correctly, but you can try to draw text last in pipeline - just before SwapBuffers(). Also you should disable depth test before text draw, and enable it after (to have it ready for next frame pass, when you draw geometry again…).
…
You could also set ortho (glOrtho) projection for all “Hud” drawing… that way you will work with only 2D coordinates for text display. In addition to ortho you can use gluUnProject and gluProject to get screen positions of the 3D object in the scene…
where the problem occurs, isn’t happening in a real time app. We’re drawing an object to a bitmap, to send to a printer.
If it’s for instance, a cube, then there are 3 dimension lines like you’d see in a drafting design. On the same plane, offset from the object is the the text that tells us how many inches long that side is.
The text appears on top of mesh lines, and always under the shading.
In the windowed view, we can spin the object and the text spins with it, appearing and hiding exactly like it is supposed to.
When drawing to a Bitmap, the text is always behind the shading.
I have tried putting the text last in the pipeline but the behaviour appears unchanged. We don’t want to display the text in HUD mode because we want it hidden, when it really is behind the object.
Shading? I meant the fill.
How are you rendering to a bitmap? Are you using glReadPixels()?
I’m not totally sure how GLUT works, but if the problem persists, you might want to consider writing text with textures, which I bet is a hell lot faster, anyway. In case you don’t want to write that code yourself, there some free libraries out there to help you with that.
I’m rendering to a bitmap by applying it to my device context and then rendering to that device context.
I am setting up the context with this call.
mGLContext.InitContext(MemDC, PFD_DRAW_TO_BITMAP | PFD_SUPPORT_OPENGL | PFD_SUPPORT_GDI, 16);
I’ve tried 32 to for the bit depth with no difference.
Textures may be the way to go.
It looks like I’ve find an ‘undocumented feature’.
You might also want to consider this:
- Render to the screen (if possible)
- Grab the raw color frame by calling glReadPixels() into an array of bytes
- Write out this array of bytes onto a bitmap (not really sure, but I’m guessing there’s a windows function for this).
The problem with this approach is that your OGL window cannot be obstructed by other windows. Otherwise you might have to take another render-to-texture approach rendering offscreen using PBuffer or FBOs. But then again, it is possible that GLUT textures might mess up there, too.
Correct me if I’m wrong, but I believe you can also use WGL text. However, WGL text might or might not have the same problems and is also very slow compared to textured text. If this is a long term important project, I’d do textured text.
I’m going with textures.
I’m working in a high end app that will look cruddy if I’m popping up windows to screenscrape, especially since I’m screen scraping up to 1200 dpi for printer outputs.
Yeah, going with textured texts is definitely the right way to go. That also means your app will be less dependent on GLUT, which is always good in case you want to switch to another GUI API. Good luck!