Re: [PD] gem/GLSL: how to compute correct coordinates for rectangular textures
Jack escribió:
What about [pix_resize] after [pix_image] ?
Well I don't want to actually resize any image (i.e. actually modify
pixel data).
But maybe you mean one [pìx_resize] after the [pix_image] of the left
(not the ones on the right), resizing it with the size of the images
on the right, those actually used as textures, so the image on the left
would serve as a dummy image just to have the shader get the correct
coordinates.
That may do the trick, however I will always need a dummy image. Is
there a way to just _set_ the image size without having any image?
thanks
m.
Jack escribió:
Le dimanche 03 janvier 2010 à 21:17 +0100, Matteo Sisti Sette a écrit :
Hi,
I guess if I had a deep understanding of openGL I could find the answer,
but I am obviously looking for a shortcut (at the moment) to solve the
specific problem I'm facing which should be pretty simple.
In the attached patch I try to use a trivial shader to texture a
rectangle with an image; the uniform variable curtex tells the shader
which texture to use.
It works fine if all images have the same size; however, if the textures
have different sizes, no matter the value of curtex, the texture
coords that are computed are correct for the image loaded by the
[pix_image] that immediately follows the [glsl_program], but are not
correct for other images.
So the question is: how should I change the vertex and/or fragment
shader code (or the patch maybe) so that the texture coordinates are
computed according to the dimensions of the texture that is actually
sampled?
It is important to NOT assume that the textures come from [pix_image]
objects, or at least, that they are loaded from image files: actually,
in real life, textures may be the video input generated by a [pix_film]
or an image captured by a [pix_snap].
What about [pix_resize] after [pix_image] ?
++
Jack
Thanks a lot in advance
pièce jointe document texte brut (trivialshader.frag)
// porcodio
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect curtex;
void main (void)
{
vec2 xy=gl_TexCoord[0].st;
vec4 frontcolor = texture2DRect(curtex, xy);
gl_FragColor = frontcolor;
}
pièce jointe document texte brut (test_trivial_shader.pd)
#N canvas 443 93 925 656 12;
#X obj 441 576 gemwin;
#X msg 437 515 create \, 1;
#X msg 484 547 destroy;
#X obj 58 177 glsl_vertex;
#X obj 59 313 glsl_fragment;
#X obj 143 211 change;
#X obj 160 342 change;
#X obj 155 385 t b f;
#X obj 153 418 pack 0 0;
#X obj 60 490 glsl_program;
#X msg 154 454 link \$1 \$2;
#X obj 60 567 pix_texture;
#X obj 188 24 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 69 33 gemhead 50;
#X obj 508 77 gemhead 23;
#X obj 511 259 pix_texture;
#X msg 519 221 texunit 1;
#X obj 664 260 pix_texture;
#X obj 661 78 gemhead 24;
#X floatatom 212 525 5 0 0 0 - - -;
#X obj 70 60 t a a;
#X msg 349 409 rectangle 1;
#X obj 348 384 loadbang;
#X msg 757 119 rectangle 1;
#X obj 762 53 loadbang;
#X msg 136 99 open trivialshader.vert;
#X msg 114 259 open trivialshader.frag;
#X obj 60 600 square 4;
#X obj 46 528 pix_image img1_.jpg;
#X obj 506 163 pix_image img2_.jpg;
#X obj 659 164 pix_image img3_.jpg;
#X msg 278 474 texunit 2;
#X msg 672 222 texunit 0;
#X floatatom 253 333 5 0 0 0 - - -;
#X msg 229 387 curtex \$1;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 3 0 4 0;
#X connect 3 1 5 0;
#X connect 4 0 9 0;
#X connect 4 1 6 0;
#X connect 5 0 8 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 7 1 8 1;
#X connect 8 0 10 0;
#X connect 9 0 28 0;
#X connect 9 1 19 0;
#X connect 10 0 9 0;
#X connect 11 0 27 0;
#X connect 12 0 25 0;
#X connect 12 0 26 0;
#X connect 13 0 20 0;
#X connect 14 0 29 0;
#X connect 16 0 15 0;
#X connect 18 0 30 0;
#X connect 20 0 3 0;
#X connect 21 0 11 0;
#X connect 22 0 21 0;
#X connect 22 0 31 0;
#X connect 23 0 17 0;
#X connect 23 0 15 0;
#X connect 24 0 23 0;
#X connect 24 0 32 0;
#X connect 24 0 16 0;
#X connect 25 0 3 0;
#X connect 26 0 4 0;
#X connect 28 0 11 0;
#X connect 29 0 15 0;
#X connect 30 0 17 0;
#X connect 31 0 11 0;
#X connect 32 0 17 0;
#X connect 33 0 34 0;
#X connect 34 0 9 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] gem/GLSL: how to compute correct coordinates for rectangular textures
Le mardi 05 janvier 2010 à 12:20 +0100, Matteo Sisti Sette a écrit :
Jack escribió:
What about [pix_resize] after [pix_image] ?
Well I don't want to actually resize any image (i.e. actually modify
pixel data).
But maybe you mean one [pìx_resize] after the [pix_image] of the left
(not the ones on the right), resizing it with the size of the images
on the right, those actually used as textures, so the image on the left
would serve as a dummy image just to have the shader get the correct
coordinates.
That may do the trick, however I will always need a dummy image. Is
there a way to just _set_ the image size without having any image?
[pix_set] ?
You have an example in examples Gem glsl 06.framebuffer_and_shader
++
Jack
thanks
m.
Jack escribió:
Le dimanche 03 janvier 2010 à 21:17 +0100, Matteo Sisti Sette a écrit :
Hi,
I guess if I had a deep understanding of openGL I could find the answer,
but I am obviously looking for a shortcut (at the moment) to solve the
specific problem I'm facing which should be pretty simple.
In the attached patch I try to use a trivial shader to texture a
rectangle with an image; the uniform variable curtex tells the shader
which texture to use.
It works fine if all images have the same size; however, if the textures
have different sizes, no matter the value of curtex, the texture
coords that are computed are correct for the image loaded by the
[pix_image] that immediately follows the [glsl_program], but are not
correct for other images.
So the question is: how should I change the vertex and/or fragment
shader code (or the patch maybe) so that the texture coordinates are
computed according to the dimensions of the texture that is actually
sampled?
It is important to NOT assume that the textures come from [pix_image]
objects, or at least, that they are loaded from image files: actually,
in real life, textures may be the video input generated by a [pix_film]
or an image captured by a [pix_snap].
What about [pix_resize] after [pix_image] ?
++
Jack
Thanks a lot in advance
pièce jointe document texte brut (trivialshader.frag)
// porcodio
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect curtex;
void main (void)
{
vec2 xy=gl_TexCoord[0].st;
vec4 frontcolor = texture2DRect(curtex, xy);
gl_FragColor = frontcolor;
}
pièce jointe document texte brut (test_trivial_shader.pd)
#N canvas 443 93 925 656 12;
#X obj 441 576 gemwin;
#X msg 437 515 create \, 1;
#X msg 484 547 destroy;
#X obj 58 177 glsl_vertex;
#X obj 59 313 glsl_fragment;
#X obj 143 211 change;
#X obj 160 342 change;
#X obj 155 385 t b f;
#X obj 153 418 pack 0 0;
#X obj 60 490 glsl_program;
#X msg 154 454 link \$1 \$2;
#X obj 60 567 pix_texture;
#X obj 188 24 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 69 33 gemhead 50;
#X obj 508 77 gemhead 23;
#X obj 511 259 pix_texture;
#X msg 519 221 texunit 1;
#X obj 664 260 pix_texture;
#X obj 661 78 gemhead 24;
#X floatatom 212 525 5 0 0 0 - - -;
#X obj 70 60 t a a;
#X msg 349 409 rectangle 1;
#X obj 348 384 loadbang;
#X msg 757 119 rectangle 1;
#X obj 762 53 loadbang;
#X msg 136 99 open trivialshader.vert;
#X msg 114 259 open trivialshader.frag;
#X obj 60 600 square 4;
#X obj 46 528 pix_image img1_.jpg;
#X obj 506 163 pix_image img2_.jpg;
#X obj 659 164 pix_image img3_.jpg;
#X msg 278 474 texunit 2;
#X msg 672 222 texunit 0;
#X floatatom 253 333 5 0 0 0 - - -;
#X msg 229 387 curtex \$1;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 3 0 4 0;
#X connect 3 1 5 0;
#X connect 4 0 9 0;
#X connect 4 1 6 0;
#X connect 5 0 8 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 7 1 8 1;
#X connect 8 0 10 0;
#X connect 9 0 28 0;
#X connect 9 1 19 0;
#X connect 10 0 9 0;
#X connect 11 0 27 0;
#X connect 12 0 25 0;
#X connect 12 0 26 0;
#X connect 13 0 20 0;
#X connect 14 0 29 0;
#X connect 16 0 15 0;
#X connect 18 0 30 0;
#X connect 20 0 3 0;
#X connect 21 0 11 0;
#X connect 22 0 21 0;
#X connect 22 0 31 0;
#X connect 23 0 17 0;
#X connect 23 0 15 0;
#X connect 24 0 23 0;
#X connect 24 0 32 0;
#X connect 24 0 16 0;
#X connect 25 0 3 0;
#X connect 26 0 4 0;
#X connect 28 0 11 0;
#X connect 29 0 15 0;
#X connect 30 0 17 0;
#X connect 31 0 11 0;
#X connect 32 0 17 0;
#X connect 33 0 34 0;
#X connect 34 0 9 0;
___
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: how to compute correct coordinates for rectangular textures
Jack escribió: [pix_set] ? You have an example in examples Gem glsl 06.framebuffer_and_shader ++ Thanks a lot, that should do the trick. Both with and without rectangle mode I think (have to try though). Now how could I set sizes for multiple textures, that is for example, how would you modify the 05 multitexture example in the 10 glsl folder in order to work correctly with images of different (non-power-of-two) sizes? (not necessarily with rectangular textures) Whether rectangle mode is active or not, you would need separate texture coordinates for the two textures. With rectangle mode, because the width and height of the two textures (hence the range of coordinate values) is different. Without rectangular mode, because the ratio between actual dimensions and internal power-of-two dimensions is different. @ Cyrille: I attach this to you too 'cause I guess the multitexture example is yours (most glsl examples are iirc); it would be a suggestion to improve it so it works with images of different sizes. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gem/GLSL: how to compute correct coordinates for rectangular textures
Matteo Sisti Sette a écrit : Jack escribió: [pix_set] ? You have an example in examples Gem glsl 06.framebuffer_and_shader ++ Thanks a lot, that should do the trick. Both with and without rectangle mode I think (have to try though). Now how could I set sizes for multiple textures, that is for example, how would you modify the 05 multitexture example in the 10 glsl folder in order to work correctly with images of different (non-power-of-two) sizes? (not necessarily with rectangular textures) unfortunatly, multitexture coordinate does not work with Gem. so you can only use 1st image coordinate. if the other images dos not have the same size, you have to manually adjust the coordinate : in the shader : textcoord1=gl_TexCoord[0].st textcoord2=gl_TexCoord[0].st*coef.xy with : coef.x = size_image2.x/size_image1.x coef.y = size_image2.y/size_image1.y) same for other textures. you can compute coef in the patch using pix_info to get image size or fix it if your images always have the same size. you can also mix rectangulare / not rectangular texture this way, but it is a bit crappy... Whether rectangle mode is active or not, you would need separate texture coordinates for the two textures. With rectangle mode, because the width and height of the two textures (hence the range of coordinate values) is different. Without rectangular mode, because the ratio between actual dimensions and internal power-of-two dimensions is different. @ Cyrille: I attach this to you too 'cause I guess the multitexture example is yours (most glsl examples are iirc); if you want answer for me, you should make shorter mail. i hardly read mail that are longer than 5 or 10 lines. c it would be a suggestion to improve it so it works with images of different sizes. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gem/GLSL: how to compute correct coordinates for rectangular textures
Le dimanche 03 janvier 2010 à 21:17 +0100, Matteo Sisti Sette a écrit :
Hi,
I guess if I had a deep understanding of openGL I could find the answer,
but I am obviously looking for a shortcut (at the moment) to solve the
specific problem I'm facing which should be pretty simple.
In the attached patch I try to use a trivial shader to texture a
rectangle with an image; the uniform variable curtex tells the shader
which texture to use.
It works fine if all images have the same size; however, if the textures
have different sizes, no matter the value of curtex, the texture
coords that are computed are correct for the image loaded by the
[pix_image] that immediately follows the [glsl_program], but are not
correct for other images.
So the question is: how should I change the vertex and/or fragment
shader code (or the patch maybe) so that the texture coordinates are
computed according to the dimensions of the texture that is actually
sampled?
It is important to NOT assume that the textures come from [pix_image]
objects, or at least, that they are loaded from image files: actually,
in real life, textures may be the video input generated by a [pix_film]
or an image captured by a [pix_snap].
What about [pix_resize] after [pix_image] ?
++
Jack
Thanks a lot in advance
pièce jointe document texte brut (trivialshader.frag)
// porcodio
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect curtex;
void main (void)
{
vec2 xy=gl_TexCoord[0].st;
vec4 frontcolor = texture2DRect(curtex, xy);
gl_FragColor = frontcolor;
}
pièce jointe document texte brut (test_trivial_shader.pd)
#N canvas 443 93 925 656 12;
#X obj 441 576 gemwin;
#X msg 437 515 create \, 1;
#X msg 484 547 destroy;
#X obj 58 177 glsl_vertex;
#X obj 59 313 glsl_fragment;
#X obj 143 211 change;
#X obj 160 342 change;
#X obj 155 385 t b f;
#X obj 153 418 pack 0 0;
#X obj 60 490 glsl_program;
#X msg 154 454 link \$1 \$2;
#X obj 60 567 pix_texture;
#X obj 188 24 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 69 33 gemhead 50;
#X obj 508 77 gemhead 23;
#X obj 511 259 pix_texture;
#X msg 519 221 texunit 1;
#X obj 664 260 pix_texture;
#X obj 661 78 gemhead 24;
#X floatatom 212 525 5 0 0 0 - - -;
#X obj 70 60 t a a;
#X msg 349 409 rectangle 1;
#X obj 348 384 loadbang;
#X msg 757 119 rectangle 1;
#X obj 762 53 loadbang;
#X msg 136 99 open trivialshader.vert;
#X msg 114 259 open trivialshader.frag;
#X obj 60 600 square 4;
#X obj 46 528 pix_image img1_.jpg;
#X obj 506 163 pix_image img2_.jpg;
#X obj 659 164 pix_image img3_.jpg;
#X msg 278 474 texunit 2;
#X msg 672 222 texunit 0;
#X floatatom 253 333 5 0 0 0 - - -;
#X msg 229 387 curtex \$1;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 3 0 4 0;
#X connect 3 1 5 0;
#X connect 4 0 9 0;
#X connect 4 1 6 0;
#X connect 5 0 8 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 7 1 8 1;
#X connect 8 0 10 0;
#X connect 9 0 28 0;
#X connect 9 1 19 0;
#X connect 10 0 9 0;
#X connect 11 0 27 0;
#X connect 12 0 25 0;
#X connect 12 0 26 0;
#X connect 13 0 20 0;
#X connect 14 0 29 0;
#X connect 16 0 15 0;
#X connect 18 0 30 0;
#X connect 20 0 3 0;
#X connect 21 0 11 0;
#X connect 22 0 21 0;
#X connect 22 0 31 0;
#X connect 23 0 17 0;
#X connect 23 0 15 0;
#X connect 24 0 23 0;
#X connect 24 0 32 0;
#X connect 24 0 16 0;
#X connect 25 0 3 0;
#X connect 26 0 4 0;
#X connect 28 0 11 0;
#X connect 29 0 15 0;
#X connect 30 0 17 0;
#X connect 31 0 11 0;
#X connect 32 0 17 0;
#X connect 33 0 34 0;
#X connect 34 0 9 0;
___
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
[PD] gem/GLSL: how to compute correct coordinates for rectangular textures
Hi,
I guess if I had a deep understanding of openGL I could find the answer,
but I am obviously looking for a shortcut (at the moment) to solve the
specific problem I'm facing which should be pretty simple.
In the attached patch I try to use a trivial shader to texture a
rectangle with an image; the uniform variable curtex tells the shader
which texture to use.
It works fine if all images have the same size; however, if the textures
have different sizes, no matter the value of curtex, the texture
coords that are computed are correct for the image loaded by the
[pix_image] that immediately follows the [glsl_program], but are not
correct for other images.
So the question is: how should I change the vertex and/or fragment
shader code (or the patch maybe) so that the texture coordinates are
computed according to the dimensions of the texture that is actually
sampled?
It is important to NOT assume that the textures come from [pix_image]
objects, or at least, that they are loaded from image files: actually,
in real life, textures may be the video input generated by a [pix_film]
or an image captured by a [pix_snap].
Thanks a lot in advance
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
// porcodio
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect curtex;
void main (void)
{
vec2 xy=gl_TexCoord[0].st;
vec4 frontcolor = texture2DRect(curtex, xy);
gl_FragColor = frontcolor;
}
#N canvas 443 93 925 656 12;
#X obj 441 576 gemwin;
#X msg 437 515 create \, 1;
#X msg 484 547 destroy;
#X obj 58 177 glsl_vertex;
#X obj 59 313 glsl_fragment;
#X obj 143 211 change;
#X obj 160 342 change;
#X obj 155 385 t b f;
#X obj 153 418 pack 0 0;
#X obj 60 490 glsl_program;
#X msg 154 454 link \$1 \$2;
#X obj 60 567 pix_texture;
#X obj 188 24 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 69 33 gemhead 50;
#X obj 508 77 gemhead 23;
#X obj 511 259 pix_texture;
#X msg 519 221 texunit 1;
#X obj 664 260 pix_texture;
#X obj 661 78 gemhead 24;
#X floatatom 212 525 5 0 0 0 - - -;
#X obj 70 60 t a a;
#X msg 349 409 rectangle 1;
#X obj 348 384 loadbang;
#X msg 757 119 rectangle 1;
#X obj 762 53 loadbang;
#X msg 136 99 open trivialshader.vert;
#X msg 114 259 open trivialshader.frag;
#X obj 60 600 square 4;
#X obj 46 528 pix_image img1_.jpg;
#X obj 506 163 pix_image img2_.jpg;
#X obj 659 164 pix_image img3_.jpg;
#X msg 278 474 texunit 2;
#X msg 672 222 texunit 0;
#X floatatom 253 333 5 0 0 0 - - -;
#X msg 229 387 curtex \$1;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 3 0 4 0;
#X connect 3 1 5 0;
#X connect 4 0 9 0;
#X connect 4 1 6 0;
#X connect 5 0 8 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 7 1 8 1;
#X connect 8 0 10 0;
#X connect 9 0 28 0;
#X connect 9 1 19 0;
#X connect 10 0 9 0;
#X connect 11 0 27 0;
#X connect 12 0 25 0;
#X connect 12 0 26 0;
#X connect 13 0 20 0;
#X connect 14 0 29 0;
#X connect 16 0 15 0;
#X connect 18 0 30 0;
#X connect 20 0 3 0;
#X connect 21 0 11 0;
#X connect 22 0 21 0;
#X connect 22 0 31 0;
#X connect 23 0 17 0;
#X connect 23 0 15 0;
#X connect 24 0 23 0;
#X connect 24 0 32 0;
#X connect 24 0 16 0;
#X connect 25 0 3 0;
#X connect 26 0 4 0;
#X connect 28 0 11 0;
#X connect 29 0 15 0;
#X connect 30 0 17 0;
#X connect 31 0 11 0;
#X connect 32 0 17 0;
#X connect 33 0 34 0;
#X connect 34 0 9 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
