Whats the dizzle with the Aspect Ratio-izzle? OpenGL scaling with video plane non intuitive?


    Feb 08 2007 | 2:50 am
    Dear god I am sorry for that subject line. I blame my newly purchased
    double power crystals. I fear I was shipped a bad set.
    Anyway.
    It is common for one to see in the Jitter Help files and examples for
    the videoplane, etc with @scale 1.33333 1. 1.
    Upon doing some sanity checking, it looks like the proper (ie, let me
    see all pixels, at the proper aspect ratio on a video plane in
    openGL), is not using 1.0 as the normalized height (or scaling
    factor). The magic number seems to be 0.83 (this is at least the case
    with Jitter 1.6.3b2 and max 4.6.2 on OS X 10.4.8
    As a service to the community, I provide the following patch which
    will automatically place nice pillar boxes or letter boxing,
    depending on your window aspect ratio, and your movie aspect ratio,
    and make the resulting video plane as large as possible.
    I did it in a javascript, but uh, it would be trivial to port to max
    logic. I just got tired or patching.
    Anyway, I hope people find this interesting and helpful. I had the
    funny feeling I wasnt seeing all my pixels...
    Anyone from C74 care to comment? Its REALLY not very obvious that the
    normalized openGL coordinate system (or camera placement), for the
    jit.gl.videoplane will be off if you scale it as advertised.
    if this is common knowledge - please forgive me - I had no idea, its
    really not obvious.
    -- max --
    max v2;
    -- js --
    // helper for calculating the proper size for our videoplane or
    other GL geometry based
    // on the current window aspect ratio and and movie aspect ratio.
    // free - public domain. if it kills your mom in the middle of the
    night it isnt my fault, etc etc
    windowAspect = 1.0;
    movieAspect = 1.0;
    scalingFactor = 1.0;
    magickNumber = 0.83;
    function setWindowAspect(v)
    {
    windowAspect = v;
    // outlet(0, "window aspect is "+windowAspect);
    recalc();
    }
    function setMovieAspect(v)
    {
    movieAspect = v;
    // outlet(0, "movie aspect is "+movieAspect);
    recalc();
    }
    function recalc()
    {
    if (windowAspect >= movieAspect)
    {
    scalingFactor = magickNumber;
    outlet(0, "scale",scalingFactor*movieAspect, 1*scalingFactor, 1 );
    }
    else
    {
    scalingFactor = ( ( 1/ (movieAspect / windowAspect) ) *
    magickNumber );
    outlet(0, "scale",scalingFactor*movieAspect, 1*scalingFactor, 1 );
    }
    }
    ----
    v a d e //
    www.vade.info
    abstrakt.vade.info

    • Feb 08 2007 | 4:17 am
      > It is common for one to see in the Jitter Help files and examples for
      > the videoplane, etc with @scale 1.33333 1. 1.
      The reason for this is that movies are typically in a 4:3 ratio as in
      320x240. jit.gl.videoplane textures a quad, so it makes sense for it
      to have the same w:h ratio as the video. @scale 1.333 1 is just an
      easy to remember 4:3 ratio. Whether or not it shows every pixel
      depends on much more than these factors in absolute terms. It depends
      on both the modelview matrix (object position, rotation, scale) and
      the perspective matrix (lens angle, viewport aspect ratio, near/far
      clip planes) and how texture sampling is setup like are you using
      GL_NEAREST or GL_LINEAR or perhaps a more complicated mimap filtering
      system. If you want it to fill your window, use @transform_reset 2.
      wes
    • Feb 08 2007 | 4:37 am
      Yes, transform reset 2 will fill the window, but not with the proper
      aspect ratio of the incoming video, which is much more like a
      jit.matrix -> jit.window solution.
      Anyway, I think it would be good to explicitly state this somewhere,
      that the default 0 0 2 camera position and the normally used 1.333 1.
      1. scaling factor will not show all of your pixels (even regardless
      of aspect ratio, it still clips).
      It took me quite some time to realize what was going on, and it is
      definitely an easy to miss fact.
      Anyway... this was more of a service announcement, as I dont expect
      any change in functionality.
      Feel free to include a derivative of this patch with Jitter, to point
      this out (should Cycling feel it necessary or somewhat explanatory)
      Thanks !
      On Feb 7, 2007, at 11:17 PM, Wesley Smith wrote:
      >> It is common for one to see in the Jitter Help files and examples for
      >> the videoplane, etc with @scale 1.33333 1. 1.
      >
      > The reason for this is that movies are typically in a 4:3 ratio as in
      > 320x240. jit.gl.videoplane textures a quad, so it makes sense for it
      > to have the same w:h ratio as the video. @scale 1.333 1 is just an
      > easy to remember 4:3 ratio. Whether or not it shows every pixel
      > depends on much more than these factors in absolute terms. It depends
      > on both the modelview matrix (object position, rotation, scale) and
      > the perspective matrix (lens angle, viewport aspect ratio, near/far
      > clip planes) and how texture sampling is setup like are you using
      > GL_NEAREST or GL_LINEAR or perhaps a more complicated mimap filtering
      > system. If you want it to fill your window, use @transform_reset 2.
      >
      > wes
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 08 2007 | 4:46 am
      > Anyway, I think it would be good to explicitly state this somewhere, that
      > the default 0 0 2 camera position and the normally used 1.333 1. 1. scaling
      > factor will not show all of your pixels (even regardless of aspect ratio, it
      > still clips).
      This has nothing to do with Jitter per se but OpenGL, so I don't feel
      it's Cycling's responsibility to document this. I'm still not sure
      what you mean by "clips". What exactly is clipping? The first and
      last pixels? Getting 1 texture pixel to show up as one OpenGL pixel
      requires a thorough understanding of OpenGL. I will politely suggest
      further reading about texture sampling in the OpenGL docs for anyone
      who has questions about this kind of behavior. OpenGL is designed for
      3D graphics. When doing stuff in 2D, you may have to do some extra
      work beyond the default.
      best,
      wes
    • Feb 08 2007 | 4:58 am
      BTW,
      I don't mean to come across as harsh in my previous email. I
      understand your desire to share this kind of information with everyone
      and that attitude is very helpful to the Jitter community so keep 'em
      coming ;)
      wes
    • Feb 08 2007 | 5:17 am
      Thanks for your latest email Wes, I figured you did not mean to come
      across in any other way - but I do appreciate none the less - I know
      youve been more than helpful in the past off and on list, so no sweat
      at all man :)
      As for the 'clipping', the default perspective matrix for the camera
      view and lens angle, combined with the normal modelview matrix for
      jit.gl.videoplane with either the scaling 1.333 1. 1. or normally
      instantiated 1. 1. 1. will indeed not show the full quad. In the
      jit.gl.helpfile, this is somewhat .. not obvious. The helpfile sends
      a hidden message to camera 0 0 4 on loadbang, making the behaviour of
      jit.gl.videoplane even more... non intuitive because the helpfiles
      behaviour and display differs quite drastically in appearance with a
      normal user creating a 'vanilla' jit.gl.render context and a
      'vanilla' jit.gl.videoplane.
      Only with quite a bit of experimentation does one get to realize what
      is going on, and, while not an OpenGL expert, I do understand the
      dynamics of the matrix operations in the openGL pipeline to some
      extent. It was just a bit odd, and unintuative to realize that a
      window with the proper aspect ratio of 1.333, and a videoplane with
      the proper aspect ratio of 1.333, would not show all of the pixels/
      image with a vanilla camera/perspective matrix.
      one needs to multiply by 0.83 to use the scale 1.10639 0.83 0.83 (or
      something right around that number) to show all of your image.
      I guess, my issue really is that the number '1', is a nice, round,
      friendly and approachable number, and it would be really sexy it
      somehow were treated as such (sorry 0.83, you just arent my type (I
      prefer ints anyway I guess))
      I hope you see, from a users perspective, how this is counterintuitive.
      Thanks,
      On Feb 7, 2007, at 11:46 PM, Wesley Smith wrote:
      >> Anyway, I think it would be good to explicitly state this
      >> somewhere, that
      >> the default 0 0 2 camera position and the normally used 1.333 1.
      >> 1. scaling
      >> factor will not show all of your pixels (even regardless of aspect
      >> ratio, it
      >> still clips).
      >
      > This has nothing to do with Jitter per se but OpenGL, so I don't feel
      > it's Cycling's responsibility to document this. I'm still not sure
      > what you mean by "clips". What exactly is clipping? The first and
      > last pixels? Getting 1 texture pixel to show up as one OpenGL pixel
      > requires a thorough understanding of OpenGL. I will politely suggest
      > further reading about texture sampling in the OpenGL docs for anyone
      > who has questions about this kind of behavior. OpenGL is designed for
      > 3D graphics. When doing stuff in 2D, you may have to do some extra
      > work beyond the default.
      >
      > best,
      > wes
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 08 2007 | 6:07 am
      i just want to say that i agree with anton 83%.
      On Feb 8, 2007, at 12:17 AM, vade wrote:
      > Thanks for your latest email Wes, I figured you did not mean to
      > come across in any other way - but I do appreciate none the less -
      > I know youve been more than helpful in the past off and on list, so
      > no sweat at all man :)
      >
      > As for the 'clipping', the default perspective matrix for the
      > camera view and lens angle, combined with the normal modelview
      > matrix for jit.gl.videoplane with either the scaling 1.333 1. 1. or
      > normally instantiated 1. 1. 1. will indeed not show the full quad.
      > In the jit.gl.helpfile, this is somewhat .. not obvious. The
      > helpfile sends a hidden message to camera 0 0 4 on loadbang, making
      > the behaviour of jit.gl.videoplane even more... non intuitive
      > because the helpfiles behaviour and display differs quite
      > drastically in appearance with a normal user creating a 'vanilla'
      > jit.gl.render context and a 'vanilla' jit.gl.videoplane.
      >
      > Only with quite a bit of experimentation does one get to realize
      > what is going on, and, while not an OpenGL expert, I do understand
      > the dynamics of the matrix operations in the openGL pipeline to
      > some extent. It was just a bit odd, and unintuative to realize that
      > a window with the proper aspect ratio of 1.333, and a videoplane
      > with the proper aspect ratio of 1.333, would not show all of the
      > pixels/image with a vanilla camera/perspective matrix.
      >
      > one needs to multiply by 0.83 to use the scale 1.10639 0.83 0.83
      > (or something right around that number) to show all of your image.
      >
      > I guess, my issue really is that the number '1', is a nice, round,
      > friendly and approachable number, and it would be really sexy it
      > somehow were treated as such (sorry 0.83, you just arent my type
      > (I prefer ints anyway I guess))
      >
      > I hope you see, from a users perspective, how this is
      > counterintuitive.
      >
      > Thanks,
      >
      >
      > On Feb 7, 2007, at 11:46 PM, Wesley Smith wrote:
      >
      >>> Anyway, I think it would be good to explicitly state this
      >>> somewhere, that
      >>> the default 0 0 2 camera position and the normally used 1.333 1.
      >>> 1. scaling
      >>> factor will not show all of your pixels (even regardless of
      >>> aspect ratio, it
      >>> still clips).
      >>
      >> This has nothing to do with Jitter per se but OpenGL, so I don't feel
      >> it's Cycling's responsibility to document this. I'm still not sure
      >> what you mean by "clips". What exactly is clipping? The first and
      >> last pixels? Getting 1 texture pixel to show up as one OpenGL pixel
      >> requires a thorough understanding of OpenGL. I will politely suggest
      >> further reading about texture sampling in the OpenGL docs for anyone
      >> who has questions about this kind of behavior. OpenGL is designed
      >> for
      >> 3D graphics. When doing stuff in 2D, you may have to do some extra
      >> work beyond the default.
      >>
      >> best,
      >> wes
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
    • Feb 08 2007 | 6:32 am
      My suggestion would be to make a clipping for yourself with
      jit.gl.videoplane @position 0 0 -2. The description of
      jit.gl.videoplane is "Overlay video as a texture onto a plane". The
      fact that the default view of jit.gl.render and jit.gl.videplane's
      initial position and scale happen to cause clipping of the top and
      bottom are IMHO not that big of a deal. Theoretically someone could
      say that their throbbing jit.gl.gridshape torus is cutoff and that the
      defaults should be changed to X or Y or something. I think in this
      case, becuse it's an image and not bare geometry there is a stronger
      reaction about this kind of thing. Personally I prefer to leave scale
      at 1.333 1 1 and change position or camera position instead of trying
      to figure out wierd scaling factors.
      wes
    • Feb 08 2007 | 6:43 am
      Yes, this train of thought does open up some things about clipping
      throbbing toruses.
      How would you handle aspect ratio transforms with only a camera move.. ?
      Anyway, I figured it out and I have working code that makes sense
      so.... time to move on.
      On Feb 8, 2007, at 1:32 AM, Wesley Smith wrote:
      > My suggestion would be to make a clipping for yourself with
      > jit.gl.videoplane @position 0 0 -2. The description of
      > jit.gl.videoplane is "Overlay video as a texture onto a plane". The
      > fact that the default view of jit.gl.render and jit.gl.videplane's
      > initial position and scale happen to cause clipping of the top and
      > bottom are IMHO not that big of a deal. Theoretically someone could
      > say that their throbbing jit.gl.gridshape torus is cutoff and that the
      > defaults should be changed to X or Y or something. I think in this
      > case, becuse it's an image and not bare geometry there is a stronger
      > reaction about this kind of thing. Personally I prefer to leave scale
      > at 1.333 1 1 and change position or camera position instead of trying
      > to figure out wierd scaling factors.
      >
      > wes
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 08 2007 | 6:47 am
      On 2/7/07, vade wrote:
      > Yes, this train of thought does open up some things about clipping throbbing
      > toruses.
      >
      > How would you handle aspect ratio transforms with only a camera move.. ?
      >
      I wouldn't. I would set scale to 1.333 1 which I mentioned in my
      previous email. Defintely time to move on....
      wes
    • Feb 08 2007 | 7:31 am
      It should also be noted that in orthographic mode 2, everything magically comes back to the realm of default 1.0 scalings. But I'll agree that a fair amount of hunt and peck scaling was necessary when I first started playing with no understanding of camera and other factors.
    • Feb 08 2007 | 8:12 am
      i use this patch to fix the lens angle to auto cover the width of an object.
      you have to matrixoutput it to get a a valid matrix for this to work doesn't
      auto-take-care of aspect ratio (matter of fact, it totally makes it worse)
      ,but that is a nice thing to have. included inside is the explanation for
      this method as appearing in the redbook.
      i second vade on the matter of opengl documenting (if he did make that
      point). its weight in the manuals is less then expected for this large a
      shift in paradigm.
      i use opengl in 85% of my patches and the manual is pretty slim compared.
      only about 25% of it is dedicated to opengl.
      reading the opengl documentation is invaluable but the actual code there is
      in C and not very obvious for a lowly patcher .
      even just porting examples from the actull book to max land without using
      one of 4 programing languages opengl jitter now support would be nice.
      making the jump from understanding jitter to mastering it is not documented
      anywhere! i demand a psi-noob power crystal shipped!
      max v2;
      On 2/8/07, Leo Mayberry wrote:
      >
      >
      > It should also be noted that in orthographic mode 2, everything magically
      > comes back to the realm of default 1.0 scalings. But I'll agree that a
      > fair amount of hunt and peck scaling was necessary when I first started
      > playing with no understanding of camera and other factors.
      >
    • Feb 08 2007 | 11:31 am
      FWIW, I also kindly request this be in the jitter tutorials/manual.
      With all due respect, there are always inconsistencies in
      implementations, and there's no guarantee that jitter's opengl will
      always behave like plain vanilla opengl (is there such a thing?)
      across different versions.
      Plus, you have jsui which defaults to ranges of -1 to 1 in both x and
      y, to confuse things.
      cheers
      evan
      On Feb 8, 2007, at 6:07 AM, joshua goldberg wrote:
      > i just want to say that i agree with anton 83%.
      >
      > On Feb 8, 2007, at 12:17 AM, vade wrote:
      >
      >> Thanks for your latest email Wes, I figured you did not mean to
      >> come across in any other way - but I do appreciate none the less -
      >> I know youve been more than helpful in the past off and on list,
      >> so no sweat at all man :)
      >>
      >> As for the 'clipping', the default perspective matrix for the
      >> camera view and lens angle, combined with the normal modelview
      >> matrix for jit.gl.videoplane with either the scaling 1.333 1. 1.
      >> or normally instantiated 1. 1. 1. will indeed not show the full
      >> quad. In the jit.gl.helpfile, this is somewhat .. not obvious. The
      >> helpfile sends a hidden message to camera 0 0 4 on loadbang,
      >> making the behaviour of jit.gl.videoplane even more... non
      >> intuitive because the helpfiles behaviour and display differs
      >> quite drastically in appearance with a normal user creating a
      >> 'vanilla' jit.gl.render context and a 'vanilla' jit.gl.videoplane.
      >>
      >> Only with quite a bit of experimentation does one get to realize
      >> what is going on, and, while not an OpenGL expert, I do understand
      >> the dynamics of the matrix operations in the openGL pipeline to
      >> some extent. It was just a bit odd, and unintuative to realize
      >> that a window with the proper aspect ratio of 1.333, and a
      >> videoplane with the proper aspect ratio of 1.333, would not show
      >> all of the pixels/image with a vanilla camera/perspective matrix.
      >>
      >> one needs to multiply by 0.83 to use the scale 1.10639 0.83 0.83
      >> (or something right around that number) to show all of your image.
      >>
      >> I guess, my issue really is that the number '1', is a nice, round,
      >> friendly and approachable number, and it would be really sexy it
      >> somehow were treated as such (sorry 0.83, you just arent my type
      >> (I prefer ints anyway I guess))
      >>
      >> I hope you see, from a users perspective, how this is
      >> counterintuitive.
      >>
      >> Thanks,
      >>
      >>
      >> On Feb 7, 2007, at 11:46 PM, Wesley Smith wrote:
      >>
      >>>> Anyway, I think it would be good to explicitly state this
      >>>> somewhere, that
      >>>> the default 0 0 2 camera position and the normally used 1.333 1.
      >>>> 1. scaling
      >>>> factor will not show all of your pixels (even regardless of
      >>>> aspect ratio, it
      >>>> still clips).
      >>>
      >>> This has nothing to do with Jitter per se but OpenGL, so I don't
      >>> feel
      >>> it's Cycling's responsibility to document this. I'm still not sure
      >>> what you mean by "clips". What exactly is clipping? The first and
      >>> last pixels? Getting 1 texture pixel to show up as one OpenGL pixel
      >>> requires a thorough understanding of OpenGL. I will politely
      >>> suggest
      >>> further reading about texture sampling in the OpenGL docs for anyone
      >>> who has questions about this kind of behavior. OpenGL is
      >>> designed for
      >>> 3D graphics. When doing stuff in 2D, you may have to do some extra
      >>> work beyond the default.
      >>>
      >>> best,
      >>> wes
      >>
      >> v a d e //
      >>
      >> www.vade.info
      >> abstrakt.vade.info
      >>
      >>
      >>
      >
    • Feb 08 2007 | 12:56 pm
      whilst it is true that whenever i get asked the question, is it hard to learn max? i generally say the learning curve is steep but made considerably easier with the provided tutorials and documentation. in fact, i still think the C74 docs / tutorials / help files are excellent in comparison to many other software!
      But i have to admit the jitter - opengl documentation is not that helpful unless you come from an opengl background (which, i dont even though i am now getting use to fumbling my way round!).
      I think it would be beneficial to have a more concise set of tutorials focusing on the opengl objects. help files of gl objects should also have an overview of what messages actually do, rather than just listing what messages it can take (By comparison, IMO the maxmsp pdf manuals are more helpful than the jitter html reference).
      I appreciate this would not be easy, but it would make using opengl objects much clearer! C74 ppl please dont take this the wrong way, i am just trying to provide you with honest feedback from my experience.
      thanks for listening... now, what page am i at in that red book?! ;)
      justin
    • Feb 08 2007 | 4:24 pm
      great, that clears things up a lot.
      So, building off of that, if you wanted to calculate those magic
      numbers, you'd use something like this:
      (patch too large for forum)
      cheers
      evan
    • Feb 08 2007 | 4:31 pm
      Here's what I use to determine the span of OpenGL coordinates across
      the window. The values are calculated for Z=0.
      wes
    • Feb 08 2007 | 4:36 pm
      Some of this stuff is already documented. Jitter Tutorial 32 seems to
      doa pretty good visual job of explaining coordinate systems in opengl
      and how they related to camera parameters and object position.
      wes
    • Feb 08 2007 | 6:50 pm
      Sorry if ithis has already been answered, but vade, I believe the
      critical thing you are missing in this is the use of the
      *perspective* rather than orthographic transform. Then everything is
      affected by where it is w/r/t the camera. It's not a 2D compositing
      system without using careful caveats (orthographic projection, fixed
      camera, etc.). It's 3D.
      -Joshua
    • Feb 08 2007 | 6:54 pm
      On Feb 7, 2007, at 11:31 PM, Leo Mayberry wrote:
      >
      > It should also be noted that in orthographic mode 2, everything
      > magically comes back to the realm of default 1.0 scalings. But
      > I'll agree that a fair amount of hunt and peck scaling was
      > necessary when I first started playing with no understanding of
      > camera and other factors.
      Right. I forgot to mention specifically, orthographic mode 1 in
      Jitter is not an ordinary orthographic projection. It tries to take
      into account a projective viewing angle. Perhaps this should have
      been done differently from the outset, but we're committed as much as
      possible to backward compatibility.
      Hope this helps.
      -Joshua
    • Feb 08 2007 | 7:53 pm
      and look, i'm probably going to annoy c74 by agreeing here too, but
      this is where the documentation REALLY falls short.
      more and more, it's obvious to everyone involved that the openGL
      stuff is really the way of the future: jitter's MSP equivalent to
      max's MIDI functionality, if you will.
      and there really does need to be a stupendously greater amount of
      documentation of using the openGL stuff. i dare say that it deserves
      its own separate manual.
      here's, to me, proof positive that openGL is underdocumented: i
      believe that nobody in New York City knows more about dealing with
      textures in openGL than vade. yet here we were, last night, whacking
      our heads against the wall YET AGAIN. because we were dealing with
      an issue that is only documented and explained in the forums.
      On Feb 8, 2007, at 7:56 AM, justin wrote:
      >
      > whilst it is true that whenever i get asked the question, is it
      > hard to learn max? i generally say the learning curve is steep but
      > made considerably easier with the provided tutorials and
      > documentation. in fact, i still think the C74 docs / tutorials /
      > help files are excellent in comparison to many other software!
      >
      > But i have to admit the jitter - opengl documentation is not that
      > helpful unless you come from an opengl background (which, i dont
      > even though i am now getting use to fumbling my way round!).
      >
      > I think it would be beneficial to have a more concise set of
      > tutorials focusing on the opengl objects. help files of gl objects
      > should also have an overview of what messages actually do, rather
      > than just listing what messages it can take (By comparison, IMO the
      > maxmsp pdf manuals are more helpful than the jitter html reference).
      >
      > I appreciate this would not be easy, but it would make using opengl
      > objects much clearer! C74 ppl please dont take this the wrong way,
      > i am just trying to provide you with honest feedback from my
      > experience.
      >
      > thanks for listening... now, what page am i at in that red book?! ;)
      >
      > justin
      >
    • Feb 08 2007 | 8:31 pm
      While I don't totally disagree with you, I will say that OpenGL is a
      huge beast that requires experience to work with fluently. There are
      many tutorials on OpenGL online. One of the better ones in NeHe
      Right now C74 provides docs on what the Jitter OpenGL objects do and
      how they expose the OpenGL API. It would probably be of great benefit
      to users to have more involved docs, but the tutorials are quite good
      as are the examples. Going further would be like explaining all
      things like additive synthesis, cross synthesis, subtractive
      synthesis, plunderphonics, remixing, etc for MSP which is at a
      different level than the docs should necessarily be at. To cover the
      OpenGL stuff at the same level, which is what you're asking, is beyond
      the writ of the Jitter documentation and is thoroughly covered already
      if you explore what kind of OpenGL information is online. The trick
      is to understand how Jitter objects use OpenGL and to look for
      information in the appropriate place.
      Vade is a smart guy, but the problems you came across last night did
      not have to do with an misunderstanding of Jitter but of OpenGL.
      Understanding that jit.gl.videoplane is simply a textured quad in 3D
      space is made plain in the Jitter docs. It is not an object that
      displays every pixel of a video by necessity although it can under the
      right circumstances. Keeping that information in mind as you read
      OpenGL docs will help you figure out problematic situations in the
      future. The implications of what you are asking is that Jitter should
      teach you everything about how to program in OpenGL. Jitter does
      provide excellent abstractions for doing things in OpenGL but it is no
      magic wand. It is still the user's responsiblity to acquire certain
      knowledge to work proficiently with it.
      One of the things C74 is working on is better documentation for users
      and better integration of the documentation with Max in general. We
      can't cover every single base. The software covers too much territory
      for for us to predict what users will try to do with the software and
      that is one of the great things about Max. So please don't feel that
      we don't hear you on the documentation issue.
      best,
      wes
    • Feb 08 2007 | 8:48 pm
      yeah, of course perspective makes a difference vs ortho, I never
      questioned that, or that openGL is for 3D, or that a videoplane is a
      quad and not a 2D compositing system, or pixels vs texels vs anything
      else, or that anything is anything other than what it is.
      My issue (and I do mean, mine, not "the".. or even cyclings), was
      that I had assumed the scale 1.33 1. 1. (or even 1. 1. 1. ) was
      normalized to the window height for the default modelview and
      perspective view matrices. Meaning, that a with camera 0 0 2 at 45
      degree lens angle and a default videoplane with @scale 1. 1. 1. would
      show the entire quad.
      It doesnt.
      Really, thats it.
      I didnt realize that and figured others might have seen that as well.
      Not that big of a deal.
      I was surprised because those numbers are thrown around a lot as
      proper (or inferred as proper) numbers to do x y z, where the
      assumption is, SHOW ME THE WHOLE GODDAMNED THING PLEASE, NOW. YES.
      THANK YOU. JUST WORK. (thats why im not using c or cocoa/obj-c btw)
      P.S.
      I still like my workaround best btw - Id rather not have to deal with
      openGL state transitions (switching from ortho to perspective to
      ortho in my pipeline. etc, why bother when I can just scale correctly?)
      I officially call for an end to this thread. As the op I herby veto
      any other responses.
      or rather
      I official-izzle call and end-izzle to this thread-izzle.
      You can all punch me later for that.
      On Feb 8, 2007, at 1:50 PM, Joshua Kit Clayton wrote:
      >
      > Sorry if ithis has already been answered, but vade, I believe the
      > critical thing you are missing in this is the use of the
      > *perspective* rather than orthographic transform. Then everything
      > is affected by where it is w/r/t the camera. It's not a 2D
      > compositing system without using careful caveats (orthographic
      > projection, fixed camera, etc.). It's 3D.
      >
      > -Joshua
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 08 2007 | 9:15 pm
      If anyone has specific suggestions on how we can improve our current
      documentation, we are happy to hear them.
      Send an email to support at cycling74 dot com
      Cheers,
      Andrew B.