batchku

i'm trying to use a jit.gl.mesh to draw a plane with an image as texture, and i'm trying to use a glsl script to change the verteces of this plane based on a jitter matrix that i bring into my script as the 'tangent array".

1) i find that my plane must be the same dimentions as my texture matrix; if not, i don't see the full image but only as many pixels as my planes dimensionality. when i use somethin like jit.gl.videoplane, on the other hand, my plane can be a much lower dimension than my image and i still see all the image. why?

2) what should be dimensions and plane-count of the textcoord array, the normal array, specular array..... ?

3) i find that when i use the two "thru" vertex/fragment programs in the "share" folder:

4) when i use these two scripts i found after some research:

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

vec4 color = texture2DRect(tex0, gl_TexCoord[0].st);

then i get my plane drawn, but it's all black. i'm trying to give jit.gl.mesh a texture from the outside with the "texture" messages to its first inlet. my texture is an jitter matrix with the same dims as my plane. is that the way?

without using a programmable shader,
1)  i find that my plane must be the same dimentions as my texture matrix;  if not, i don't see the full image but only as many pixels as my planes dimensionality.  when i use somethin like jit.gl.videoplane, on the other hand, my plane can be a much lower dimension than my image and i still see all the image.  why?

2)  what should be dimensions and plane-count of the textcoord array, the normal array, specular array..... ? 

now, with using a glsl shader:
3)  i find that when i use the two "thru" vertex/fragment programs in the "share" folder:

sh.passthru.color.fp.glsl
sh.passthru.xform.vp.glsl

4)  when i use these two scripts i found after some research:

    gl_TexCoord[0] = gl_MultiTexCoord0;
       gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

void main (void)
{
 vec4 color = texture2DRect(tex0, gl_TexCoord[0].st);
 gl_FragColor = color;
}

then i get my plane drawn, but it's all black.  i'm trying to give jit.gl.mesh a texture from the outside with the "texture" messages to its first inlet.  my texture is an jitter matrix with the same dims as my plane.  is that the way?

some-questions-about-jit-gl-mesh

The texcoord matrix input to jit.gl.mesh is 2 planes, and it expects 

normalized values (0.-1.) for texture coordinates. jit.expr @expr 

norm[0] norm[1] will give you a texcoord matrix that is basically what 

you would get with jit.gl.videoplane. Note that the dimensions of all of 

your jit.gl.mesh inputs should be the same. See example patch below.

See the Jitter OpenGL documentation for more info about the breakdown of 

plane numbers. (Appendix C? I can't remember off the top of my head).

What you're trying to do with the shader is going to require more than a 

cursory knowledge of GLSL. I wouldn't recommend diving too deep into it 

without grabbing a copy of the GLSL orange book.

Truth be told, I'm not sure I understand why you aren't just 

manipulating the vertex matrix using MOPs. You might also look at the 

td.repos.jxs shader if you are simply trying to manipulate the texture 

image. It's hard to speculate on any of this without a better idea of 

Hey Ali,
The texcoord matrix input to jit.gl.mesh is 2 planes, and it expects 
normalized values (0.-1.) for texture coordinates.  jit.expr @expr 
norm[0] norm[1] will give you a texcoord matrix that is basically what 
you would get with jit.gl.videoplane. Note that the dimensions of all of 
your jit.gl.mesh inputs should be the same.  See example patch below.

See the Jitter OpenGL documentation for more info about the breakdown of 
plane numbers. (Appendix C? I can't remember off the top of my head).

What you're trying to do with the shader is going to require more than a 
cursory knowledge of GLSL.  I wouldn't recommend diving too deep into it 
without grabbing a copy of the GLSL orange book.
Truth be told, I'm not sure I understand why you aren't just 
manipulating the vertex matrix using MOPs.  You might also look at the 
td.repos.jxs shader if you are simply trying to manipulate the texture 
image. It's hard to speculate on any of this without a better idea of 
what you're trying to accomplish.

On Aug 26, 2006, at 4:41 AM, Ali Momeni wrote:

> 1) i find that my plane must be the same dimentions as my texture 

> matrix; if not, i don't see the full image but only as many pixels 

> as my planes dimensionality. when i use somethin like 

> jit.gl.videoplane, on the other hand, my plane can be a much lower 

> dimension than my image and i still see all the image. why?

Difficult to speculate without example. It sounds like for some 

reason you're not giving texture coordinates from 0.-1, or you're no 

providing enough cells for one of your jit.gl.mesh input matrices.

> 2) what should be dimensions and plane-count of the textcoord 

> array, the normal array, specular array..... ?

Dimensions of *all* matrix input to jit.gl.mesh should always be the 

same. With the exception of the index matrix.

