# OpenGL OpenGL printing: getting too thin lines and too small points

## Recommended Posts

Hello, I am trying to output my OpenGL scene to a bitmap and a printer using code that is very similar to the one contained here: http://www.codeguru.com/cpp/g-m/opengl/printing/article.php/c5585 It executes fine, except for one thing: in the output, lines appear very thin and points appear very small when using high resolution printing(say 600 dpi). Output to smaller resolutions yields correct results. Calls to glLineWidth() and glPointSize() appear to have no effect or little effect for values higher than 2. To summarize: * When generating BMP files with 75 or 96 dpi, everything is rendered correctly. Lines and Points follow screen appearance. * When printing to a PDF or Laser Printer (which, by default, uses 600 dpi) lines and points appear as 1 pixel width/size. The DPI values retrieved from printer influence size of memory bitmap to where I render. Does anybody now if bitmap size influences how lines and points are rasterized? Thanks in advance. João Pedro

##### Share on other sites
Quote:
 Original post by jpnascimHello,I am trying to output my OpenGL scene to a bitmap and a printer using code that is very similar to the one contained here:http://www.codeguru.com/cpp/g-m/opengl/printing/article.php/c5585It executes fine, except for one thing: in the output, lines appear very thin and points appear very small when using high resolution printing(say 600 dpi). Output to smaller resolutions yields correct results. Calls to glLineWidth() and glPointSize() appear to have no effect or little effect for values higher than 2.To summarize:* When generating BMP files with 75 or 96 dpi, everything is rendered correctly. Lines and Points follow screen appearance.* When printing to a PDF or Laser Printer (which, by default, uses 600 dpi) lines and points appear as 1 pixel width/size.The DPI values retrieved from printer influence size of memory bitmap to where I render. Does anybody now if bitmap size influences how lines and points are rasterized?Thanks in advance.João Pedro

in opengl a line normally doesn't have a width so when rasterized it becomes as thin as possible, a higher resolution means the line gets thinner, the recommended resolution in windows is 96 dpi (1280x960 for a 16.7" 4:3 monitor) which is why 96 dpi rasterizations match what you see.

http://www.khronos.org/opengles/sdk/docs/man/glLineWidth.xml

The only linewidth that is guaranteed to be supported is 1 , the rest is implementation specific, use glGet to see what range your implementation supports.

##### Share on other sites
Quote:
 * When generating BMP files with 75 or 96 dpi, everything is rendered correctly. Lines and Points follow screen appearance.* When printing to a PDF or Laser Printer (which, by default, uses 600 dpi) lines and points appear as 1 pixel width/size.

A line that is 1 pixel wide at 77/96 dpi is not 1 pixel wide at 600 dpi.
You need to scale up glLineWidth() accordingly. Use GetDeviceCaps() to get the ppi for you device.

##### Share on other sites
Hello,

Sorry for not getting back sooner. Thank you for the replies.

Quote:
 Original post by SimonForsmanThe only linewidth that is guaranteed to be supported is 1 , the rest is implementation specific, use glGet to see what range your implementation supports.

Ok, I see. By calling glGetIntegerv(GL_LINE_WIDTH_RANGE, range) when render context is the memory bitmap, I get min=1 and max=10.

Quote:
 Original post by samster581A line that is 1 pixel wide at 77/96 dpi is not 1 pixel wide at 600 dpi.You need to scale up glLineWidth() accordingly. Use GetDeviceCaps() to get the ppi for you device.

Right. In fact that's what I was doing. I get device DPI for the PDF printer I am using, in this case, 600 dpi. With DPI and page size, I determine bitmap render size, like this:
const unsigned X_DPI = GetDeviceCaps(PrinterDialog.hDC, LOGPIXELSX); const unsigned Y_DPI = GetDeviceCaps(PrinterDialog.hDC, LOGPIXELSY);// Define the size of the image that will be createdbitmapWidthOnPage  = pageWidthInches  * X_DPI;bitmapHeightOnPage = pageHeightInches * Y_DPI;

Then I build the bitmap, device context, rendering context and activate everything:

