[vox-tech] OpenGL: Frustums

[Peter Jay Salzman]

On Sun 13 Feb 05,  8:52 PM, Mark K. Kim said:
> On Sun, 13 Feb 2005, Peter Jay Salzman wrote:
> 
> > On Sun 13 Feb 05,  4:58 PM, Mark K. Kim said:
> > > On Sun, 13 Feb 2005, Mark K. Kim wrote:
> > >
> > > > On Sun, 13 Feb 2005, Peter Jay Salzman wrote:
> > > > [snip]
> > > > > First of all, why "-near" and not "near"?  That's such a strange definition
> > > > > I can't help but feel it's a typo.
> > > >
> > > > Not sure.  My v1.2 redbook says the same thing.
> > >
> > > Oh, I think I figured out why it's -near.  I think it's because the Z axis
> > > comes out of your screen, so the direction you're looking at is in the -Z
> > > axis direction.  "near" is in the direction you're looking at, therefore
> > > the plane you're defining is -near relative to the axis.
> > >
> > > -Mark
> >
> > I don't think I buy that.  It's true that the default viewing matrix is at
> > the origin looking down the -z axis, but that's just one special case.  I
> > can't believe that the designers would implement a fundamental definition
> > based on a default viewing angle?   So if the camera turns around and faces
> > the positive z axis...
> >
> > Most of the time in a 3D world, you first draw the scene, then you position
> > and point the camera.  So most of the time the camera really isn't going to
> > be at the origin anyhow.  (I think.)
> 
> That depends on many factors.  Because the graphics pipeline is a bunch of
> matrix operations (among others), the order of operations in the pipeline
> (as well as the matrix operation order) sometimes makes things come out
> exactly the opposite of how one thinks things should be.

I don't know if this is completely true.  The OpenGL pipeline is simply the
path the pixel data, or vertex data, takes.  It starts with a geometric
primitive and ends with being shipped off to the framebuffer, not
necessarily on the same computer that generated the pixel/vertex data.

You can easily construct a series of matrix operations so that the order of
operations in the pipeline comes out exactly in the SAME order as you'd
think.  For example, consider the graphics API called oPENgl in
bizarro-world.   Here is how you'd do a rotation followed by a translation
in oPENgl:

   GLlOADIDENTITY();
   GLrOTATEF();
   GLtRANSLATEF();

In oPENgl, this would represent multiplying a vertex first by a rotation
matrix, then by a translation matrix.  If we define operations by left
multiplication, you'd represent it as:

   v R^(-1)T^(-1)

where v would now be a row vector, and the inverses come from the "shoes and
socks principle".

But the point is, the matrix operations (which is independent of what the
pipeline looks like) come in the same order as you specify them.  First v,
then R^-1 then T^-1


Now, in our universe, we have OpenGL.  And that acts a bit differently.  In
OpenGL, we right-multiply the "current matrix" by the active transformation.
Then we right-multiply the combined current matrix by vertex data.  So if
you were to specify:

   glLoadIdentity();
   glRotate();
   glTranslate();

It would look like:

   RTv

Now, at first blush, this LOOKS like it makes sense.  R comes first and T
comes second.  But if you think about what happens, it's completely opposite
of what you wanted to happen.  You *wanted* to rotate first, then translate.
But instead, "RTv" means to translate the vertex first, then rotate the
translated vertex.

That lies at the heart of why OpenGL transformations are "backwards".  They
appear backwards only because we right multiply matrices (which is
independent of pipeline detail).

It only appears backward from a programatic POV though.  If you think in
terms of a local coordinate system fixed to the object you're modeling, it
no longer appears backwards.  Page 113 of the Redbook was so important I
read it three times.   ;)


> My knowledge of OpenGL is limited -- You might wanna just try it out and
> see what happens.  -near vs. near should be easy to test.  Then try
> changing the camera's view and see what happens.  Also try changing the
> camera's view THEN setting the frustum -- I don't think that'll make any
> difference but it might shed some light on how the pipeline works as far
> as the frustum is concerned.

You said the magic words: "try it out".   :)   It's so much easier to be
spoonfed...    ;-)

The problem is that since I'm an OpenGL newbie, getting a "black screen" is
really easy for me.  It wouldn't really tell me much just to get a black
screen.

But I'll give it a try (and if you're interested, report back).  I may not
get to it till Wednesday.  I've been awfully sick for the past week and fell
really behind on my grading and lesson plans.    :(   It's a good thing my
calculus is so strong...I can walk into the classroom and "wing it" for most
topics.

Pete

PS [Off topic]: I read that one of my favorite books in the whole world,
"Div Grad Curl and All That" has a new edition, so I went to Amazon to pick
it up.  Under the "customers who bought this also bought..." section,
another book came up called "Geometrical Vectors".  It's supposed to be an
informal text (like Div Grad Curl) but is supposed to present the beginnings
of Clifford Algebra (a geometric algebra), tensor analysis and new metaphors
for vectors.  Instead of arrows, it mentions "lines, sheaves, thumbtacks,
and stacks".

At this point in my education, the notion of seeing new metaphors for
vectors and tensors makes me drool with anticipation.  And I've NEVER heard
of an informal text on tensor analysis (if anybody knows of another one,
please post!)  Anyhow, I thought that this book might be of interest to some
of the people on the list since many of us are engineers, mathematicians and
physicists.

-- 
Save Star Trek Enterprise from extinction: http://www.saveenterprise.com

GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E  70A9 A3B9 1945 67EA 951D