hello,
i just did an svn update. lots of file have changed. (last update was 21 december) after building gem, i realized that few shaders example did not work any-more. it look to be related with rectangular texture : if you open shader example 1 : simple texture : it work ok with non rectangular texture (but the texture is upside down), but it does not work at all in rectangular mode...
hope that could be fixed soon thx, Cyrille
In a semi-related note, I'm trying to start gather patches for automatic regression testing. Cyrille, is this something that you could put into a patch that would test whether it worked and [print] the word SUCCESS if it does? If so, then such a thing can be run automatically every night.
We need to do more of this kind of stuff...
.hc
On Jan 15, 2010, at 3:22 PM, cyrille henry wrote:
hello,
i just did an svn update. lots of file have changed. (last update was 21 december) after building gem, i realized that few shaders example did not work any-more. it look to be related with rectangular texture : if you open shader example 1 : simple texture : it work ok with non rectangular texture (but the texture is upside down), but it does not work at all in rectangular mode...
hope that could be fixed soon thx, Cyrille _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
cyrille henry wrote:
hello,
i just did an svn update. lots of file have changed. (last update was 21 december) after building gem, i realized that few shaders example did not work any-more. it look to be related with rectangular texture : if you open shader example 1 : simple texture : it work ok with non rectangular texture (but the texture is upside down), but it does not work at all in rectangular mode...
i started to unify as much code as possible and try to reduce all the hacks handling different image orientations and non/rectangular textures. obviously the process is not finished yet :-(
- in the past, linux/w32 acquired pixes (images, video,...) in openGL orientation starting bottom-left (usually by flipping the images manually, since most image-APIs will return them top-left), whereas osx acquired them in top-left orientation and set the "upside-down" flag, thus being more performant (no pixel-wise flipping required) now, Gem will acquire the image in the same way on all OSs (top-left).
- the code was full of special handling for rectangular vs normalized texture coordinates. removing the cruft basically involved setting up a texture transformation matrix that would make the rectangular textures behave the same as normalized textures (mainly this is done by premultiplying the texcoords with a matrix that transforms 0..1 to 0..xsize and the like).
this basically means that now the texcoords should always appear to be 0..1. since the "sampler2DRect" expects texcoords to range from 0..xsize (and similar), it now fails.
hope that could be fixed soon
me too.
fmgasdr IOhannes
cyrille henry wrote:
hello,
i just did an svn update. lots of file have changed. (last update was 21 december) after building gem, i realized that few shaders example did not work any-more. it look to be related with rectangular texture : if you open shader example 1 : simple texture : it work ok with non rectangular texture (but the texture is upside down), but it does not work at all in rectangular mode...
hmm, the solution is "simple": you have to pre-multiply the texture matrix with the current tex-coords.
something like
<diff> Index: texture_rect.frag =================================================================== --- texture_rect.frag (Revision 3085) +++ texture_rect.frag (Arbeitskopie) @@ -7,8 +7,7 @@
void main (void) { -vec4 color = texture2DRect(MyTex, gl_TexCoord[0].st); -// vec4 color = texture2D(MyTex, gl_TexCoord[0].st); + vec4 color = texture2DRect(MyTex, (gl_TextureMatrix[0] * gl_TexCoord[0]).st); color *= B+1.; // brightness vec4 gray = vec4(dot(color.rgb,vec3(0.2125, 0.7154, 0.0721))); color = mix(gray, color, C+1.); // contrast </diff>
now i know that this breaks about each shader written so far for Gem.
the change is rather trivial, but it has to be done for each shader (to fix the upside down issue, it has also to be done for normalized (sampler2D) textures. the change in the shader code should (to the best of my knowledge) be compatible with older versions of Gem.
i don't see a way how this change could be automated (without parsing the shader and dynamically modifying it, which i would rather not :-)
the alternative would be to go back, which is also a bit problematic, as the change did fix inconsistencies and bugs between various platforms.
does anybody have any other ideas how this could be handled with the least annoyance for everybody?
fmgasdr IOhannes
PS: a hackish solution could also be the use of [pix_coordinate] to explicitely set the texture coordinates to "rectangular" values. this has the main drawback that it only works for the most primitive Geos. personally, i would not really recommend this, but i mention it for completeness' sake.
hello,
if this is the best solution for the future of Gem, i'm ok to manually check all my shaders and adapt them like you describe. i'll have a look next week... c
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
i just did an svn update. lots of file have changed. (last update was 21 december) after building gem, i realized that few shaders example did not work any-more. it look to be related with rectangular texture : if you open shader example 1 : simple texture : it work ok with non rectangular texture (but the texture is upside down), but it does not work at all in rectangular mode...
hmm, the solution is "simple": you have to pre-multiply the texture matrix with the current tex-coords.
something like
<diff> Index: texture_rect.frag =================================================================== --- texture_rect.frag (Revision 3085) +++ texture_rect.frag (Arbeitskopie) @@ -7,8 +7,7 @@
void main (void) { -vec4 color = texture2DRect(MyTex, gl_TexCoord[0].st); -// vec4 color = texture2D(MyTex, gl_TexCoord[0].st);
- vec4 color = texture2DRect(MyTex, (gl_TextureMatrix[0] *
gl_TexCoord[0]).st); color *= B+1.; // brightness vec4 gray = vec4(dot(color.rgb,vec3(0.2125, 0.7154, 0.0721))); color = mix(gray, color, C+1.); // contrast
</diff>
now i know that this breaks about each shader written so far for Gem.
the change is rather trivial, but it has to be done for each shader (to fix the upside down issue, it has also to be done for normalized (sampler2D) textures. the change in the shader code should (to the best of my knowledge) be compatible with older versions of Gem.
i don't see a way how this change could be automated (without parsing the shader and dynamically modifying it, which i would rather not :-)
the alternative would be to go back, which is also a bit problematic, as the change did fix inconsistencies and bugs between various platforms.
does anybody have any other ideas how this could be handled with the least annoyance for everybody?
fmgasdr IOhannes
PS: a hackish solution could also be the use of [pix_coordinate] to explicitely set the texture coordinates to "rectangular" values. this has the main drawback that it only works for the most primitive Geos. personally, i would not really recommend this, but i mention it for completeness' sake.
cyrille henry wrote:
hello,
if this is the best solution for the future of Gem, i'm ok to manually check all my shaders and adapt them like you describe.
cool, if you are open to such a change :-)
anyhow, i would also be interested in the opinion of others who have used shaders a lot (e.g. marius)
fgmasdr IOhannes
i'll have a look next week... c
I have never used (yet !) gl_TextureMatrix[0] in my shaders :) Always used something like this :
Vertex : texcoord1 = gl_MultiTexCoord0.st;
Fragment : vec4 color = texture2DRect(mytextA, texcoord1);
So i should use now : vec4 color = texture2DRect(mytextA, gl_TextureMatrix[0] * texcoord1); ? ++
Jack
Le mercredi 20 janvier 2010 à 14:18 +0100, IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
if this is the best solution for the future of Gem, i'm ok to manually check all my shaders and adapt them like you describe.
cool, if you are open to such a change :-)
anyhow, i would also be interested in the opinion of others who have used shaders a lot (e.g. marius)
fgmasdr IOhannes
i'll have a look next week... c
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Jack wrote:
I have never used (yet !) gl_TextureMatrix[0] in my shaders :)
nobody had, because there was the silent assumption, that nobody would touch the texture matrix.
Always used something like this :
Vertex : texcoord1 = gl_MultiTexCoord0.st;
Fragment : vec4 color = texture2DRect(mytextA, texcoord1);
So i should use now : vec4 color = texture2DRect(mytextA, gl_TextureMatrix[0] * texcoord1); ? ++
yes.
fnmasdr IOhannes
hello,
i adapt most shaders, it work great. but i still have upside down texture with framebuffer. can you have a look at example 07? i think i have to understand what is going on with framebuffer before trying to fix the physical modelling example...
Cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
i just did an svn update. lots of file have changed. (last update was 21 december) after building gem, i realized that few shaders example did not work any-more. it look to be related with rectangular texture : if you open shader example 1 : simple texture : it work ok with non rectangular texture (but the texture is upside down), but it does not work at all in rectangular mode...
hmm, the solution is "simple": you have to pre-multiply the texture matrix with the current tex-coords.
something like
<diff> Index: texture_rect.frag =================================================================== --- texture_rect.frag (Revision 3085) +++ texture_rect.frag (Arbeitskopie) @@ -7,8 +7,7 @@
void main (void) { -vec4 color = texture2DRect(MyTex, gl_TexCoord[0].st); -// vec4 color = texture2D(MyTex, gl_TexCoord[0].st);
- vec4 color = texture2DRect(MyTex, (gl_TextureMatrix[0] *
gl_TexCoord[0]).st); color *= B+1.; // brightness vec4 gray = vec4(dot(color.rgb,vec3(0.2125, 0.7154, 0.0721))); color = mix(gray, color, C+1.); // contrast
</diff>
now i know that this breaks about each shader written so far for Gem.
the change is rather trivial, but it has to be done for each shader (to fix the upside down issue, it has also to be done for normalized (sampler2D) textures. the change in the shader code should (to the best of my knowledge) be compatible with older versions of Gem.
i don't see a way how this change could be automated (without parsing the shader and dynamically modifying it, which i would rather not :-)
the alternative would be to go back, which is also a bit problematic, as the change did fix inconsistencies and bugs between various platforms.
does anybody have any other ideas how this could be handled with the least annoyance for everybody?
fmgasdr IOhannes
PS: a hackish solution could also be the use of [pix_coordinate] to explicitely set the texture coordinates to "rectangular" values. this has the main drawback that it only works for the most primitive Geos. personally, i would not really recommend this, but i mention it for completeness' sake.
cyrille henry wrote:
hello,
i adapt most shaders, it work great. but i still have upside down texture with framebuffer. can you have a look at example 07? i think i have to understand what is going on with framebuffer before
i think i fixed it. please re-check.
btw, it seems like the new code makes hacks like the [pix_set]/[pix_texture] thing to set the texcoords obsolete.
fgm,adsr IOhannes
Hello,
yes, everything is working for what i see now.
i just have to fix the example 09. it is a bit complex, so it will take longer. all other examples are working perfectly.
thanks
Cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
i adapt most shaders, it work great. but i still have upside down texture with framebuffer. can you have a look at example 07? i think i have to understand what is going on with framebuffer before
i think i fixed it. please re-check.
btw, it seems like the new code makes hacks like the [pix_set]/[pix_texture] thing to set the texcoords obsolete.
fgm,adsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
well. the example 09 work with no modification of the code. strange, since it use both rectangle 0 and 1 mode. but since it work and the code is not really friendly, i'll leave it like it is...
Cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
i adapt most shaders, it work great. but i still have upside down texture with framebuffer. can you have a look at example 07? i think i have to understand what is going on with framebuffer before
i think i fixed it. please re-check.
btw, it seems like the new code makes hacks like the [pix_set]/[pix_texture] thing to set the texcoords obsolete.
fgm,adsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
updating my shader, i find 1 more problem.
the repeat message to texture does not work anymore. worst, when sending it, the texture does not work at all. see this patch : all shader and images used are in the glsl section in example folder.
Cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
i adapt most shaders, it work great. but i still have upside down texture with framebuffer. can you have a look at example 07? i think i have to understand what is going on with framebuffer before
i think i fixed it. please re-check.
btw, it seems like the new code makes hacks like the [pix_set]/[pix_texture] thing to set the texcoords obsolete.
fgm,adsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
cyrille henry wrote:
hello,
updating my shader, i find 1 more problem.
the repeat message to texture does not work anymore. worst, when sending it, the texture does not work at all. see this patch : all shader and images used are in the glsl section in example folder.
aye, this is obviously a bug in [pix_texture], which seems to not re-initialize itself after a "repeat" message. until it get's fixed it helps to call "rectangle <x>" after the "repeat". but this is really an ugly hack and i hope to fix the problem asap.
fgmasdr IOhannes
the quality message have the same probleme. i replace the 3 occurrences of : setModified(); with m_rebuildList=1; in pix_texture.cpp i don't know if it's the solution or a hack, but it work.
c
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello,
updating my shader, i find 1 more problem.
the repeat message to texture does not work anymore. worst, when sending it, the texture does not work at all. see this patch : all shader and images used are in the glsl section in example folder.
aye, this is obviously a bug in [pix_texture], which seems to not re-initialize itself after a "repeat" message. until it get's fixed it helps to call "rectangle <x>" after the "repeat". but this is really an ugly hack and i hope to fix the problem asap.
fgmasdr IOhannes
cyrille henry wrote:
the quality message have the same probleme. i replace the 3 occurrences of : setModified(); with m_rebuildList=1; in pix_texture.cpp i don't know if it's the solution or a hack, but it work.
i hope i have fixed it now in svn. everything get's a bit more complicated if you try to keep multi-context rendering in mind.
fgmasdr IOhannes
-
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Jack