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 --
-- 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 //
www.vade.info
abstrakt.vade.info
> 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
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
> 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
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
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
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
>
>
>
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
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
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
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.
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.
>
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
>>
>>
>>
>
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
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
Here's what I use to determine the span of OpenGL coordinates across
the window. The values are calculated for Z=0.
wes
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
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
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
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
>
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
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
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.