cube environment mapping using orthographic projection

[bshArchive bshArchive]

Using an orthographic projection when doing cube environment mapping
produces
weird results in case the parallel view frustum is not centered around
the origin.

According to OpenGL, the view ray is reflected about the surface
normal of where the view
vector intersects a geometry. This results in a reflected ray which is
then passed to the cube map
to get the texel which the camera then sees as if it is on the surface
of the object.
With other words, the reflected ray which is shot from the ORIGIN is
used to select a cube face and
eventually a texel on that face.

Any hints ?

Example (Snippet):

void resizeGL(int w, int h) {

glViewport(0, 0, (GLint) w, (GLint) h);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0.0, 50.0, 0.0, 50.0, 0.1, 100.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}

void paintGL() {

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

glTranslated(25, 25, -75);

drawGeometry();

glFinish();
}

void drawGeometry() {

glEnable(GL_DEPTH_TEST);

glBindTexture(GL_TEXTURE_CUBE_MAP, cubemapTextureID);
glEnable(GL_TEXTURE_CUBE_MAP);
glEnable(GL_TEXTURE_GEN_S);
glEnable(GL_TEXTURE_GEN_T);
glEnable(GL_TEXTURE_GEN_R);

glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, mode);
glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, mode);
glTexGeni(GL_R, GL_TEXTURE_GEN_MODE, mode);

glColor3d(1.0, 0.0, 1.0);

glutSolidSphere(10.0, 100, 100);

glBindTexture(GL_TEXTURE_CUBE_MAP, 0);
glBindTexture(GL_TEXTURE_2D, 0);

glDisable(GL_TEXTURE_CUBE_MAP);
glDisable(GL_TEXTURE_2D);
}

[babaxter1]

Seems like I could answer the question by myself:

/*
* For every fragment a ray is shot from the coordinate system origin
to that fragment.
* Knowing the normal vectors at the intersection points, we can
easily compute the
* reflection ray. The reflected ray is used as a lookup key in the
environment map
* to obtain the final texel.
* Setting up a projection whose frustum is not centered around the
* coordinate system origin as e.g. glOrtho(100, 200, 100, 200, 0.1,
100)
* assumes that the projection's view rays are no longer shot from the
coordinate system origin.
* They are parallel to the z axis but do not start off from the
coordinate system origin in the obove example !
* For every fragment that is hit by a projection view ray $VEC_1 and
a ray starting off at the coordinate system origin $VEC_2,
* the reflection of $VEC_2 is computed. Let's denote it as
$VEC_2_REFLECTION.
* $VEC_2_REFLECTION is used for the determination of a texel to be
copied into the current fragment.
* This can indeed produce visual glitches under certain scenarios.
*
* Example:
* ========
* A parallel and uncentered viewing frustum is used with a sphere in
it.
* A projection viewing ray hits the geometry at a side furthest away
from the coordinate system origin.
* A ray is shot from the coordinate system origin to that point and
the corresponding reflection ray is computed.
* This ray can indeed go THROUGH the geometry and hit the regarded
point. The reflection ray can again go back
* through the geometry and select a cubemap face which is on the
opposite side. All of the sudden certain fragments
* receive wrong texels.
*
* Solution:
* =========
* If possible, center your viewing frustum around the origin and move
the geometry down towards the negative Z axis.
* This reduces the error to an acceptable degree. One needs to make
sure the geometries are not pushead away
* too far, though. In case of low or no curvature geometries such as
e.g. a cube, texture resolution is lost,
* resulting a poor image quality.
*/

Regards,

Babak Sayyid Hosseini