//Create Bitmap herememset(&BitmapInfo, 0, sizeof(BITMAPINFO));BitmapInfo.bmiHeader.biSize		   = sizeof(BITMAPINFOHEADER);BitmapInfo.bmiHeader.biWidth	   = bitmapWidthOnPage;BitmapInfo.bmiHeader.biHeight	   = bitmapHeightOnPage;BitmapInfo.bmiHeader.biPlanes	   = 1;BitmapInfo.bmiHeader.biBitCount	   = 24;BitmapInfo.bmiHeader.biCompression = BI_RGB;BitmapInfo.bmiHeader.biSizeImage   = ((width * 3) + complement) * height;// Create DIBDibNew = CreateDIBSection(NULL, &BitmapInfo, DIB_RGB_COLORS, &BitmapBits, NULL, (DWORD)0);//Create Device ContextHDC_MemoryBitmap = CreateCompatibleDC(NULL);//...//Create Rendering ContextHRC_MemoryBitmap = wglCreateContext(HDC_MemoryBitmap);//...//Make it currentwglMakeCurrent(HDC_MemoryBitmap, HRC_MemoryBitmap);//...

Then I render the scene to the bitmap taking care to set lineWidth to the maximum value of 10 obtained earlier(as a test). Still, rendered line is thin.

Any other ideas?

Thank you very much,

Joao Pedro

[Edited by - jpnascim on May 3, 2010 8:50:46 AM]

##### Share on other sites
OpenGL only knows about pixels, it doesn't know anything about ppi or device resolution (as far as I know).
As long as you're setting up a thick line width using glLineWidth(), then the line should look thicker, provided it's supported

So, open up your 600 ppi bitmap and measure the pixel width of your line. If you say you set its width to 10, then your lines
should be 10 pixels wide. There's your proof.

If you want bigger lines than 10, then you'll have to come up with a new way to render OpenGL lines. Like, drawing them as
thick polygon rectangles. That will support lines of any thickness.

##### Share on other sites
Well, problem solved.

Before the correction, I was generating a bitmap with a size dependent on output device DPI. For example, if page size is A4(8.27 X 11.69 inches) and printer's DPI is 600 I was trying to render a bitmap with size:

horizontal = 8.27 x 600 = 4962 pixels
vertical = 11.69 x 600 = 7014 pixels

When rendering to this bitmap lines appeared thin, no matter the values I've passed to glLineWidth(). The reason I was doing this was because I thought I would loose image quality in a high DPI device if I rendered to a smaller bitmap and called StretchDIBits() (Win32 API).

Well, it turned out that if I generate my bitmap considering 96 dpi:

horizontal = 8.27 x 96 dpi = 794 pixels
vertical = 11.69 x 96 dpi = 1122 pixels

and make a call to StretchDIBits() with the parameters:

nDestWidth = 4962 (paper width in pixels)
nDestHeight = 7014 (paper height in pixels)

nSrcWidth = 794 (rendered bitmap width in pixels)
nSrcHeight = 1122 (rendered bitmap height in pixels)

With these values, results are correct. Lines and Points appear with programmed thickness. Also, print quality is excellent with no loss of resolution due to bitmap scale up operation.

Thanks for the help,

João Pedro

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627660
• Total Posts
2978489
• ### Similar Content

• Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.
But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.
• By cebugdev
hi guys,
are there any books, link online or any other resources that discusses on how to build special effects such as magic, lightning, etc. in OpenGL? i mean, yeah most of them are using particles but im looking for resources specifically on how to manipulate the particles to look like an effect that can be use for games,. i did fire particle before, and I want to learn how to do the other 'magic' as well.
Like are there one book or link(cant find in google) that atleast featured how to make different particle effects in OpenGL (or DirectX)? If there is no one stop shop for it, maybe ill just look for some tips on how to make a particle engine that is flexible enough to enable me to design different effects/magic
let me know if you guys have recommendations.
• By dud3
How do we rotate the camera around x axis 360 degrees, without having the strange effect as in my video below?
Mine behaves exactly the same way spherical coordinates would, I'm using euler angles.
Tried googling, but couldn't find a proper answer, guessing I don't know what exactly to google for, googled 'rotate 360 around x axis', got no proper answers.

References:
Code: https://pastebin.com/Hcshj3FQ
The video shows the difference between blender and my rotation:

• By Defend
I've had a Google around for this but haven't yet found some solid advice. There is a lot of "it depends", but I'm not sure on what.
My question is what's a good rule of thumb to follow when it comes to creating/using VBOs & VAOs? As in, when should I use multiple or when should I not? My understanding so far is that if I need a new VBO, then I need a new VAO. So when it comes to rendering multiple objects I can either:
* make lots of VAO/VBO pairs and flip through them to render different objects, or
* make one big VBO and jump around its memory to render different objects.
I also understand that if I need to render objects with different vertex attributes, then a new VAO is necessary in this case.
If that "it depends" really is quite variable, what's best for a beginner with OpenGL, assuming that better approaches can be learnt later with better understanding?

• 10
• 12
• 22
• 13
• 33