GEM-dev August 2011

gem-dev@lists.iem.at

12 participants
21 discussions

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3281206, was opened at 2011-04-08 23:07 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: rendering (e.g. display) Group: any operating system Status: Pending Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 22:41 Message: as for [gemframebuffer], i really don't know why CLAMP is used rather than CLAMP_TO_EDGE; it was most likely forgotten... but apart from that, CLAMP_TO_EDGE is already used (and that's at least since 0.91) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-08-16 21:25 Message: hello, yes, GL_CLAMP_TO_EDGE is better than GL_CLAMP. The grep does not say a lot about the code. if you have a look in pix_texture.cpp : if (type) m_repeat = GL_REPEAT; else { if(GLEW_EXT_texture_edge_clamp) m_repeat = GL_CLAMP_TO_EDGE; else m_repeat = GL_CLAMP; } when repeat mode = 0, then m_repeat is GL_CLAMP_TO_EDGE if possible, or GL_CLAMP if not. it's the same about pix_imageInPlace and pix_cubemap. it's not the same for framebuffer, but there certainly is a good reason for this. c ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 19:15 Message: Guessing at the cause here, but I'm led to believe GL_CLAMP is mostly wrong, and GL_CLAMP_TO_EDGE is to be preferred almost always... http://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem claude@zebimus:~/code/pd-gem$ grep -Rwn "GL_CLAMP" . | grep -v \\.svn ./Gem/ChangeLog:4473: "GL_CLAMP" when doing rectangle-textures, as they will ignore ./Gem/src/Pixes/pix_imageInPlace.cpp:216: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_cubemap.cpp:365: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_texture.cpp:118: // NPOT: GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER ./Gem/src/Pixes/pix_texture.cpp:690: m_repeat = GL_CLAMP; ./Gem/src/Gem/glew.h:698:#define GL_CLAMP 0x2900 ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ./Gem/src/Utils/GLUtil_generated.h:86: if (!strcmp(name, "GL_CLAMP")) return GL_CLAMP; ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:42: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:43: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:69: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:70: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:128: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:129: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/include/FTGLTextureFont.h:85: * GL_TEXTURE_WRAP_S = GL_CLAMP ./GemLibs/FTGL/include/FTGLTextureFont.h:86: * GL_TEXTURE_WRAP_T = GL_CLAMP Incidentally, could these better be ...i instead of ...f function calls? claude@zebimus:~/code/pd-gem$ grep -Rn "glTexParameterf" . | grep -v \\.svn | grep -v GL_TEXTURE_PRIORITY | grep -v src/openGL | grep -v glew\.h | grep -v build/ | grep -v GEM ./Gem/src/Pixes/pix_imageInPlace.cpp:156: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_imageInPlace.cpp:157: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:112: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:113: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:114: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:115: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:347: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:348: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:371: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:372: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:90: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:91: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:365: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:366: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:137: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:138: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:139: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:140: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:270: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:271: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:657: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:658: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:696: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:697: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_movieOS.cpp:271: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); ./Gem/src/Pixes/pix_movieOS.cpp:272: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 18:33 Message: it's hardware/driver specific as the openGL standard doesn't specify exactly how it ought to be done (afair); i mainly follow cyrille's arguing here. the workaround is to e.g. set "repeat" mode and/or the "quality" mode of texture. you can apply a global defaul by adding lines for "texture.quality" and "texture.repeat" to your gem.conf; something like: <gem.conf> texture.quality 0 </gem.conf> ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 18:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 18:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 18:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 17:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-09 00:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 23:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3281206, was opened at 2011-04-08 21:07 Message generated for change (Comment added) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: rendering (e.g. display) Group: any operating system Status: Pending Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-08-16 19:25 Message: hello, yes, GL_CLAMP_TO_EDGE is better than GL_CLAMP. The grep does not say a lot about the code. if you have a look in pix_texture.cpp : if (type) m_repeat = GL_REPEAT; else { if(GLEW_EXT_texture_edge_clamp) m_repeat = GL_CLAMP_TO_EDGE; else m_repeat = GL_CLAMP; } when repeat mode = 0, then m_repeat is GL_CLAMP_TO_EDGE if possible, or GL_CLAMP if not. it's the same about pix_imageInPlace and pix_cubemap. it's not the same for framebuffer, but there certainly is a good reason for this. c ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 17:15 Message: Guessing at the cause here, but I'm led to believe GL_CLAMP is mostly wrong, and GL_CLAMP_TO_EDGE is to be preferred almost always... http://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem claude@zebimus:~/code/pd-gem$ grep -Rwn "GL_CLAMP" . | grep -v \\.svn ./Gem/ChangeLog:4473: "GL_CLAMP" when doing rectangle-textures, as they will ignore ./Gem/src/Pixes/pix_imageInPlace.cpp:216: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_cubemap.cpp:365: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_texture.cpp:118: // NPOT: GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER ./Gem/src/Pixes/pix_texture.cpp:690: m_repeat = GL_CLAMP; ./Gem/src/Gem/glew.h:698:#define GL_CLAMP 0x2900 ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ./Gem/src/Utils/GLUtil_generated.h:86: if (!strcmp(name, "GL_CLAMP")) return GL_CLAMP; ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:42: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:43: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:69: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:70: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:128: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:129: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/include/FTGLTextureFont.h:85: * GL_TEXTURE_WRAP_S = GL_CLAMP ./GemLibs/FTGL/include/FTGLTextureFont.h:86: * GL_TEXTURE_WRAP_T = GL_CLAMP Incidentally, could these better be ...i instead of ...f function calls? claude@zebimus:~/code/pd-gem$ grep -Rn "glTexParameterf" . | grep -v \\.svn | grep -v GL_TEXTURE_PRIORITY | grep -v src/openGL | grep -v glew\.h | grep -v build/ | grep -v GEM ./Gem/src/Pixes/pix_imageInPlace.cpp:156: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_imageInPlace.cpp:157: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:112: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:113: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:114: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:115: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:347: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:348: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:371: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:372: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:90: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:91: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:365: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:366: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:137: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:138: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:139: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:140: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:270: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:271: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:657: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:658: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:696: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:697: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_movieOS.cpp:271: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); ./Gem/src/Pixes/pix_movieOS.cpp:272: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 16:33 Message: it's hardware/driver specific as the openGL standard doesn't specify exactly how it ought to be done (afair); i mainly follow cyrille's arguing here. the workaround is to e.g. set "repeat" mode and/or the "quality" mode of texture. you can apply a global defaul by adding lines for "texture.quality" and "texture.repeat" to your gem.conf; something like: <gem.conf> texture.quality 0 </gem.conf> ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 16:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 16:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 16:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 15:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-08 22:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 21:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3281206, was opened at 2011-04-08 21:07 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: rendering (e.g. display) Group: any operating system Status: Pending Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 17:15 Message: Guessing at the cause here, but I'm led to believe GL_CLAMP is mostly wrong, and GL_CLAMP_TO_EDGE is to be preferred almost always... http://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem claude@zebimus:~/code/pd-gem$ grep -Rwn "GL_CLAMP" . | grep -v \\.svn ./Gem/ChangeLog:4473: "GL_CLAMP" when doing rectangle-textures, as they will ignore ./Gem/src/Pixes/pix_imageInPlace.cpp:216: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_cubemap.cpp:365: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_texture.cpp:118: // NPOT: GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER ./Gem/src/Pixes/pix_texture.cpp:690: m_repeat = GL_CLAMP; ./Gem/src/Gem/glew.h:698:#define GL_CLAMP 0x2900 ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ./Gem/src/Utils/GLUtil_generated.h:86: if (!strcmp(name, "GL_CLAMP")) return GL_CLAMP; ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:42: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:43: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:69: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:70: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:128: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:129: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/include/FTGLTextureFont.h:85: * GL_TEXTURE_WRAP_S = GL_CLAMP ./GemLibs/FTGL/include/FTGLTextureFont.h:86: * GL_TEXTURE_WRAP_T = GL_CLAMP Incidentally, could these better be ...i instead of ...f function calls? claude@zebimus:~/code/pd-gem$ grep -Rn "glTexParameterf" . | grep -v \\.svn | grep -v GL_TEXTURE_PRIORITY | grep -v src/openGL | grep -v glew\.h | grep -v build/ | grep -v GEM ./Gem/src/Pixes/pix_imageInPlace.cpp:156: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_imageInPlace.cpp:157: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:112: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:113: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:114: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:115: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:347: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:348: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:371: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:372: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:90: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:91: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:365: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:366: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:137: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:138: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:139: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:140: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:270: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:271: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:657: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:658: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:696: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:697: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_movieOS.cpp:271: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); ./Gem/src/Pixes/pix_movieOS.cpp:272: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 16:33 Message: it's hardware/driver specific as the openGL standard doesn't specify exactly how it ought to be done (afair); i mainly follow cyrille's arguing here. the workaround is to e.g. set "repeat" mode and/or the "quality" mode of texture. you can apply a global defaul by adding lines for "texture.quality" and "texture.repeat" to your gem.conf; something like: <gem.conf> texture.quality 0 </gem.conf> ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 16:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 16:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 16:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 15:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-08 22:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 21:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3281206, was opened at 2011-04-08 23:07 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: rendering (e.g. display) Group: any operating system Status: Pending Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 18:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 18:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 18:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 17:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-09 00:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 23:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

