another camera perspective question


    Jun 23 2007 | 4:59 pm
    According to one OpenGL paper I read the following is apparently possible in
    OpenGL but am not sure whether jitter offers this kind of low-level access,
    hence my question:
    Is it possible to adjust camera angle in such a way that the actual z-plane
    is skewed in respect to the camera origin, yet that it appears flat on the
    view. The best way to visualize this is to look at the attached jpg
    rendition.
    Please note that I am aware that this could be compensated by doing some
    runtime position/rotation adjustments to objects and/or by using an
    appropriate lens shader. I am however wondering whether this is possible via
    the aforesaid low-level OpenGL modification of camera.
    Ivica Ico Bukvic, D.M.A.
    Composition, Music Technology, CCTAD, CHCI
    Virginia Tech
    Dept. of Music - 0240
    Blacksburg, VA 24061
    (540) 231-1137
    (540) 231-5034 (fax)
    ico@vt.edu
    http://www.music.vt.edu/people/faculty/bukvic/

    • Jun 24 2007 | 8:44 pm
      Hi ico,
      Unfortunately in the forum your attachment is not visible. Could you repost the attachment via the forum?
      Mattijs
      Quote: ico wrote on Sat, 23 June 2007 18:59
      ----------------------------------------------------
      > According to one OpenGL paper I read the following is apparently possible in
      > OpenGL but am not sure whether jitter offers this kind of low-level access,
      > hence my question:
      >
      > Is it possible to adjust camera angle in such a way that the actual z-plane
      > is skewed in respect to the camera origin, yet that it appears flat on the
      > view. The best way to visualize this is to look at the attached jpg
      > rendition.
      >
      > Please note that I am aware that this could be compensated by doing some
      > runtime position/rotation adjustments to objects and/or by using an
      > appropriate lens shader. I am however wondering whether this is possible via
      > the aforesaid low-level OpenGL modification of camera.
      >
      > Ivica Ico Bukvic, D.M.A.
      > Composition, Music Technology, CCTAD, CHCI
      > Virginia Tech
      > Dept. of Music - 0240
      > Blacksburg, VA 24061
      > (540) 231-1137
      > (540) 231-5034 (fax)
      > ico@vt.edu
      > http://www.music.vt.edu/people/faculty/bukvic/
      > http://ico.bukvic.net
      >
      >
      >
      >
      >
      ----------------------------------------------------
    • Jun 24 2007 | 8:51 pm
      You want an asymmetric frustum. This is possible through
      jit.gl.sketch and calling glfrustum with appropriate parameters.
      wes
      On 6/24/07, Mattijs Kneppers wrote:
      >
      > Hi ico,
      >
      > Unfortunately in the forum your attachment is not visible. Could you repost the attachment via the forum?
      >
      > Mattijs
      >
      > Quote: ico wrote on Sat, 23 June 2007 18:59
      > ----------------------------------------------------
      > > According to one OpenGL paper I read the following is apparently possible in
      > > OpenGL but am not sure whether jitter offers this kind of low-level access,
      > > hence my question:
      > >
      > > Is it possible to adjust camera angle in such a way that the actual z-plane
      > > is skewed in respect to the camera origin, yet that it appears flat on the
      > > view. The best way to visualize this is to look at the attached jpg
      > > rendition.
      > >
      > > Please note that I am aware that this could be compensated by doing some
      > > runtime position/rotation adjustments to objects and/or by using an
      > > appropriate lens shader. I am however wondering whether this is possible via
      > > the aforesaid low-level OpenGL modification of camera.
      > >
      > > Ivica Ico Bukvic, D.M.A.
      > > Composition, Music Technology, CCTAD, CHCI
      > > Virginia Tech
      > > Dept. of Music - 0240
      > > Blacksburg, VA 24061
      > > (540) 231-1137
      > > (540) 231-5034 (fax)
      > > ico@vt.edu
      > > http://www.music.vt.edu/people/faculty/bukvic/
      > > http://ico.bukvic.net
      > >
      > >
      > >
      > >
      > >
      > ----------------------------------------------------
      >
      >
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Hard- and software for interactive audiovisual sampling
      >
    • Jun 24 2007 | 10:50 pm
      > You want an asymmetric frustum. This is possible through
      > jit.gl.sketch and calling glfrustum with appropriate parameters.
      Many thanks for the clarification. However, this should only affect drawing
      associated with jit.gl.sketch, no? If so, how can one make this global so
      that it affects all that is being captured by a particular GL camera?
      The other question is what are default values in glfrustum inside jitter. I
      messed with values but am getting rather bizarre results. An example would
      be most appreciated, too.
      Many thanks!
      Best wishes,
      Ico
    • Jun 24 2007 | 10:57 pm
      There are no defualt values for Jitter but there are values for
      OpenGL. It's a very very lowlevel call and you have to really
      understand what you're doing to get proper results. It's not really
      something you can just muck around with and expect interesting things
      from. I'm not really sure what the best way to use it to control an
      entire patch would be at this point.
      wes
      On 6/24/07, Ivica Ico Bukvic wrote:
      > > You want an asymmetric frustum. This is possible through
      > > jit.gl.sketch and calling glfrustum with appropriate parameters.
      >
      > Many thanks for the clarification. However, this should only affect drawing
      > associated with jit.gl.sketch, no? If so, how can one make this global so
      > that it affects all that is being captured by a particular GL camera?
      >
      > The other question is what are default values in glfrustum inside jitter. I
      > messed with values but am getting rather bizarre results. An example would
      > be most appreciated, too.
      >
      > Many thanks!
      >
      > Best wishes,
      >
      > Ico
      >
      >
      >
    • Jun 25 2007 | 12:43 am
      > There are no defualt values for Jitter but there are values for
      > OpenGL. It's a very very lowlevel call and you have to really
      > understand what you're doing to get proper results. It's not really
      > something you can just muck around with and expect interesting things
      > from. I'm not really sure what the best way to use it to control an
      > entire patch would be at this point.
      I would be surprised to find out that jitter does not use default OpenGL
      flustrum values, yet basic expected setting does not yield favorable results
      (glfrustum -1.33 1.33 -1 1 0.1 100 for a camera at 0 0 2 with a 4:3 screen
      and with z near/far adjusted to default setting inside jit.gl.sketch where
      objects disappear at 1.9 and -98).
      The other problem with glfrustum is that one has to click on a message twice
      before it has a more-or-less expected effect. If jit.gl.sketch is reset and
      then glfrustum is clicked on once, image is inverted and there is a bunch of
      other problems. Yet, when it is clicked twice, results are closer to what is
      expected, but still off. Clicking on the message three or more times makes
      difficult if not impossible to locate object in the viewport.
      To portray some of the oddities, for instance entering glfrustum -1 1 -1 1 3
      10 gets you closest to the default frustum of a sphere 0.5 object in the
      jit.gl.sketch help file but that is a far cry from what it ought to be. One
      would expect 4:3 scene frustum to be -1.33 1.33 -1 1 but any off values
      skews the object suggesting that frustum is object rather than
      scene-specific.
      So, based on a wasted afternoon my guess is the following:
      1) glfrustum implementation may be buggy--namely, requires double entry of
      data
      2) glfrustum in its current form affects object but not the scene, which
      would explain some of the oddities with obtained results as well as removal
      of the object from its center (when you try to rotate object with
      jit.gl.handle it appears outside the rotational center).
      If these conjectures are true, then this type glfrustum is useless for this
      particular purpose.
      Best wishes,
      Ico
    • Jun 25 2007 | 1:31 am
      Here's a question for you that may be the root of your problems.
      Notice in the glFrustum spec how it says a call to glFrustum generates
      a matrix which is multiplied by the current projection matrix. If
      you're not doing the following:
      glmatrixmode projection,
      glpushmatrix,
      glloadidentity,
      glfurstum ...,
      glmatrixmode modelview,
      draw stuff,
      glmatrixmode projection,
      glpopmatrix,
      glmatrixmode modelview
      then you might have problems.
      wes
      On 6/24/07, Ivica Ico Bukvic wrote:
      > > There are no defualt values for Jitter but there are values for
      > > OpenGL. It's a very very lowlevel call and you have to really
      > > understand what you're doing to get proper results. It's not really
      > > something you can just muck around with and expect interesting things
      > > from. I'm not really sure what the best way to use it to control an
      > > entire patch would be at this point.
      >
      > I would be surprised to find out that jitter does not use default OpenGL
      > flustrum values, yet basic expected setting does not yield favorable results
      > (glfrustum -1.33 1.33 -1 1 0.1 100 for a camera at 0 0 2 with a 4:3 screen
      > and with z near/far adjusted to default setting inside jit.gl.sketch where
      > objects disappear at 1.9 and -98).
      >
      > The other problem with glfrustum is that one has to click on a message twice
      > before it has a more-or-less expected effect. If jit.gl.sketch is reset and
      > then glfrustum is clicked on once, image is inverted and there is a bunch of
      > other problems. Yet, when it is clicked twice, results are closer to what is
      > expected, but still off. Clicking on the message three or more times makes
      > difficult if not impossible to locate object in the viewport.
      >
      > To portray some of the oddities, for instance entering glfrustum -1 1 -1 1 3
      > 10 gets you closest to the default frustum of a sphere 0.5 object in the
      > jit.gl.sketch help file but that is a far cry from what it ought to be. One
      > would expect 4:3 scene frustum to be -1.33 1.33 -1 1 but any off values
      > skews the object suggesting that frustum is object rather than
      > scene-specific.
      >
      > So, based on a wasted afternoon my guess is the following:
      >
      > 1) glfrustum implementation may be buggy--namely, requires double entry of
      > data
      > 2) glfrustum in its current form affects object but not the scene, which
      > would explain some of the oddities with obtained results as well as removal
      > of the object from its center (when you try to rotate object with
      > jit.gl.handle it appears outside the rotational center).
      >
      > If these conjectures are true, then this type glfrustum is useless for this
      > particular purpose.
      >
      > Best wishes,
      >
      > Ico
      >
      >
    • Jun 25 2007 | 3:34 pm
      >1) glfrustum implementation may be buggy--namely, requires double entry of data
      >2) glfrustum in its current form affects object but not the scene, which would explain some of the oddities with obtained results as well as removal of the object from its center (when you try to rotate object with jit.gl.handle it appears outside the rotational center).
      1. I'd bet that the problems you're having aren't due to bugs, they're because of some quirk of whatever method you're using. But unless you post an example, no one can really give you an definitive answer.
      2. The way you're stating the question would suggest you're a bit confused about how the whole jit.gl system works. glfrustum is only available through jit.gl.sketch, so you'll want to use one instance of jit.gl.sketch to control your camera. If there are other jit.gl objects (including additional jit.gl.sketch's) that you want to include in the scene, turn off their automatic attribute and use the first jit.gl.sketch's drawobject method with them. Then they'll all be viewed from the same frustum-enabled camera.
      The frustum stuff isn't actually all that complicated. Here's a working example (patch & javascript)
      max v2;
      //begin frustum.js
      var renderContext = "myContext"
      var look = [0,0,3,0,0,0,0,1,0];
      var frust = [-1.33,1.33,-1,1,1.5,120];
      var mySketch = new JitterObject("jit.gl.sketch",renderContext); // CREATE JITTER OBJECTS
      var myText = new JitterObject("jit.gl.text3d",renderContext);
      var myHandle = new JitterObject("jit.gl.handle",renderContext);
      var myRender = new JitterObject("jit.gl.render",renderContext);
      var myWindow = new JitterObject("jit.window",renderContext);
      mySketch.lighting_enable = 1;
      mySketch.smooth_shading = 1;
      myWindow.depthbuffer = 1;
      myRender.erase_color = [0,0,0,1];
      function bang() {
      mySketch.reset();
      mySketch.glclear();
      mySketch.glmatrixmode("projection"); // PROJECTION MATRIX
      mySketch.glloadidentity();
      mySketch.glfrustum(frust);
      mySketch.glmatrixmode("modelview"); // MODELVIEW MATRIX
      mySketch.glloadidentity();
      mySketch.glulookat(look);
      mySketch.gltranslate(myHandle.position); // HANDLE
      mySketch.glrotate(myHandle.rotate);
      mySketch.glpushmatrix(); // GROUND PLANE
      mySketch.gltranslate(0,-0.45,0);
      mySketch.glrotate(90,0,0);
      mySketch.glcolor(1,1,0,1);
      mySketch.plane(2);
      mySketch.glpopmatrix();
      mySketch.glpushmatrix(); // CONE
      mySketch.gltranslate(-1.125,0,0);
      mySketch.glrotate(90,0,0);
      mySketch.glcolor(1,0,0,1);
      mySketch.cylinder(0.45,0,0.45);
      mySketch.glpopmatrix();
      mySketch.glpushmatrix(); // CUBE
      mySketch.glcolor(0,0.25,1,1);
      mySketch.cube(0.425);
      mySketch.glpopmatrix();
      mySketch.glpushmatrix(); // SPHERE
      mySketch.gltranslate(1.125,0,0);
      mySketch.glcolor(0,1,0,1);
      mySketch.sphere(0.45);
      mySketch.glpopmatrix();
      myRender.erase();
      myRender.drawswap();
      }
      function lookat(a,b,c,d,e,f) {
      look = [a,b,c,d,e,f,0,1,0];
      }
      function frustum(a,b,c,d,e,f) {
      frust = [a,b,c,d,e,f];
      }
      //end frustum.js
    • Jun 25 2007 | 9:07 pm
      That's it! Thank you very much for the clarification. My error was to assume
      that glfrustum was simply an option passed to the jit.gl.sketch object (as
      in message "glfrustum a b c d e f"), but what was missing in my case is all
      the low-level code in between. Interesting thing was that it produced any
      results whatsoever, some of which I must admit were quite interesting :-).
      One more quick question. You mentioned to use @automatic 0 option on other
      objects that need rendering. I am having hard time to project them into the
      same space once automatic is disabled. Do you mind posting a simple example
      on how to alter draw object method you mentioned?
      I thought of simply adding another "jit.gl.sketch myContext @automatic 0"
      object and then instantiating stuff inside of it, but that did not work, nor
      did adding a bang/erase into the object's inlet.
      Best wishes,
      Ico
      > -----Original Message-----
      > From: jitter-bounces@cycling74.com [mailto:jitter-bounces@cycling74.com]
      > On Behalf Of Perry Hoberman
      > Sent: Monday, June 25, 2007 11:34 AM
      > Subject: [jitter] Re: another camera perspective question
      >
      >
      > >1) glfrustum implementation may be buggy--namely, requires double entry
      > of data
      > >2) glfrustum in its current form affects object but not the scene, which
      > would explain some of the oddities with obtained results as well as
      > removal of the object from its center (when you try to rotate object with
      > jit.gl.handle it appears outside the rotational center).
      >
      > 1. I'd bet that the problems you're having aren't due to bugs, they're
      > because of some quirk of whatever method you're using. But unless you post
      > an example, no one can really give you an definitive answer.
      >
      > 2. The way you're stating the question would suggest you're a bit confused
      > about how the whole jit.gl system works. glfrustum is only available
      > through jit.gl.sketch, so you'll want to use one instance of jit.gl.sketch
      > to control your camera. If there are other jit.gl objects (including
      > additional jit.gl.sketch's) that you want to include in the scene, turn
      > off their automatic attribute and use the first jit.gl.sketch's drawobject
      > method with them. Then they'll all be viewed from the same frustum-enabled
      > camera.
    • Jun 25 2007 | 9:31 pm
      To clarify my problem here's the example patch. Namely, the object now draws
      inside the renderer but its position which is updated via Max has no effect
      inside the scene with frustum:
      //frustum.js
      var renderContext = "myContext"
      var look = [0,0,3,0,0,0,0,1,0];
      var frust = [-1.33,1.33,-1,1,1.5,120];
      var mySketch = new JitterObject("jit.gl.sketch",renderContext); // CREATE
      JITTER OBJECTS
      var myText = new JitterObject("jit.gl.text3d",renderContext);
      var myHandle = new JitterObject("jit.gl.handle",renderContext);
      var myRender = new JitterObject("jit.gl.render",renderContext);
      var myWindow = new JitterObject("jit.window",renderContext);
      mySketch.lighting_enable = 1;
      mySketch.smooth_shading = 1;
      myWindow.depthbuffer = 1;
      myRender.erase_color = [0,0,0,1];
      function bang() {
      myRender.erase();
      mySketch.reset();
      mySketch.glclear();
      mySketch.glmatrixmode("projection"); // PROJECTION MATRIX
      mySketch.glloadidentity();
      mySketch.glfrustum(frust);
      mySketch.glmatrixmode("modelview"); // MODELVIEW MATRIX
      mySketch.glloadidentity();
      mySketch.glulookat(look);
      mySketch.gltranslate(myHandle.position); // HANDLE
      mySketch.glrotate(myHandle.rotate);
      mySketch.glpushmatrix(); // GROUND PLANE
      mySketch.gltranslate(0,-0.45,0);
      mySketch.glrotate(90,0,0);
      mySketch.glcolor(1,1,0,1);
      mySketch.plane(2);
      mySketch.glpopmatrix();
      mySketch.glpushmatrix(); // CONE
      mySketch.gltranslate(-1.125,0,0);
      mySketch.glrotate(90,0,0);
      mySketch.glcolor(1,0,0,1);
      mySketch.cylinder(0.45,0,0.45);
      mySketch.glpopmatrix();
      mySketch.glpushmatrix(); // CUBE
      mySketch.glcolor(0,0.25,1,1);
      mySketch.cube(0.425);
      mySketch.glpopmatrix();
      mySketch.glpushmatrix(); // SPHERE
      mySketch.gltranslate(1.125,0,0);
      mySketch.glcolor(0,1,0,1);
      mySketch.sphere(0.45);
      mySketch.glpopmatrix();
      mySketch.drawobject("boo",1);
      myRender.updateclients();
      myRender.drawswap();
      }
      function lookat(a,b,c,d,e,f) {
      look = [a,b,c,d,e,f,0,1,0];
      }
      function frustum(a,b,c,d,e,f) {
      frust = [a,b,c,d,e,f];
      }
      //end frustum.js
      What am I missing?
      Ico
    • Jun 25 2007 | 10:57 pm
      I don't really know what that sketch in the patch is supposed to be
      doing, especially with the [t b erase] hooked into it. It's not
      going to be afected by any frustum calls because that all gets negated
      by the draw method of jit.gl.sketch. Did you ever see the
      public_ob3d.c file? It might be enlightening. The ob3d_draw_begin and
      ob3d_draw_preamble get called _every_ time a jit.gl object draws in
      the normal fashion.
      wes
    • Jun 26 2007 | 12:25 am
      The other sketch was supposed to have its object instantiated manually (I
      believe in that version was a cube 2) and rendered it via other
      jit.gl.sketch in order to be affected by the same custom frustum. The [t b
      erase] was a pointless experiment at me trying to understand the concept.
      FWIW, I finally figured out the problem. Changing drawobject call
      mySketch.drawobject("boo",1);
      to
      mySketch.drawobject("boo",0);
      inside the js file did the trick. The source of this problem was in part
      because I copied drawobject(name, 1); call from another patch that was
      posted on the list a while ago and which worked (although did not require
      objects to move) and hence my assumption that it should've just worked and
      thus the ensuing problem...
      I was also unable to locate more info on drawobject in any of the jitter
      documentation which would point out my error with 0 vs 1, so I finally dug
      into the OpenGL API to learn more about it. Yet, there it simply talks about
      the priority of rendering which is making me confused again...
      Finally, for those who actually might find this useful, the default camera
      frustum appears to be:
      -0.0551 0.0551 -0.041429 0.041429 0.1 100
      Many thanks to all for your help in this matter!
      Best wishes,
      Ico
      > -----Original Message-----
      > From: jitter-bounces@cycling74.com [mailto:jitter-bounces@cycling74.com]
      > On Behalf Of Wesley Smith
      > Sent: Monday, June 25, 2007 6:58 PM
      > Subject: Re: [jitter] Re: another camera perspective question
      >
      > I don't really know what that sketch in the patch is supposed to be
      > doing, especially with the [t b erase] hooked into it. It's not
      > going to be afected by any frustum calls because that all gets negated
      > by the draw method of jit.gl.sketch. Did you ever see the
      > public_ob3d.c file? It might be enlightening. The ob3d_draw_begin and
      > ob3d_draw_preamble get called _every_ time a jit.gl object draws in
      > the normal fashion.
      >
      > wes
    • Jun 26 2007 | 12:52 am
      Look in the jit.gl.sketch help file in the object commands sub patch
      for info on drawobject. This is a Jitter method, not an OpenGL one so
      you won't find it in the spec.
      wes
      On 6/25/07, Ivica Ico Bukvic wrote:
      > The other sketch was supposed to have its object instantiated manually (I
      > believe in that version was a cube 2) and rendered it via other
      > jit.gl.sketch in order to be affected by the same custom frustum. The [t b
      > erase] was a pointless experiment at me trying to understand the concept.
      >
      > FWIW, I finally figured out the problem. Changing drawobject call
      >
      > mySketch.drawobject("boo",1);
      >
      > to
      >
      > mySketch.drawobject("boo",0);
      >
      > inside the js file did the trick. The source of this problem was in part
      > because I copied drawobject(name, 1); call from another patch that was
      > posted on the list a while ago and which worked (although did not require
      > objects to move) and hence my assumption that it should've just worked and
      > thus the ensuing problem...
      >
      > I was also unable to locate more info on drawobject in any of the jitter
      > documentation which would point out my error with 0 vs 1, so I finally dug
      > into the OpenGL API to learn more about it. Yet, there it simply talks about
      > the priority of rendering which is making me confused again...
      >
      > Finally, for those who actually might find this useful, the default camera
      > frustum appears to be:
      >
      > -0.0551 0.0551 -0.041429 0.041429 0.1 100
      >
      > Many thanks to all for your help in this matter!
      >
      > Best wishes,
      >
      > Ico
      >
      >
      > > -----Original Message-----
      > > From: jitter-bounces@cycling74.com [mailto:jitter-bounces@cycling74.com]
      > > On Behalf Of Wesley Smith
      > > Sent: Monday, June 25, 2007 6:58 PM
      > > Subject: Re: [jitter] Re: another camera perspective question
      > >
      > > I don't really know what that sketch in the patch is supposed to be
      > > doing, especially with the [t b erase] hooked into it. It's not
      > > going to be afected by any frustum calls because that all gets negated
      > > by the draw method of jit.gl.sketch. Did you ever see the
      > > public_ob3d.c file? It might be enlightening. The ob3d_draw_begin and
      > > ob3d_draw_preamble get called _every_ time a jit.gl object draws in
      > > the normal fashion.
      > >
      > > wes
      >
      >