Re: [PD] Gem / glsl_fragment
Hello ub, yes, some things are strange with shaders texture coordinate, specially with multi-texture. in fact, only 1st texture coordinate is set to correct value, not the others. so you have to compute texture coordinate according to the textures size. That's why you need a pix_set : it will initialise texture size, if you don't have a pix_image after the shader. I don't thing you really need to use rectangle texture with 4:3 input : non rectangle should work to. (if you scale accordingly the texture coordinate). (you can have a look at how it's done in example 06). if the example multitexture works for you, but not rectangle_multitexture, it's probably because you system did not allow you to create rectangle texture (this is strange). or maybe because some function use to get the image size did not work for you. (what is your GPU?). you can try to change shaders line : ivec2 size1 = textureSize2DRect(Ttex1, 0); ivec2 size2 = textureSize2DRect(Ttex2, 0); ivec2 size0 = textureSize2DRect(tex0, 0); vith : ivec2 size1 = (256, 256); ivec2 size2 = (234, 543); ivec2 size0 = (512, 512); I never tried to use a pix_object (contrast or add) when using a shader, because a shader can easilly do the same thing but lot's faster. I'm quite familiar with the flashing your experimenting : it's usually a problem with texture coordinate. You can experiment with adding a scale factor for the texture in order to understand a bit more how things work : good luck Cyrille Le 30/07/2011 01:42, u...@xdv.org a écrit : hey there again, i basically got my shader running, it was a bit of a challenge, because i realized i had to use rectangle texunits, as the input is classic 4:3 video frames. so fine, i did this, but now the output of pix_progam is acting kind of weird. it seems to be a proper pix structure, when i attach a pix_info to it, it's the correct resolution and type. it is possible that it is still an bug in my shader, but for instance i see in the example patch 06.rectangle_multitexture that there is a pix_set right after the pix_program and also in my patch things dont work correctly when i don't put it there. i wonder what it's needed for. still with the thing in place, the texturing behaves strange. for example, if i put an object like pix_contrast or pix_add in it's way, i only see some blue flashing. the flashing seems like one pixel of the texture magnified to the whole surface. so i thought it's the texture coordinates and i tried pix_coordinates to correct them without success. then the texture won't display on pix_draw at all, which is fine, i can live without it. pix_flip doesn't do anything but it doesn't screw up the texture. when i use the output of the rectangle_multitexture example i have basically the same effects slightly different in some cases. maybe i'm missing something obvious, i have tried a lot and i will continue to look, but if someone knows more about this i'd be happy with some explanations. thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
hey there again, i basically got my shader running, it was a bit of a challenge, because i realized i had to use rectangle texunits, as the input is classic 4:3 video frames. so fine, i did this, but now the output of pix_progam is acting kind of weird. it seems to be a proper pix structure, when i attach a pix_info to it, it's the correct resolution and type. it is possible that it is still an bug in my shader, but for instance i see in the example patch 06.rectangle_multitexture that there is a pix_set right after the pix_program and also in my patch things dont work correctly when i don't put it there. i wonder what it's needed for. still with the thing in place, the texturing behaves strange. for example, if i put an object like pix_contrast or pix_add in it's way, i only see some blue flashing. the flashing seems like one pixel of the texture magnified to the whole surface. so i thought it's the texture coordinates and i tried pix_coordinates to correct them without success. then the texture won't display on pix_draw at all, which is fine, i can live without it. pix_flip doesn't do anything but it doesn't screw up the texture. when i use the output of the rectangle_multitexture example i have basically the same effects slightly different in some cases. maybe i'm missing something obvious, i have tried a lot and i will continue to look, but if someone knows more about this i'd be happy with some explanations. thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-25 18:07, u...@xdv.org wrote: i did give the --with-pd option as ../pd/src so ./configure did not complain in the first place. weirdly now trying to reproduce it, libtool says, it can't determine the absolute directory name. i swear, that wasn't there before. :D ah yes; afaik, this is a known limitation of autotools: you should never give any paths as relative paths, always use absolute paths! the reason is simple: all makefiles generated by autoconf will have the include path for Pd expanded to ../pd/src; while this makes sense in the top-level directory, it will expand to non-existant paths in subdirectories (e.g. in ...gem/src/plugins it will expand to ...gem/src/pd/src) this also explains a small mystery: Gem's configure will stop if it doesn't find the pd sources; unfortunately it did find them at the relative path, but could not use them from within the subdirectories! fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ua3MACgkQkX2Xpv6ydvQ1OgCg3bjUMQP49/gonPJvyIe8V+4X KXwAoLeeBApVdYN/MHioQ+spFFBc5eND =GF4m -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-24 17:05, u...@xdv.org wrote: i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 there are some known problems with shaderID-t_float mapping on 64bit systems which are fixed in current trunk. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4tGqUACgkQkX2Xpv6ydvSwegCfaypYb6WrjNqSiXW+VvlHGnic b18AnREwHAd5WUOon93VsiyJt66/7RuR =ljOB -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
hey there, On 25.07.2011 09:26, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-24 17:05, u...@xdv.org wrote: i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 there are some known problems with shaderID-t_float mapping on 64bit i thought at some point one should leave the 32bit comfort zone. systems which are fixed in current trunk. ok, i did the svn update, but now i can't build Gem anymore. make fails pretty soon, saying: Dylib.cpp: In function ‘std::string getFullfilename(const _glist*, const char*, const char*)’: Dylib.cpp:157: error: ‘canvas_open’ was not declared in this scope svn log tells me these files have been worked on recently, so it might not be entirely my ignorance. thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-25 14:51, u...@xdv.org wrote: hey there, On 25.07.2011 09:26, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-24 17:05, u...@xdv.org wrote: i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 there are some known problems with shaderID-t_float mapping on 64bit i thought at some point one should leave the 32bit comfort zone. systems which are fixed in current trunk. ok, i did the svn update, but now i can't build Gem anymore. make fails pretty soon, saying: Dylib.cpp: In function ?std::string getFullfilename(const _glist*, const char*, const char*)?: Dylib.cpp:157: error: ?canvas_open? was not declared in this scope svn log tells me these files have been worked on recently, so it might not be entirely my ignorance. indeed :-) however, i have the feeling, that your compiler simply cannot find m_pd.h (and you did not give us the full error message that would have said that) i don't know where pd-extended puts its headers, you might try something like: $ ./configure --with-pd=/usr/include/pdextended/ and don't forget, that now the entire build process is in ...gem/ rather than ...gem/src/ fg amsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4taeoACgkQkX2Xpv6ydvQ17wCeISbbrgobcVqyFHw5YbWGQ/Qz pGMAoMkjWAnw2p0sV6eg/4F4k2NHqUfC =POHf -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
On 25.07.2011 15:04, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-25 14:51, u...@xdv.org wrote: hey there, On 25.07.2011 09:26, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-24 17:05, u...@xdv.org wrote: i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 there are some known problems with shaderID-t_float mapping on 64bit i thought at some point one should leave the 32bit comfort zone. systems which are fixed in current trunk. ok, i did the svn update, but now i can't build Gem anymore. make fails pretty soon, saying: Dylib.cpp: In function ?std::string getFullfilename(const _glist*, const char*, const char*)?: Dylib.cpp:157: error: ?canvas_open? was not declared in this scope svn log tells me these files have been worked on recently, so it might not be entirely my ignorance. indeed :-) however, i have the feeling, that your compiler simply cannot find m_pd.h (and you did not give us the full error message that would have said that) i did give the --with-pd option as ../pd/src so ./configure did not complain in the first place. weirdly now trying to reproduce it, libtool says, it can't determine the absolute directory name. i swear, that wasn't there before. :D i don't know where pd-extended puts its headers, you might try something like: $ ./configure --with-pd=/usr/include/pdextended/ anyway ... it did compile, it did install, the shader examples work and my shader also more or less works. joo! and don't forget, that now the entire build process is in ...gem/ rather than ...gem/src/ saw that. :) thanks for the help! ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Gem / glsl_fragment
hey there, i'm trying to implement a hard-light blending mode, as described on between two textures using a glsl fragment shader. it's compiling, linking and running fine in ShaderMaker. when i try to load it with [glsl_fragment] i don't seem to be getting an ID on the right outlet though. it never changes from [ 0] which i take to mean failure in some way. the same happens, by the way, with the shaders, both vertex and fragment, that come in example/data. a print message on glsl_fragment produces: [glsl_fragment]: [glsl_fragment]: MAX_FRAGMENT_UNIFORM_COMPONENTS: 2048 [glsl_fragment]: MAX_TEXTURE_COORDS: 8 [glsl_fragment]: MAX_TEXTURE_IMAGE_UNITS: 32 seems to be telling me, glsl support is acknowledged to be there. i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 with corporate nvidia driver, version: 260.19.44 any ideas anyone? and then i have another question: if i manage to run the shader, how would i throw the two textures to their respective 2Dsamplers in there? prefix [pix_dump] output with the samplers name? thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem / glsl_fragment
Hello, First, let's try to have the example to work. did you have any error when clicking on the load shader bang on the 1st example (01.simple texture)? for multi texture example, see example 5... Cyrille Le 24/07/2011 17:05, u...@xdv.org a écrit : hey there, i'm trying to implement a hard-light blending mode, as described on between two textures using a glsl fragment shader. it's compiling, linking and running fine in ShaderMaker. when i try to load it with [glsl_fragment] i don't seem to be getting an ID on the right outlet though. it never changes from [ 0] which i take to mean failure in some way. the same happens, by the way, with the shaders, both vertex and fragment, that come in example/data. a print message on glsl_fragment produces: [glsl_fragment]: [glsl_fragment]: MAX_FRAGMENT_UNIFORM_COMPONENTS: 2048 [glsl_fragment]: MAX_TEXTURE_COORDS: 8 [glsl_fragment]: MAX_TEXTURE_IMAGE_UNITS: 32 seems to be telling me, glsl support is acknowledged to be there. i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 with corporate nvidia driver, version: 260.19.44 any ideas anyone? and then i have another question: if i manage to run the shader, how would i throw the two textures to their respective 2Dsamplers in there? prefix [pix_dump] output with the samplers name? thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