1 0

[ pd-gem-Bugs-3091491 ] lights don't turn off when disconnected
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3091491, was opened at 2010-10-20 22:02 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3091491&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: rendering (e.g. display) Group: None >Status: Pending >Resolution: Postponed Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Nobody/Anonymous (nobody) Summary: lights don't turn off when disconnected Initial Comment: lights do not stop to render when the patch-cord is disconnected. this is true for gem 0.92.3 on windows. m. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 18:11 Message: svn now mentions the on/off messages ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 18:06 Message: it's more the way openGL is working (against how Pd is working) i don't think this will be fixed anytime soon. the simple way to turn on/off a specific light is by sending it 1/0 (i think this is missing in the help-files) ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2010-10-23 22:19 Message: no, I really think, this is a bug, because I see another problem related to this: lighting in gemframebuffers does not work (can't have lights only in gemframebuffer). m. ---------------------------------------------------------------------- Comment By: kubriel (kubriel) Date: 2010-10-21 13:38 Message: last week i was wondering if this is a bug they also dont react on turning off the gemhead so same here on gem ver: 0.93.SVN rev3478M, 64bit ubuntu linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3091491&group_…

1 0

[ pd-gem-Bugs-3091491 ] lights don't turn off when disconnected
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3091491, was opened at 2010-10-20 22:02 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3091491&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: rendering (e.g. display) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Nobody/Anonymous (nobody) Summary: lights don't turn off when disconnected Initial Comment: lights do not stop to render when the patch-cord is disconnected. this is true for gem 0.92.3 on windows. m. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 18:06 Message: it's more the way openGL is working (against how Pd is working) i don't think this will be fixed anytime soon. the simple way to turn on/off a specific light is by sending it 1/0 (i think this is missing in the help-files) ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2010-10-23 22:19 Message: no, I really think, this is a bug, because I see another problem related to this: lighting in gemframebuffers does not work (can't have lights only in gemframebuffer). m. ---------------------------------------------------------------------- Comment By: kubriel (kubriel) Date: 2010-10-21 13:38 Message: last week i was wondering if this is a bug they also dont react on turning off the gemhead so same here on gem ver: 0.93.SVN rev3478M, 64bit ubuntu linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3091491&group_…

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 16 Aug '11

