Michael Vance wrote:
>
> On Wed, Feb 16, 2000 at 01:54:51PM -0700, Brian Paul wrote:
>
> > > Where can I find information about the values in ctx->ProjectionMatrix?
> >
> > Not sure I understand your question.
>
> Where are the values for ctx->ProjectionMatrix generated? I assume
> they're from a series of:
>
> glMatrixMode( GL_PROJECTION );
> glLoadIdentity( );
> glOrtho( 0, w, h, 0, 0, 1.0 );
>
> style API calls. The question is poor, I admit. I was just wondering
> why certain values where, say, -1, or even, according to gdb -0 (ie,
> if this is out of the ordinary), and if these values were perhaps due
> to my rendering setup (below).
In src/matrix.c you'll find the sources for glOrtho() and glFrustum().
They simply build a 4x4 matrix and multiply it with the current
(projection) matrix.
> > I guess I'll need more info on your "rasterization only interface".
>
> I do all of my own transformation, clipping and projection. The only
> manipulation of the modelview or projection matrices comes from a call
> to glOrtho(). All vertices are specified with x,y screen coordinates
> and a z value between 0 and -1.0. The texture coordinates are supplied
> with a homogenous w coordinate.
Hmmm, I'm not sure what the implications of using fog in this
scenario are. I've never dealt with this.
> > I was working on a bug fix for LINEAR fog in the 3dfx driver yesterday.
> > Maybe related?
>
> This is actually with the software renderer. I was able to resolve
> these issues by fiddling with the start/end. For a glOrtho with 0,1.0
> near/far I got appropriate fogging by setting the start to 0.995 and
> the end to 1.0. I assume this is because a great deal of my data is
> clustered towards the far clip plane (terrain data).
Could be.
> However, I am currently exploring a problem with the GL_LINEAR FX fog
> mode, but I was looking into why all of my oow coordinates are set to
> 1.0 in my grVertex structures.
Well, I fixed a bug in the FX driver whereby changes to fog GL_START
and GL_END weren't being caught by the driver. I haven't checked in
the change yet.
Along the way however, I found that when using an orthographic projection
matrix that all the w coords in the FX driver are 1. This is correct,
according to the OpenGL spec. The problem is Glide uses the W coordinate
to compute fog. It looks like we'll have to stash a scaled/biased?
version of the Z coord into the W coord when using an ortho projection
in order to make fog work.
I'll look into this.
> There did seem to be a large problem with the way the fog tables were
> calculated for FX, given that I got a table filled with 0xFF for the
> start/end I described above.
>
> > You're looking at _mesa_fog_rgba_pixel()? The sign of eyez doesn't
> > really matter since for LINEAR and EXP we use the absolute vale and
> > in the EXP2 case we're squaring that value.
>
> What about the zero values for tmp I was seeing (0 value for the
> variable 'd' in gl_fog_rgba_pixels())? This was causing no fogging in
> the EXP and EXP2 cases because eyez always ended up as 0, f became
> 2.81, clamped to 1.0, and no fogging provided.
d = projectionMatrix[14] = -(far + near) / (far - near) where
near and far are the parameters given to glOrtho.
If you're setting near=0 and far=1 then d should be -1.
If that's not the case, something is very wrong somewhere.
-Brian
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
