URGENT QUESTION!!!!


    Nov 04 2008 | 6:40 pm
    I've worked with jitter for a long time, and what I cannot understand is why a jit.gl.render requires 3 planes for rendering 3D stuff (x,y,z) vector arranged in a:
    "jit.matrix 3 float32 30 30"
    This is a 3 plane matrix with 30 rows and 30 columns..
    WHY 30 rows and 30 columns having already 3 planes for the 3D vector?
    If I try to render something with 3 planes and just 30 rows it doesn't work... what is this N x M (rows x columns) thing? what is the meaning of this? please explain that to me... I can't end a project because of this abstraction!
    Much much thanks
    Miguel

    • Nov 04 2008 | 6:43 pm
      Joshua, Vade, Yahir, andrewb any of you please help!
    • Nov 04 2008 | 7:20 pm
      On Tue, Nov 4, 2008 at 7:40 PM, Miguel Mesa Perez wrote:
      >
      >
      > I've worked with jitter for a long time, and what I cannot understand is
      > why a jit.gl.render requires 3 planes for rendering 3D stuff (x,y,z) vector
      > arranged in a:
      >
      > "jit.matrix 3 float32 30 30"
      >
      > This is a 3 plane matrix with 30 rows and 30 columns..
      >
      > WHY 30 rows and 30 columns having already 3 planes for the 3D vector?
      >
      > If I try to render something with 3 planes and just 30 rows it doesn't
      > work... what is this N x M (rows x columns) thing? what is the meaning of
      > this? please explain that to me... I can't end a project because of this
      > abstraction!
      >
      I don't know where you get this 30x30 idea from but I don't think there is
      such a requirement. I usually don't render gl from video matrices, but the
      last time I did it was definately not a 30x30 matrix.
      Every cell in a matrix holds a vertex and its additional data. The first 3
      planes are the bare minimum to hold the data for 1 vertex (x y and z). If
      you want to add other info like color and texture coordinates you need to
      use more planes then the first 3. The specification of what planes hold what
      data is somewhere in the jitter reference.
      So a 30x30 matrix would mean you can store data for a maximum of 900
      vertices. There is no such limit afaik. There is a limit to the maximum
      jitter matrix dimensions but that's way higher.
      Quoted from the online jitter sdk:
      *Since Jitter is a general purpose matrix processing framework, it makes
      sense that you would have the ability to pass geometry information through a
      Jitter network as matrices if your geometry is well suited to a matrix
      representation. The cells of your matrix can hold vertex information such as
      position, texture coordinates, normal vectors, color, and edge flags, and
      are documented in the "Geometry Under The Hood" Jitter Tutorial. You also
      have the option of specifying a connections matrix to reference the
      connectivity of the vertices if it is not implicit in the matrix
      representation, and a drawing primitive to use when drawing the vertices.*
      If you've worked with jitter for so long, maybe now is a good time to have a
      look at the documentation ;-)
      Thijs
    • Nov 04 2008 | 7:28 pm
      Hi there,
      If you are sending a matrix directly to jit.gl.render, then by default it is reading the matrix as a "tri_grid", meaning a grid of vertex positions connected as triangles. Without a second dimension, you have no grid. You can try switching the drawing mode of jit.gl.render to try different interpretations (polygon,line_loop,quads, etc.). In general, I would recommend using jit.gl.mesh for this sort of thing, as the interface is a lot more friendly and robust and it provides a lot more sensible options. As always, we're going to be much more help if you post a specific patch that is giving you trouble. It is quite a bit more time-consuming for someone to sit down and explain a general theory of operation without any clue as to what you are working on. The easier you make it for us to help, the more likely we all are to help you.
      Take a breath.
      Andrew B.
    • Nov 04 2008 | 7:37 pm
      Sorry if my post sounded harsh.... it wasn't my intention to offend . Just receive help because tomorrow is my deadline and now things are confusing.
      here is my patch. If you open the "plot" subpatch and change the "dim" then it would work anymore.
      Thanks in advance.
      max v2;
    • Nov 04 2008 | 7:44 pm
      God! I'm tired and confused... my english is not good now... I've read the posts again and no one clamis to be offended, well don't know why I tought that before... well... sorry for everything I've written wrong.
      Miguel
    • Nov 04 2008 | 8:31 pm
      Hello,
      The problem mainly stems from how your expression is written. Since you rely on coordinates generated across the Y-dimension of your matrix, you are going to get very different results with a 1D matrix. In this case, all the cells of plane 1 will equal 0., which means that the result of your plane 2 expression will essentially just be the sin(norm[0]*24) when used with a 1D matrix. To remedy this, you can either change your expressions to no longer require values from plane 1 or use jit.submatrix to take a horizontal slice of your larger matrix coming from jit.gencoord. On a side note, another thing I might recommend is the use of norm[n],snorm[n],and cell[n] variables in jit.expr instead of the jit.gencoord object. Let us know how you get on. Also, try using other draw_modes besides tri_grid (line_strip comes to mind).
      Best,
      Andrew B.
    • Nov 04 2008 | 8:46 pm
      On Tue, Nov 4, 2008 at 9:31 PM, Andrew Benson wrote:
      >
      > The problem mainly stems from how your expression is written. Since you
      > rely on coordinates generated across the Y-dimension of your matrix, you are
      > going to get very different results with a 1D matrix. In this case, all the
      > cells of plane 1 will equal 0., which means that the result of your plane 2
      > expression will essentially just be the sin(norm[0]*24) when used with a 1D
      > matrix. To remedy this, you can either change your expressions to no longer
      > require values from plane 1 or use jit.submatrix to take a horizontal slice
      > of your larger matrix coming from jit.gencoord. On a side note, another
      > thing I might recommend is the use of norm[n],snorm[n],and cell[n] variables
      > in jit.expr instead of the jit.gencoord object. Let us know how you get on.
      > Also, try using other draw_modes besides tri_grid (line_strip comes to
      > mind).
      >
      A quick fix is to set your dimensions with 1 as a minimum with a simple
      adjustment like shown in the patch below. I second the suggestion of Andrew
      to use jit.gl.mesh instead of sending matrices directly to jit.gl.render.
      That way your patch becomes more managable and also scalable. For example,
      you could render multiple of these object by using multiple jit.gl.mesh
      objects.
      Good luck with the deadline.
      Thijs