Hi,
The subject resembles very much that of one recent message of mine but
it is NOT the same.
I think it's better to start a new thread because the previous one was
erroneously focused on rectangle textures: I was suggested to use them
to solve a problem I mentioned, and though I do appreciate very much the
suggestion, it actually pointed me to the wrong direction.
So, I have learned that when you use an image as a texture (be it loaded
from file, generated by camera input or by a pixsnap), the texture
internally has power-of-two dimensions greater than or equal to the
actual dimensions of the image, the rest being padded with black or
something.
Then, I've seen that even if I use a shader, I usually don't have to
worry about that IF the [pix_image] (or [pix_video] or whatever) that
generates the image is in the same "line" (of left-inlet connections) as
the [pix_texture] and the [glsl_program].
That is, when in the shader I use gl_TexCoord[0].st to sample the
texture, I get the right coordinates.
So, the "01 simple texture" patch in the example folder works fine with
non-power-of-two-sized images with no need to be changed, and without
using rectangular texture mode.
However, as the attached patch shows, this is no more true if I use a
uniform variable to tell the shader to use a given texture unit N, which
correspond to some [pix_texture] object which is connected to another
separate [gemhead] and which has been sent a [texunit N( message.
So what I understand is that [pix_image] (or any object that creates a
pix and translates it into a texture) takes care of it by doing some
kind of "OpenGL magic" so that the texture coordinates being "passed" to
the shader are OK with no need to take care of that in the shader code.
The aritmetical part of this "magic" is indeed as simple as computing a
scale factor of W/Nw for width and H/Nh for height, where W and H are
width and height, and Nw and Nh are the next power of two equal to or
greater than W and H respectively.
The question is, what's the best way (if there is any) to "reproduce"
the magic that the pix objects do, in order to "pre-compute" this scale
factor and have the shader "receive" correctly 'normalized' coordinates?
I mean, I can calculate the scaling factor and pass it through a uniform
variable to the shader, and have the shader use it to rescale the
coordinates. This will work fine, but it seems (to me) that [pix_image]
and other pix objects are able to do this kind of rescaling somehow
_before_ the shader gets in action, since you don't need to change the
shader code if such an object (which is generating the image) is present
in the chain.
I hope I have explained the question clearly.
The attached patch shows the problem quite well I think. I don't attach
the images to avoid flooding mailboxes; any non-power-of-two different
sized images with those names will do; by the way I have attached them
in a recent message of mine.
Compare the behaviour to that of example 01 of the GLSL example folder:
even with a non-pot-sized image, that example works fine.
Note that no rectangular textures are involved. Rectangular textures
won't help (indeed I think it gets more complicated): I have the same
problem because I need to "tell" the shader the actual size of the
texture it has to use.
Thanks a lot in advance
m.
P.S. though I can't promise it, it's almost sure that I will post and
share the final patches, for what it's worth; but I can't do it yet.
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
uniform sampler2D curtex;
void main (void)
{
vec2 xy=gl_TexCoord[0].st;
vec4 frontcolor = texture2D(curtex, xy);
gl_FragColor = frontcolor;
}
// Cyrille Henry 2007
void main()
{
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_Position = ftransform();
}
#N canvas 399 97 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 187 69 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 obj 348 384 loadbang;
#X obj 762 53 loadbang;
#X obj 60 600 square 4;
#X obj 565 383 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 msg 136 99 open trivialshader_norec.vert;
#X msg 114 259 open trivialshader_norec.frag;
#X obj 584 313 gemhead 23;
#X obj 587 495 pix_texture;
#X msg 595 457 texunit 2;
#X obj 185 42 loadbang;
#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 11 0;
#X connect 9 1 19 0;
#X connect 10 0 9 0;
#X connect 11 0 23 0;
#X connect 12 0 31 0;
#X connect 12 0 32 0;
#X connect 13 0 20 0;
#X connect 14 0 25 0;
#X connect 16 0 15 0;
#X connect 18 0 26 0;
#X connect 20 0 3 0;
#X connect 21 0 27 0;
#X connect 22 0 28 0;
#X connect 22 0 16 0;
#X connect 22 0 35 0;
#X connect 24 0 34 0;
#X connect 25 0 15 0;
#X connect 26 0 17 0;
#X connect 27 0 11 0;
#X connect 28 0 17 0;
#X connect 29 0 30 0;
#X connect 30 0 9 0;
#X connect 31 0 3 0;
#X connect 32 0 4 0;
#X connect 33 0 24 0;
#X connect 35 0 34 0;
#X connect 36 0 12 0;
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
