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 --
    -- 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!
      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 (http://nehe.gamedev.net/).
      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.