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

Feb 8, 2007 at 2:50am

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

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;
#N vpatcher 54 319 1361 1009;
#P origin 0 6;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 552 378 101 196617 Just for comparison;
#P message 368 114 38 196617 rate 1;
#P newex 624 322 66 196617 prepend size;
#P button 886 293 15 0;
#P newex 886 274 66 196617 route update;
#P message 333 114 29 196617 stop;
#P newex 355 374 193 196617 jit.window “Actual Matrix based Pixels”;
#P message 872 154 70 196617 size 320 240;
#P message 899 205 70 196617 size 720 486;
#P message 942 363 104 196617 setWindowAspect $1;
#P message 844 363 97 196617 setMovieAspect $1;
#P newex 844 387 97 196617 js aspect_helper.js;
#P newex 557 259 30 196617 t b b;
#P flonum 942 324 64 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 882 171 70 196617 size 720 480;
#P flonum 844 324 71 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 815 254 42 196617 getsize;
#N vpatcher 30 44 630 444;
#P window setfont “Sans Serif” 9.;
#P number 45 138 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 45 160 27 196617 / 1.;
#P window linecount 1;
#P newex 45 90 55 196617 route size;
#P flonum 45 182 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 93 139 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P newex 45 117 58 196617 unpack 0 0;
#P inlet 45 68 15 0;
#P outlet 45 222 15 0;
#P connect 1 0 5 0;
#P connect 5 0 2 0;
#P connect 2 0 7 0;
#P connect 7 0 6 0;
#P connect 6 0 4 0;
#P connect 4 0 0 0;
#P fasten 3 0 6 1 98 157 67 157;
#P connect 2 1 3 0;
#P pop;
#P newobj 942 297 75 196617 p aspect_ratio;
#P message 889 188 70 196617 size 800 450;
#P newex 557 238 50 196617 deferlow;
#N vpatcher 30 89 630 489;
#P window setfont “Sans Serif” 9.;
#P flonum 54 125 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 50 91 27 196617 / 1.;
#P number 98 72 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 50 72 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 50 50 58 196617 unpack 0 0;
#P inlet 50 30 15 0;
#P outlet 54 165 15 0;
#P connect 1 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 0 0;
#P connect 4 0 5 1;
#P connect 2 1 4 0;
#P pop;
#P newobj 640 193 75 196617 p aspect_ratio;
#P message 577 292 40 196617 getdim;
#P newex 542 218 41 196617 sel 0 1;
#P toggle 542 200 15 0;
#P newex 495 178 57 196617 unpack s 0;
#P newex 495 159 269 196617 route read dim;
#P message 301 114 30 196617 read;
#P newex 105 114 30 196617 t b b;
#P toggle 40 32 15 0;
#P newex 40 51 51 196617 qmetro 2;
#P newex 40 79 58 196617 t b b erase;
#P newex 872 253 92 196617 jit.window Aspect;
#P newex 40 528 209 196617 jit.gl.render Aspect @erase_color 0. 0. 0. 1;
#P window linecount 2;
#P newex 301 430 248 196617 jit.gl.videoplane Aspect @automatic 1
@blend_enable 0 @scale 1.333 1. 1. @color 1. 1. 1. 1.;
#P window linecount 1;
#P newex 301 137 107 196617 jit.qt.movie @adapt 1;
#P window linecount 2;
#P comment 852 408 176 196617 outputs scale messages to videoplane
(or whatever you want);
#P connect 7 0 6 0;
#P connect 6 0 5 0;
#P connect 5 0 3 0;
#P connect 5 2 3 0;
#P fasten 5 1 8 0 69 105 110 105;
#P fasten 9 0 1 0 306 133 306 133;
#P fasten 30 0 1 0 338 133 306 133;
#P connect 14 0 1 0;
#P fasten 8 1 1 0 130 134 306 134;
#P fasten 34 0 1 0 373 133 306 133;
#P connect 1 0 2 0;
#P fasten 24 0 2 0 849 407 306 407;
#P connect 8 0 2 0;
#P connect 1 0 29 0;
#P connect 33 0 29 0;
#P fasten 1 1 10 0 403 156 500 156;
#P connect 10 0 11 0;
#P connect 11 1 12 0;
#P connect 12 0 13 0;
#P connect 13 1 16 0;
#P connect 16 0 23 0;
#P connect 23 1 14 0;
#P connect 10 1 33 0;
#P fasten 10 1 15 0 629 183 645 183;
#P fasten 23 0 19 0 562 283 801 283 801 246 820 246;
#P fasten 32 0 19 0 891 310 810 310 810 246 820 246;
#P connect 15 0 20 0;
#P connect 20 0 25 0;
#P fasten 25 0 24 0 849 382 849 382;
#P fasten 26 0 24 0 947 382 849 382;
#P fasten 19 0 4 0 820 272 865 272 865 249 877 249;
#P connect 28 0 4 0;
#P connect 27 0 4 0;
#P connect 21 0 4 0;
#P connect 17 0 4 0;
#P fasten 4 1 31 0 959 272 891 272;
#P connect 31 0 32 0;
#P connect 31 1 18 0;
#P connect 18 0 22 0;
#P connect 22 0 26 0;
#P pop;

