some questions about jit.gl.mesh

batchku's icon

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".

i have a number of questions.

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

i no longer see anything rendered.

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

///vertext
void main()
{

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

}

///fragment
uniform sampler2DRect tex0;

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?

thanks in advance....

a

Andrew Benson's icon

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.

Andrew B.

Max Patch
Copy patch and select New From Clipboard in Max.

Joshua Kit Clayton's icon

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

>
> 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.

Planecount is as follows:

- 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.

-Joshua

batchku's icon

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.

batchku's icon

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.

patch and script are below:

Max Patch
Copy patch and select New From Clipboard in Max.

----------patch

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

    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

Wesley Smith's icon

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.

wes

batchku's icon
Joshua Kit Clayton's icon

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
> 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).

-Joshua