some questions about jit.gl.mesh


    Aug 26 2006 | 11:41 am
    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

    • Aug 26 2006 | 8:28 pm
      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.
    • Aug 26 2006 | 9:01 pm
      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
    • Aug 27 2006 | 5:45 am
      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.
    • Aug 27 2006 | 6:18 am
      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:
      ----------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
    • Aug 27 2006 | 6:41 am
      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
    • Aug 27 2006 | 6:57 am
    • Aug 27 2006 | 10:10 pm
      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