videoplane or other plane questions


    Jul 15 2006 | 7:06 pm
    I've been using videoplanes as 3D objects in a first-person world and having a heck of a time with getting them to display correctly according to their depth order, even with the new layers attribute in the beta.
    I just realized that if I replace them with jit.gl.plato all those problems took care of themselves. I guess this is because a jit.gl.videoplane isn't truly a 3D object? Anyways, now what I am wondering, is that if I want to use video as a texture will things slow down this way? And what is the fastest way to do that. I do not yet have shader support. Should I just refernce a jit.gl.texture object that has live video going into it?
    Thanks,
    Christopher Overstreet

    • Jul 15 2006 | 7:28 pm
      So I spoke to soon. I still can't seem to get depth to work properly.
      I have tried all combinations of layering and drawing with automatic off giving all of the transformations in the correct order. I can get things to look correct from one side but if I move the camera to the other side and everything is still drawn in the same order regardless of what is in front in the 3D space.
      I have also tried many combinations of depth_enable 1/0, depthbuffer 1/0, on all objects and have tried doublebuffer 1/0 to jit.gl.render and jit.window and nothing seems to change.
      Another short unrelated question. In a first person type jitter environment is it best to set the camera, and primarily use the position command to move around? Or maybe just use one or the other?
    • Jul 15 2006 | 9:01 pm
      You need to handle your own depth ordering by making your own display
      lists to fix the 'closest to the camera' issue.
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Jul 15, 2006, at 3:28 PM, Christopher Overstreet wrote:
      >
      > So I spoke to soon. I still can't seem to get depth to work properly.
      >
      > I have tried all combinations of layering and drawing with
      > automatic off giving all of the transformations in the correct
      > order. I can get things to look correct from one side but if I
      > move the camera to the other side and everything is still drawn in
      > the same order regardless of what is in front in the 3D space.
      >
      > I have also tried many combinations of depth_enable 1/0,
      > depthbuffer 1/0, on all objects and have tried doublebuffer 1/0 to
      > jit.gl.render and jit.window and nothing seems to change.
      >
      > Another short unrelated question. In a first person type jitter
      > environment is it best to set the camera, and primarily use the
      > position command to move around? Or maybe just use one or the other?
    • Jul 16 2006 | 4:12 am
      > You need to handle your own depth ordering by making your own display
      > lists to fix the 'closest to the camera' issue.
      >
      >
      > v a d e //
      >
      This seems quite complicated, especially with my forgotten math skills, but seems like it could solve some collision detection problems as well. So would the answer be something like...
      For every 3D object I create it needs to store its position and scale into a matrix "objects position table". Then each dimension of this matrix is compared to the camera's position using something like the pythagorean theorem to find the distances. The objects are then each sent a draw command or bang in the order of furthest to closest?
      BTW, when I played with GEM and PD the other day I noticed that this all seems to be handled by the system. Less flexible yes but...
      I can't wait until there is a physics object for Jitter with a counter-part to handle collision detection, depth ordering, etc.
    • Jul 16 2006 | 7:37 am
      pmpd runs in max? (Physical modelling - ie springs, masses,
      dampening. Hans Christoph Steiner [package manager for PD Extended)
      showed it to me the other day. Calling it sexy is an understatement.
      yes, ive been meaning to try it ;)
      it looks fantastic, if it runs anything like in PD.
      yes and no about my prior comments. it depends on the complexity of
      your scene. you can tell max to handle it for you for simple stuff.
      make sure you give depth_enable 1 to your objects and depthbuffer 1
      to your jit.window:
      here is a PD patch with GEM and the 'same' patch in Jitter. they
      exhibit the same behavior. hope this helps:
      max-
      pd-
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Jul 16, 2006, at 12:12 AM, Christopher Overstreet wrote:
      >
      >
      >> You need to handle your own depth ordering by making your own display
      >> lists to fix the 'closest to the camera' issue.
      >>
      >>
      >> v a d e //
      >>
      >
      > This seems quite complicated, especially with my forgotten math
      > skills, but seems like it could solve some collision detection
      > problems as well. So would the answer be something like...
      >
      > For every 3D object I create it needs to store its position and
      > scale into a matrix "objects position table". Then each dimension
      > of this matrix is compared to the camera's position using
      > something like the pythagorean theorem to find the distances. The
      > objects are then each sent a draw command or bang in the order of
      > furthest to closest?
      >
      > BTW, when I played with GEM and PD the other day I noticed that
      > this all seems to be handled by the system. Less flexible yes but...
      >
      > I can't wait until there is a physics object for Jitter with a
      > counter-part to handle collision detection, depth ordering, etc.
    • Jul 16 2006 | 2:24 pm
      You can do one of several things:
      Use jit.gl.texture in conjunction with jit.gl.gridshape @shape plane
      with a low dim count.
      Use jit.gl.texture in conjunction with jit.gl.mesh and send it a
      4-point quad with corresponding tex coords.
      Basically anyway you can texture 4 vertices can get you can do what
      jit.gl.videoplane does. BTW, jit.gl.videoplane should work properly.
      Perhaps you can post a patch as there are any number of things that
      could be going awry.
      best,
      wes
      On 7/15/06, Christopher Overstreet wrote:
      >
      > I've been using videoplanes as 3D objects in a first-person world and having a heck of a time with getting them to display correctly according to their depth order, even with the new layers attribute in the beta.
      >
      > I just realized that if I replace them with jit.gl.plato all those problems took care of themselves. I guess this is because a jit.gl.videoplane isn't truly a 3D object? Anyways, now what I am wondering, is that if I want to use video as a texture will things slow down this way? And what is the fastest way to do that. I do not yet have shader support. Should I just refernce a jit.gl.texture object that has live video going into it?
      >
      > Thanks,
      > Christopher Overstreet
      >
    • Jul 16 2006 | 2:31 pm
      Are you setting jit.window mywindow @depthbuffer 1? If you din;t give
      jit.window a depthbuffer, you won't have depth testing and this won't
      have object ordering based on z-value. That said, this doesn't apply
      to transparent objects and in this case, you have to do Z-ordering
      yourself which is really a pain. There are some techniques for
      getting around this using shaders and depth textures. The technique
      is generally called depth peeling:
      Suffice to say, this isn't possible in jitter just yet although depth
      textures is on the horizon.
      best,
      wes
      On 7/16/06, vade wrote:
      >
      > pmpd runs in max? (Physical modelling - ie springs, masses, dampening. Hans
      > Christoph Steiner [package manager for PD Extended) showed it to me the
      > other day. Calling it sexy is an understatement.
      >
      > yes, ive been meaning to try it ;)
      >
      >
      >
      > http://www.cnmat.berkeley.edu/%7Eali/share/max/pmpd/
      >
      > it looks fantastic, if it runs anything like in PD.
      >
      > yes and no about my prior comments. it depends on the complexity of your
      > scene. you can tell max to handle it for you for simple stuff. make sure you
      > give depth_enable 1 to your objects and depthbuffer 1 to your jit.window:
      >
      > here is a PD patch with GEM and the 'same' patch in Jitter. they exhibit the
      > same behavior. hope this helps:
      >
      > max-
      >
      >
      > #P window setfont "Sans Serif" 9.;
      > #P window linecount 2;
      > #P newex 191 97 263 196617 jit.gl.plato target @shape cube @scale 0.5 0.5
      > 0.5 @depth_enable 1 @lighting_enable 1 @smooth_shading 1;
      > #P window linecount 1;
      > #P newex 144 279 196 196617 jit.gl.handle target @inherit_transform 1;
      > #P window linecount 2;
      > #P newex 214 160 338 196617 jit.gl.plato target @shape cube @scale 0.5 0.5
      > 0.5 @position 0.5 0.5 0.5 @color 0 255 0 @depth_enable 1 @lighting_enable 1
      > @smooth_shading 1;
      > #P toggle 46 45 15 0;
      > #P window linecount 1;
      > #P newex 49 65 51 196617 qmetro 2;
      > #P newex 46 98 61 196617 t b b erase;
      > #P newex 49 188 96 196617 jit.gl.render target;
      > #P newex 66 330 161 196617 jit.window target @depthbuffer 1;
      > #P connect 6 0 1 0;
      > #P connect 4 0 3 0;
      > #P connect 3 0 2 0;
      > #P connect 2 0 1 0;
      > #P connect 2 2 1 0;
      > #P window clipboard copycount 8;
      >
      >
      > pd-
      >
      > #N canvas 256 159 764 493 10;
      > #X msg 59 20 create , 1;
      > #X msg 128 19 0 , destroy;
      > #X obj 68 44 gemwin;
      > #X obj 183 74 gemhead;
      > #X obj 282 76 gemhead;
      > #X obj 180 230 cube 0.5;
      > #X obj 280 232 cube 0.5;
      > #X obj 138 125 color 0 1 0;
      > #X obj 461 353 camera;
      > #X obj 461 241 gemhead;
      > #X obj 444 278 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
      > 1;
      > #X obj 467 259 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
      > 1;
      > #X obj 516 304 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
      > 1;
      > #X obj 542 282 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
      > 1;
      > #X msg 516 320 left $1;
      > #X msg 542 298 right $1;
      > #X obj 357 316 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
      > 1;
      > #X obj 383 294 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
      > 1;
      > #X msg 383 310 up $1;
      > #X msg 357 332 down $1;
      > #X msg 549 254 reset;
      > #X msg 467 276 forward $1;
      > #X msg 444 294 reverse $1;
      > #X msg 348 448 speed $1;
      > #X floatatom 348 430 5 0 0 0 - - -;
      > #X floatatom 349 391 5 0 0 0 - - -;
      > #X msg 661 346 lookX $1;
      > #X msg 661 383 lookY $1;
      > #X msg 661 419 lookZ $1;
      > #X floatatom 661 330 5 0 0 0 - - -;
      > #X floatatom 661 403 5 0 0 0 - - -;
      > #X floatatom 661 366 5 0 0 0 - - -;
      > #X msg 349 409 distance $1;
      > #X obj 261 161 translateXYZ 0.5 0.5 0.5;
      > #X connect 0 0 2 0;
      > #X connect 1 0 2 0;
      > #X connect 3 0 7 0;
      > #X connect 4 0 33 0;
      > #X connect 7 0 5 0;
      > #X connect 9 0 8 0;
      > #X connect 10 0 22 0;
      > #X connect 11 0 21 0;
      > #X connect 12 0 14 0;
      > #X connect 13 0 15 0;
      > #X connect 14 0 8 0;
      > #X connect 15 0 8 0;
      > #X connect 16 0 19 0;
      > #X connect 17 0 18 0;
      > #X connect 18 0 8 0;
      > #X connect 19 0 8 0;
      > #X connect 20 0 8 0;
      > #X connect 21 0 8 0;
      > #X connect 22 0 8 0;
      > #X connect 23 0 8 0;
      > #X connect 24 0 23 0;
      > #X connect 25 0 32 0;
      > #X connect 26 0 8 0;
      > #X connect 27 0 8 0;
      > #X connect 28 0 8 0;
      > #X connect 29 0 26 0;
      > #X connect 30 0 28 0;
      > #X connect 31 0 27 0;
      > #X connect 32 0 8 0;
      > #X connect 33 0 6 0;
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      >
      >
      > On Jul 16, 2006, at 12:12 AM, Christopher Overstreet wrote:
      >
      >
      >
      >
      > You need to handle your own depth ordering by making your own display
      > lists to fix the 'closest to the camera' issue.
      >
      >
      > v a d e //
      >
      >
      >
      > This seems quite complicated, especially with my forgotten math skills, but
      > seems like it could solve some collision detection problems as well. So
      > would the answer be something like...
      >
      > For every 3D object I create it needs to store its position and scale into a
      > matrix "objects position table". Then each dimension of this matrix is
      > compared to the camera's position using something like the pythagorean
      > theorem to find the distances. The objects are then each sent a draw
      > command or bang in the order of furthest to closest?
      >
      > BTW, when I played with GEM and PD the other day I noticed that this all
      > seems to be handled by the system. Less flexible yes but...
      >
      > I can't wait until there is a physics object for Jitter with a counter-part
      > to handle collision detection, depth ordering, etc.
      >
      >
      >
      >
    • Jul 16 2006 | 2:56 pm
      Try this patch out.