– 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.

// vade – http://abstrakt.vade.info

// 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 //

http://www.vade.info
abstrakt.vade.info

#30180
Feb 8, 2007 at 4:17am

> 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
320×240. 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

#95872
Feb 8, 2007 at 4:37am

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
> 320×240. 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 //

http://www.vade.info
abstrakt.vade.info

#95873
Feb 8, 2007 at 4:46am

> 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

#95874
Feb 8, 2007 at 4:58am

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

#95875
Feb 8, 2007 at 5:17am

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 //

http://www.vade.info
abstrakt.vade.info

#95876
Feb 8, 2007 at 6:07am

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 //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

#95877
Feb 8, 2007 at 6:32am

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

#95878
Feb 8, 2007 at 6:43am

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 //

http://www.vade.info
abstrakt.vade.info

#95879
Feb 8, 2007 at 6:47am

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

#95880
Feb 8, 2007 at 7:31am

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.

#95881
Feb 8, 2007 at 8:12am

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;
#N vpatcher 35 85 715 485;
#P origin 0 2;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 364 344 64 9109513 loadmess 0.6;
#P window setfont “Sans Serif” 18.;
#N vpatcher 15 55 749 497;
#P origin 0 49;
#P user fpic 679 325 428 71 func2.png 0 0 0 0. 0 0 3;
#X interp 1;
#P window setfont “Sans Serif” 12.;
#P window linecount 10;
#P comment 681 274 128 9109516 If the viewpoint is at (8 , 9 , 10) , the
distance between it and the center is ; The tangent of the half angle is
5.477 divided by 12.57 , which equals 0.4357 , so the half angle is
23.54degrees.;
#P user fpic 679 203 428 71 func1.png 0 0 0 0. 0 0 3;
#X interp 1;
#P window linecount 13;
#P comment 679 40 370 9109516 Of course , typically you don’t know the
exact size of an object , and the distance can only be determined between
the viewpoint and a single point in your scene. To obtain a fairly good
approximate value , find the bounding box for your scene by determining the
maximum and minimum x , y , and z coordinates of all the objects in your
scene. Then calculate the radius of a bounding sphere for that box , and
use the center of the sphere to determine the distance and the radius to
determine the size. For example , suppose all the coordinates in your
object satisfy the equations . Then the center of the bounding box is (1 ,
6 , 0) , and the radius of a bounding sphere is the distance from the
center of the box to any corner – say (3 , 7 , 5) – or ;;
#P window linecount 9;
#P comment 50 153 301 9109516 Example 3-3 : Calculating Field of View
#define PI 3.141593 ; double calculateAngle(double size , double distance)
; { ; double radtheta , degtheta ; radtheta = 2. * atan2 (size/2.0 ,
distance) ; degtheta = (180.0 * radtheta) / PI ; return (degtheta) ; };
#P comment 50 1 576 9109516 Even after you’ve aimed the camera in the
correct direction and you can see your objects , they might appear too
small or too large. If you’re using gluPerspective() , you might need to
alter the angle defining the field of view by changing the value of the
first parameter for this command. You can use trigonometry to calculate the
desired field of view given the size of the object and its distance from the
viewpoint: The tangent of half the desired angle is half the size of the
object divided by the distance to the object (see Figure 3-19). Thus , you
can use an arctangent routine to compute half the desired angle. Example 3-3
assumes such a routine , atan2() , which calculates the arctangent given
the length of the opposite and adjacent sides of a right triangle. This
result then needs to be converted from radians to
degrees.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> p94
redBook;
#P pop;
#P newobj 470 49 79 9109522 p explain;
#P window setfont “Sans Serif” 12.;
#P flonum 282 316 51 12 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 315 346 46 12 0 0 0 139 0 0 0 255 92 174 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 244 367 67 9109513 vexpr $f1*$f2;
#P newex 244 340 59 9109513 slide 11. 11.;
#P newex 244 252 27 9109513 * 2.;
#P window setfont “Sans Serif” 12.;
#P message 244 393 87 9109516 lens_angle $1;
#B color 4;
#P window setfont “Sans Serif” 9.;
#P newex 244 294 40 9109513 * 180.;
#P newex 244 273 63 9109513 / 3.141593;
#P newex 244 203 27 9109513 / 2.;
#P newex 244 227 42 9109513 atan2 2.;
#P window setfont “Sans Serif” 12.;
#P comment 273 176 167 9109516 radious of bounding sphere;
#P window setfont “Sans Serif” 9.;
#P newex 244 119 72 9109513 pack 0. 0. 0. 0.;
#P newex 244 176 27 9109513 sqrt;
#P window setfont “Sans Serif” 12.;
#P comment 343 120 97 9109516 max – mean;
#P window setfont “Sans Serif” 14.;
#P newex 244 144 259 9109518 expr pow(($f2-$f1)\,2)+pow(($f4-$f3)\,2);
#P window setfont “Sans Serif” 9.;
#P newex 299 66 88 9109513 unpack 0. 0. 0.;
#P newex 209 66 88 9109513 unpack 0. 0. 0.;
#P newex 57 42 375 9109513 jit.3m;
#B color 5;
#P inlet 57 22 15 0;
#P outlet 244 417 15 0;
#P window setfont “Sans Serif” 12.;
#P comment 431 344 135 9109516 multiply the lens_angle;
#P user panel 467 42 86 42;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window setfont “Sans Serif” 14.;
#P window linecount 6;
#P comment 373 220 100 9109518 calculate radiuos of bounding sphere and
apply to lens_angle;
#P window setfont “Sans Serif” 12.;
#P window linecount 1;
#P comment 389 67 40 9109516 maxZ;
#P connect 5 0 6 0;
#P fasten 6 1 7 0 183 63 214 63;
#P connect 7 0 12 0;
#P connect 12 0 9 0;
#P connect 9 0 11 0;
#P fasten 11 0 15 0 249 199 249 199;
#P fasten 15 0 14 0 249 226 249 226;
#P connect 14 0 19 0;
#P connect 19 0 16 0;
#P connect 16 0 17 0;
#P connect 17 0 20 0;
#P connect 20 0 21 0;
#P connect 21 0 18 0;
#P connect 18 0 4 0;
#P connect 8 0 12 1;
#P connect 23 0 20 1;
#P connect 7 1 12 2;
#P connect 23 0 20 2;
#P connect 6 2 8 0;
#P fasten 22 0 21 1 320 365 306 365;
#P connect 8 1 12 3;
#P connect 25 0 22 0;
#P pop;

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.
>