> then i get my plane drawn, but it's all black. i'm trying to give 

> jit.gl.mesh a texture from the outside with the "texture" messages 

> to its first inlet. my texture is an jitter matrix with the same 

Too hard to speculate without a complete example (you really need to 

get better at providing clear and complete information for people to 

help you, otherwise we're just going to start ignoring your emails, 

Ali). Why aren't you using Wesley's patch and shader as a starting 

>
> without using a programmable shader,
> 1)  i find that my plane must be the same dimentions as my texture  
> matrix;  if not, i don't see the full image but only as many pixels  
> as my planes dimensionality.  when i use somethin like  
> jit.gl.videoplane, on the other hand, my plane can be a much lower  
> dimension than my image and i still see all the image.  why?

Difficult to speculate without example. It sounds like for some  
reason you're not giving texture coordinates from 0.-1, or you're no  
providing enough cells for one of your jit.gl.mesh input matrices.

> 2)  what should be dimensions and plane-count of the textcoord  
> array, the normal array, specular array..... ?

Dimensions of *all* matrix input to jit.gl.mesh should always be the  
same. With the exception of the index matrix.

- vertex: 2 -3 planes (x,y,z)
- texcoord: 1-4 planes (s,t,r,q)
- normal: 3 plane (nx,ny,nz)
- color: 3 or 4 planes (r,g,b,a)
- specular: 4 planes (r,g,b,a)
- edgeflag: 1 plane (on/off)
- tangent: 4 planes (tx,ty,tz,tw)
- bitangent: 4 planes (bx,by,bz,bw)
- index: 1 plane (vertex index)

> then i get my plane drawn, but it's all black.  i'm trying to give  
> jit.gl.mesh a texture from the outside with the "texture" messages  
> to its first inlet.  my texture is an jitter matrix with the same  
> dims as my plane.  is that the way?

Too hard to speculate without a complete example (you really need to  
get better at providing clear and complete information for people to  
help you, otherwise we're just going to start ignoring your emails,  
Ali). Why aren't you using Wesley's patch and shader as a starting  
point? It should work fine.

thanks for the answers andrew and joshua.

actually, joshua, that's just what i did. i started with wes' patch and shaders, and i began to adjust it to do what i need and i ran into various questions that i didn't find answers to in the jit.gl.mesh html reference or the forum so i posted my questions.

thanks for the answers andrew and joshua.
actually, joshua, that's just what i did.  i started with wes' patch and shaders, and i began to adjust it to do what i need and i ran into various questions that i didn't find answers to in the jit.gl.mesh html reference or the forum so i posted my questions.


i'm not trying to apply what i learned from andrew's patch about placeing a texture on a geometry with jit.gl.mesh, and wes's patches and applying shaders, in order to get a texture rendered on a geometry that has a programmable shader applied.

