[PD] gem/GLSL: how to compute correct coordinates for rectangular textures

Jack jack at rybn.org
Tue Jan 5 12:37:24 CET 2010


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 at iem.at mailing list
> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > 
> > 
> > 
> 
> 






More information about the Pd-list mailing list