16 Aug '11

1 0

[ pd-gem-Bugs-3191771 ] pix_movement treats a duplicate frame as black in Mac OS
by SourceForge.net 16 Aug '11

16 Aug '11

Bugs item #3191771, was opened at 2011-02-25 01:32 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: osx >Status: Pending >Resolution: Duplicate Priority: 6 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_movement treats a duplicate frame as black in Mac OS Initial Comment: Consider: [pix_video] | [pix_movement] Expected behavior: When pix_video produces a duplicate frame (i.e. doesn't grab a new frame), one may expect any of these two: A - (best) pix_movement won't generate a new image B - (acceptable) pix_movement will generate a black image since it's comparing two identical frames (actually the same frame) Observed behavior in Linux: - I'm almost sure it's A Observed behavior in Mac OS: - pix_movement treats the duplicate frame as if it was a black frame; so it will compare the current frame with a completely black frame, outputting an image with a lot of "false movement". Not sure about Windows, I seem to remember it works fine just like in Linux; or it may be behavior B; surely not like Mac OS. This has been known for a long time but I couldn't find it in the bug tracker and it is not fixed, so I thought I would report it. Note that it is not just a matter of failing to detect that the new frame hasn't been grabbed. That would explain behavior B described above, flickering to black. What's happening is much wronger: duplicate frames are treated as black frames which causes the output to flicker to almost-white. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 14:53 Message: actually, what i've written above (below?) is wrong, the YUV handling is fine (apart from weird behaviour, that it leaves color information intact which gives you "ghost images" in the no-movement zone) the real issue is, that the pix-manipulation is done in-place in that the "newimage" flag is not properly set. this makes it a dupe of #1939029, #2519970 and can be solved by inserting a [pix_separator] object after the [pix_video]. https://sourceforge.net/tracker/?func=detail&aid=1939029&group_id=64325&ati… https://sourceforge.net/tracker/?func=detail&aid=2519970&group_id=64325&ati… ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-07-21 18:25 Message: ack. the problem seems to be only the YUV handling, so a quick fix is to switch the colorspace e.g. by using [pix_grey] just before [pix_movement] ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-05 13:51 Message: I'm raising priority as this renders pix_movement almost useless in Mac OS, and it is a pretty basic object. Hope this is ok ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev August 2011