#95882
Feb 8, 2007 at 11:31am

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 //
>>
>> http://www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>

#95883
Feb 8, 2007 at 12:56pm

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

#95884
Feb 8, 2007 at 4:24pm

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)

http://pixelpusher.flkr.com/patches/scale-lens-angle-explained.pat

cheers
evan

#95885
Feb 8, 2007 at 4:31pm

Here’s what I use to determine the span of OpenGL coordinates across
the window. The values are calculated for Z=0.

wes

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 222 274 35 196617 height;
#P flonum 151 254 59 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 214 254 59 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 3;
#P message 38 151 72 196617 getdest_dim , getcamera , getlens_angle;
#P window linecount 1;
#N vpatcher 385 97 759 364;
#P outlet 131 150 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 131 128 29 196617 * 1.;
#P window linecount 1;
#P message 270 77 20 196617 $2;
#P message 248 77 20 196617 $1;
#P newex 248 95 32 196617 / 1.;
#P message 102 70 20 196617 $3;
#P newex 50 92 184 196617 expr $f2*2*tan($f1/2*3.1415/180);
#P newex 50 50 164 196617 route lens_angle camera dest_dim;
#P inlet 50 30 15 0;
#P outlet 166 152 15 0;
#P connect 1 0 2 0;
#P connect 2 0 3 0;
#P connect 2 1 4 0;
#P fasten 3 0 8 0 55 115 136 115;
#P connect 8 0 9 0;
#P fasten 5 0 8 1 253 118 155 118;
#P fasten 3 0 0 0 55 115 171 115;
#P fasten 4 0 3 1 107 88 229 88;
#P fasten 2 2 6 0 157 73 253 73;
#P connect 6 0 5 0;
#P fasten 2 2 7 0 157 73 275 73;
#P connect 7 0 5 1;
#P pop;
#P newobj 207 229 76 196617 p CalcGLHeight;
#P comment 154 274 35 196617 width;
#P toggle 233 122 15 0;
#P message 233 142 68 196617 fullscreen $1;
#N vpatcher 30 89 166 253;
#P window setfont “Sans Serif” 9.;
#P newex 50 71 35 196617 sel 27;
#P newex 50 50 40 196617 key;
#P outlet 50 93 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P pop;
#P newobj 233 102 33 196617 p Esc;
#P newex 233 160 151 196617 jit.window test @depthbuffer 1;
#P message 194 160 34 196617 reset;
#P newex 194 181 186 196617 jit.gl.handle test @inherit_transform 1;
#P toggle 131 141 15 0;
#P newex 131 160 57 196617 qmetro 30;
#P newex 131 181 50 196617 t b erase;
#P newex 131 206 86 196617 jit.gl.render test;
#P fasten 12 0 0 0 43 202 136 202;
#P connect 0 1 11 0;
#P fasten 11 1 13 0 278 250 219 250;
#P fasten 11 0 14 0 212 250 156 250;
#P connect 8 0 6 0;
#P connect 9 0 8 0;
#P connect 7 0 9 0;
#P connect 5 0 4 0;
#P fasten 1 0 0 0 136 202 136 202;
#P fasten 1 1 0 0 176 202 136 202;
#P fasten 4 0 0 0 199 202 136 202;
#P connect 2 0 1 0;
#P connect 3 0 2 0;
#P window clipboard copycount 16;

#95886
Feb 8, 2007 at 4:36pm

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

#95887
Feb 8, 2007 at 6:50pm

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

#95888
Feb 8, 2007 at 6:54pm

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

#95889
Feb 8, 2007 at 7:53pm

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
>

#95890
Feb 8, 2007 at 8:31pm

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

#95891
Feb 8, 2007 at 8:48pm

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 //

http://www.vade.info
abstrakt.vade.info

#95892
Feb 8, 2007 at 9:15pm

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.

#95893

You must be logged in to reply to this topic.