From: Rouben R. <ros...@um...> - 2002-05-17 16:13:46
|
Hello Mesa users! Is there a utility for capturing Mesa-generated graphics as vector postscript output? I can save the graphics in pixel-oriented formats, such as png or tiff. But such pixel graphics don't do well under scaling. I believe that implementing vector postscript output amounts to re-writing a good chunk of Mesa in Postscript, therefore it may not be a simple task. I wonder is this has been done or is being worked on. -- Rouben Rostamian <ros...@um...> |
From: Stephen J B. <sj...@li...> - 2002-05-17 17:39:35
|
On Fri, 17 May 2002, Rouben Rostamian wrote: > Hello Mesa users! > > Is there a utility for capturing Mesa-generated graphics > as vector postscript output? I don't know about a specifically Mesa solution - but there was at one time a package on www.opengl.org that did a partial job of generating Postscript from raw OpenGL calls. It's hard to do a good job though - hidden surface elimination and texturing (for example) are particularly hard to render in Postscript. Check out: http://www.opengl.org/developers/code/mjktips/Feedback.html?postscript#first_hit ...and... http://www.easysw.com/~mike/opengl/index.html > I can save the graphics in pixel-oriented formats, such > as png or tiff. But such pixel graphics don't do well > under scaling. You might want to consider rendering your image at insanely high resolution (perhaps tiling the image so that you can render it in (say) 1k x 1k chunks) - so that you can send the raster to your printer (or whatever) at a sufficiently high resolution. It's relatively easy to scale a raster image *down* in size - so if you start of with very high resolution, you should be OK. > I believe that implementing vector postscript output > amounts to re-writing a good chunk of Mesa in Postscript, > therefore it may not be a simple task. I wonder is this > has been done or is being worked on. Yes it has (see the GLP link above) - but the results are disappointing simply because you end up needing pixel-like rendering primitives in order to get perspective-correct texture, alpha blending and hidden surfaces (to name just a few) in Postscript. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Andy S. <an...@ne...> - 2002-05-20 00:41:27
|
I haven't had time to download and compile Mesa 4.0.2 and this particular problem may or may not have been fixed (it seems related to the "GL_REPLACE with GL_RGB texture format wasn't always correct (alpha)" bug fix, although I'm using GL_RGBA here). However, as of 4.0.1 it exists. See listing at the end of the message. Replacing: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); with: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); shows the correct colors. Also, does anyone know what I am doing wrong? I can't seem to get translucent textures (does not seem to be a bug, since my Win XP 3dfx OpenGL drivers also give the same behaviour. The translucency did appear under Win98 MS OpenGL dlls, but not the SGI OpenGL dlls). === BEGIN LISTING === #include <GL/glut.h> #include <stdlib.h> #include <mem.h> static int smallFirst = GL_TRUE; GLbyte texture[4096*4]; void createTexture(void) { int counter=0; do { switch (counter%16) { case 0: memset(texture+counter,0x00,1); break; case 1: memset(texture+counter,0x00,1); break; case 2: memset(texture+counter,0xff,1); break; case 3: memset(texture+counter,0x00,1); break; case 4: memset(texture+counter,0xff,1); break; case 5: memset(texture+counter,0x00,1); break; case 6: memset(texture+counter,0x00,1); break; case 7: memset(texture+counter,0x7f,1); break; case 8: memset(texture+counter,0x00,1); break; case 9: memset(texture+counter,0xff,1); break; case 10: memset(texture+counter,0x00,1); break; case 11: memset(texture+counter,0x3f,1); break; case 12: memset(texture+counter,0xff,1); break; case 13: memset(texture+counter,0xff,1); break; case 14: memset(texture+counter,0xff,1); break; case 15: memset(texture+counter,0x00,1); break; } } while (++counter<16384); } static void init(void) { createTexture(); glClearColor (0.0, 0.0, 0.0, 0.0); glTexImage2D(GL_TEXTURE_2D,0,3,64,64,0,GL_RGBA,GL_UNSIGNED_BYTE,texture); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); // BUG APPEARS HERE! glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); // END OF BUG glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE); glEnable(GL_TEXTURE_2D); glEnable (GL_BLEND); glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); } static void drawSmallQuad(void) { glBegin (GL_QUADS); glTexCoord2f(0,0); glVertex2i(0,0); glTexCoord2f(1,0); glVertex2i(64,0); glTexCoord2f(1,1); glVertex2i(64,64); glTexCoord2f(0,1); glVertex2i(0,64); glEnd(); } static void drawBigQuad(void) { glBegin (GL_QUADS); glTexCoord2f(0,0); glVertex2i(31,31); glTexCoord2f(1,0); glVertex2i(159,31); glTexCoord2f(1,1); glVertex2i(159,159); glTexCoord2f(0,1); glVertex2i(31,159); glEnd(); } void display(void) { glClear(GL_COLOR_BUFFER_BIT); if (smallFirst) { drawSmallQuad(); drawBigQuad(); } else { drawBigQuad(); drawSmallQuad(); } glFlush(); } void reshape(int w, int h) { glViewport(0, 0, (GLsizei) w, (GLsizei) h); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho ( 0, 320, 0, 240, -1, 1 ); } void keyboard(unsigned char key, int x, int y) { switch (key) { case 't': case 'T': smallFirst = !smallFirst; glutPostRedisplay(); break; case 27: /* Escape key */ exit(0); break; default: break; } } int main(int argc, char** argv) { glutInit(&argc, argv); glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB); glutInitWindowSize (320, 240); glutCreateWindow (argv[0]); init(); glutReshapeFunc (reshape); glutKeyboardFunc (keyboard); glutDisplayFunc (display); glutMainLoop(); return 0; } === END LISTING === |
From: Brian P. <br...@tu...> - 2002-05-20 18:49:03
|
Andy Sy wrote: > > I haven't had time to download and compile Mesa 4.0.2 > and this particular problem may or may not have been > fixed (it seems related to the "GL_REPLACE with GL_RGB > texture format wasn't always correct (alpha)" bug > fix, although I'm using GL_RGBA here). However, as of > 4.0.1 it exists. See listing at the end of the message. > > Replacing: > glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); > glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); > > with: > glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); > glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); > > shows the correct colors. I tried your program with Mesa 4.0.1 and the latest CVS and don't see a problem. Do you understand the difference between point sampling and linear sampling? > Also, does anyone know what I am doing wrong? I can't seem > to get translucent textures (does not seem to be a bug, > since my Win XP 3dfx OpenGL drivers also give the same > behaviour. The translucency did appear under Win98 MS OpenGL > dlls, but not the SGI OpenGL dlls). You'll have to provide more info. -Brian |
From: Andy S. <an...@ne...> - 2002-05-20 19:19:20
|
> I tried your program with Mesa 4.0.1 and the latest CVS and don't > see a problem. Do you understand the difference between point > sampling and linear sampling? I was gonna take a screenshot just now, but the bug did not appear anymore... weird... in the original case the colors were all wrong in the GL_LINEAR case. > > Also, does anyone know what I am doing wrong? I can't seem > > to get translucent textures (does not seem to be a bug, > > since my Win XP 3dfx OpenGL drivers also give the same > > behaviour. The translucency did appear under Win98 MS OpenGL > > dlls, but not the SGI OpenGL dlls). In the test program, the texture I'm using has alpha info (as can be seen in the createTexture() function), but they are being rendered as opaque even when I have the following: glEnable(GL_TEXTURE_2D); glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); Am I still missing some parameter? |
From: Brian P. <br...@tu...> - 2002-05-20 19:26:06
|
Andy Sy wrote: > > > I tried your program with Mesa 4.0.1 and the latest CVS and don't > > see a problem. Do you understand the difference between point > > sampling and linear sampling? > > I was gonna take a screenshot just now, but the bug > did not appear anymore... weird... in the original > case the colors were all wrong in the GL_LINEAR > case. Well, when you blend red w/ blue, or red w/ green, etc. as in done with linear sampling, you're not going to see pure red, pure blue, etc. > > > Also, does anyone know what I am doing wrong? I can't seem > > > to get translucent textures (does not seem to be a bug, > > > since my Win XP 3dfx OpenGL drivers also give the same > > > behaviour. The translucency did appear under Win98 MS OpenGL > > > dlls, but not the SGI OpenGL dlls). > > In the test program, the texture I'm using has alpha info (as > can be seen in the createTexture() function), but they are being > rendered as opaque even when I have the following: > > glEnable(GL_TEXTURE_2D); > glEnable(GL_BLEND); > glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); > > Am I still missing some parameter? Try changing the '3' in your glTexImage call to '4'. This is the internal texture format parameter. 3 corresponds to GL_RGB and 4 corresponds to GL_RGBA. -Brian |
From: Andy S. <an...@ne...> - 2002-05-20 20:31:44
|
Whoops my mistake, the 'bug' didn't disappear, I just forgot to switch to using the mesa dlls. Here are the screenshots. Could it have anything to do with my using MesaGL.dll as a drop-in replacement for opengl32.dll? I just rename mesaGL.dll as opengl32.dll and stick it in the same directory as the executable. |
From: Brian P. <br...@tu...> - 2002-05-20 20:46:15
|
Andy Sy wrote: > > Whoops my mistake, the 'bug' didn't disappear, > I just forgot to switch to using the mesa dlls. > > Here are the screenshots. Could it have anything > to do with my using MesaGL.dll as a drop-in > replacement for opengl32.dll? I just rename > mesaGL.dll as opengl32.dll and stick it in > the same directory as the executable. Try Mesa 4.0.2. I seem to recall a bug in the Windows driver in 4.0.1 that might explain the problem seen in mesa_linear.png. -Brian |