i'm able to get the texture on the geometry following andrew's patch; but when i tell jit.gl.mesh to use a shader (wes's), i loose the texture; i assume it's because the texture isn't explicitly passed thru within wes's script. but i'm still not clear on how to access the matrices that entire jit.gl.mesh's inlets within my glsl script.

i'm also uncertain about the difference between passing a texture to jit.gl.mesh using the "texture" or "jit_gl_textures" messages, as opposed to it's color matrix input which can serve the same ends.

---------------.jxs file named "vd.attr2.jxs"

    Textured glass-like material lit with a point light w/ two specular components calculated per pixel.

        Primary Specular Multiplier

        Secondary Specular Multiplier

i'm not trying to apply what i learned from andrew's patch about placeing a texture on a geometry with jit.gl.mesh, and wes's patches and applying shaders, in order to get a texture rendered on a geometry that has a programmable shader applied.  

i'm able to get the texture on the geometry following andrew's patch; but when i tell jit.gl.mesh to use a shader (wes's), i loose the texture; i assume it's because the texture isn't explicitly passed thru within wes's script.  but i'm still not clear on how to access the matrices that entire jit.gl.mesh's inlets within my glsl script.  

	Textured glass-like material lit with a point light w/ two specular components calculated per pixel.
		Position of Light Source
		Position
		Tangent
		Primary Specular Color
		Secondary Specular Color
		Base Color
		Primary Specular Multiplier
		Secondary Specular Multiplier
		Specularity Adjustment

No offense, but do you actually <> the emails we've been sending

you? If you look at the top of the email that I posted the inital

vertex displacement shader patch in, you would find this list:

> These are the state variables that you can bind vertex shader

> attributes to. The correspond precisely to their jit.gl.mesh's

Now, if you look at my original shader it's simple matter to access

the input matrices to jit.gl.mesh using these values instead of

> i'm able to get the texture on the geometry following andrew's patch; but when i tell jit.gl.mesh to > use a shader (wes's), i loose the texture; i assume it's because the texture isn't explicitly passed > thru within wes's script. but i'm still not clear on how to access the matrices that entire

> jit.gl.mesh's inlets within my glsl script.

As I think Andrew suggested, you need to take a look at a book or

website or something on shaders. Textures need to be explicity

applied by the fragment shader to ane any effect. May I politely

suggest you read the orangebook or something similar to familiarize

yourself with the programmable GPU pipeline. There are also a

bajillion shader examples that do texture access. It should be

straightforward to add this to the shader.

> i'm also uncertain about the difference between passing a texture to jit.gl.mesh using the

> "texture" or "jit_gl_textures" messages, as opposed to it's color matrix input which can serve the

jit_gl_texture and @texture are exactly the same thing. The color

matrix and textures are completely different. For more on this, see

http://www.opengl.org/documentation/specs/version1.1/glspec1.1/node21.html

jit.gl.mesh uses glVertexPointer and related methods for doing its

thing. glColorPointer is very very different than textures.

Ali,
No offense, but do you actually <> the emails we've been sending
you?  If you look at the top of the email that I posted the inital
vertex displacement shader patch in, you would find this list:

> These are the state variables that you can bind vertex shader
> attributes to.  The correspond precisely to their jit.gl.mesh's
> namesake.:

> "POSITION"
> "NORMAL"
> "TANGENT"
> "BITANGENT"
> "TEXCOORD"

Now, if you look at my original shader it's simple matter to access
the input matrices to jit.gl.mesh using these values instead of
TANGENT like I had done.

> i'm able to get the texture on the geometry following andrew's patch; but when i tell jit.gl.mesh to > use a shader (wes's), i loose the texture; i assume it's because the texture isn't explicitly passed > thru within wes's script.  but i'm still not clear on how to access the matrices that entire
> jit.gl.mesh's inlets within my glsl script.

As I think Andrew suggested, you need to take a look at a book or
website or something on shaders.  Textures need to be explicity
applied by the fragment shader to ane any effect.  May I politely
suggest you read the orangebook or something similar to familiarize
yourself with the programmable GPU pipeline.  There are also a
bajillion shader examples that do texture access.  It should be
straightforward to add this to the shader.

> i'm also uncertain about the difference between passing a texture to jit.gl.mesh using the
> "texture" or "jit_gl_textures" messages, as opposed to it's color matrix input which can serve the
> same ends.

jit_gl_texture and @texture are exactly the same thing.  The color
matrix and textures are completely different.  For more on this, see
this page:

jit.gl.mesh uses glVertexPointer and related methods for doing its
thing.  glColorPointer is very very different than textures.

On Aug 26, 2006, at 11:57 PM, Ali Momeni wrote:

> there are plenty of people asking basic and obvious questions on 

> the cycling forum. if at anypoint something is so far below your 

> level of expertise that a respond to the question is going to be 

> tinged with antagonism instead of compassion, then perhaps you 

What is under discussion here is that you ask questions (which are in 

no way below our level of expertise), that we would be happy to 

answer, but that you consistently ask the questions in such a way 

that we need to send several emails back and forth to actually figure 

out what you're doing. This is frustrating for us (and frustrating 

It really is important to provide clear and complete information so 

that anyone (not just us) can answer your questions intelligently. 

Not to single you out, as there are many users that do this (I would 

like to stress to everyone to provide this sort of information), 

however, I would expect at this point, you would know to provide this 

kind of information in the first message.

I'm not trying to berate you as a person, or the fundamental nature 

of any of the questions you ask. Just that you do so in a way that 

requires much more work on all of our parts (yours and ours).

> there are plenty of people asking basic and obvious questions on  
> the cycling forum.  if at anypoint something is so far below your  
> level of expertise that a respond to the question is going to be  
> tinged with antagonism instead of compassion, then perhaps you  
> should simply refrain from responding.

What is under discussion here is that you ask questions (which are in  
no way below our level of expertise), that we would be happy to  
answer, but that you consistently ask the questions in such a way  
that we need to send several emails back and forth to actually figure  
out what you're doing. This is frustrating for us (and frustrating  
for you).

It really is important to provide clear and complete information so  
that anyone (not just us) can answer your questions intelligently.  
Not to single you out, as there are many users that do this (I would  
like to stress to everyone to provide this sort of information),  
however, I would expect at this point, you would know to provide this  
kind of information in the first message.

I'm not trying to berate you as a person, or the fundamental nature  
of any of the questions you ask. Just that you do so in a way that  
requires much more work on all of our parts (yours and ours).

some questions about jit.gl.mesh