|
|
| Author |
Message |
| dj |
 Posted: Mon Aug 28, 2006 4:59 pm |
|
|
|
|
I am reading some text about OpenGL cube mapping and something really
puzzles me. It is said, that the six faces of the cube map are created
by rendering from some position in the six orthogonal directions. To me
the only such logical position would be the origin of the world
coordinate system, which is the only one "fixed" for some application.
On the other hand, the reflection vector, which is used for texture
coordinate generation through GL_REFLECTION_MAP, is said to be computed
in eye space (i.e. with the origin at camera position) and directly used
to map to s, t, and r.
Now, how can an eye space vector be used to index a texture created from
the world origin? Obviously there is something wrong with my inference
above, but I thought someone could help me pinpoint on it.
|
|
| Back to top |
|
| dj |
| Posted: Mon Aug 28, 2006 6:03 pm |
|
|
|
|
dj wrote:
Quote: I am reading some text about OpenGL cube mapping and something really
puzzles me. It is said, that the six faces of the cube map are created
by rendering from some position in the six orthogonal directions. To me
the only such logical position would be the origin of the world
coordinate system, which is the only one "fixed" for some application.
On the other hand, the reflection vector, which is used for texture
coordinate generation through GL_REFLECTION_MAP, is said to be computed
in eye space (i.e. with the origin at camera position) and directly used
to map to s, t, and r.
Now, how can an eye space vector be used to index a texture created from
the world origin? Obviously there is something wrong with my inference
above, but I thought someone could help me pinpoint on it.
I think I made some progress. The six cube map faces are rendered from
arbitrary position in the world (the best such position could be the
world origin if there are many reflecting objects, but this is not
neccessary). When rendering the scene from some other viewpoint, the
reflection vector ultimately should be transformed back to the
coordinate system in which the cube map was generated. I cannot see how
else the technique could be "view-independent", as everybody likes to
stress.
What remains a mystery to me is how the cube map must be generated for
use in OpenGL, which (by specs) definitely uses eye space reflection
vector to generate the texture coordinates. And how can this be
view-independent anyway, since if I change the viewpoint, the cube map
indexing is corrupted?
|
|
| Back to top |
|
| Thorsten Kiefer |
| Posted: Mon Aug 28, 2006 8:10 pm |
|
|
|
|
dj wrote:
Quote: I am reading some text about OpenGL cube mapping and something really
puzzles me. It is said, that the six faces of the cube map are created
by rendering from some position in the six orthogonal directions. To me
the only such logical position would be the origin of the world
coordinate system, which is the only one "fixed" for some application.
On the other hand, the reflection vector, which is used for texture
coordinate generation through GL_REFLECTION_MAP, is said to be computed
in eye space (i.e. with the origin at camera position) and directly used
to map to s, t, and r.
Now, how can an eye space vector be used to index a texture created from
the world origin? Obviously there is something wrong with my inference
above, but I thought someone could help me pinpoint on it.
Hi,
the cubemap is not rendered dynamically, you have to specify the six images
with glTexImage and an appropriate target. Now when you render a triangle,
one of the six images is selected (depending on the selection method - e.g.
GL_REFLECTION_MAP) and from the selected image a pixel is selected (also
depending on the selection method). Within a fragment program you can even
abuse a cube map e.g. for vertex normalization.
Regards
Thorsten
|
|
| Back to top |
|
| dj |
| Posted: Tue Aug 29, 2006 12:31 am |
|
|
|
|
Thorsten Kiefer wrote:
Quote: dj wrote:
I am reading some text about OpenGL cube mapping and something really
puzzles me. It is said, that the six faces of the cube map are created
by rendering from some position in the six orthogonal directions. To me
the only such logical position would be the origin of the world
coordinate system, which is the only one "fixed" for some application.
On the other hand, the reflection vector, which is used for texture
coordinate generation through GL_REFLECTION_MAP, is said to be computed
in eye space (i.e. with the origin at camera position) and directly used
to map to s, t, and r.
Now, how can an eye space vector be used to index a texture created from
the world origin? Obviously there is something wrong with my inference
above, but I thought someone could help me pinpoint on it.
Hi,
the cubemap is not rendered dynamically, you have to specify the six images
with glTexImage and an appropriate target. Now when you render a triangle,
one of the six images is selected (depending on the selection method - e.g.
GL_REFLECTION_MAP) and from the selected image a pixel is selected (also
depending on the selection method). Within a fragment program you can even
abuse a cube map e.g. for vertex normalization.
Regards
Thorsten
All you wrote is very understandable to me, what is not understandable
is how the eye space vector can be used to sample a view-independent
environment map. No literature on cube mapping explicitely states that
the eye space reflection vector must be back-transformed to the
environment map generation space (e.g. some object model space or the
world space), which is what should be done IMHO.
|
|
| Back to top |
|
| fungus |
| Posted: Tue Aug 29, 2006 12:47 am |
|
|
|
|
dj wrote:
Quote: No literature on cube mapping explicitely states that
the eye space reflection vector must be back-transformed to the
environment map generation space (e.g. some object model space or the
world space), which is what should be done IMHO.
You're supposed to use the texture matrix
to rotate the generated texture coordinates.
See this page:
http://www.opengl.org/registry/specs/ARB/texture_cube_map.txt
--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.
In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again. They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like
that happened in politics or religion.
- Carl Sagan, 1987 CSICOP keynote address
|
|
| Back to top |
|
| Wolfgang Draxinger |
| Posted: Tue Aug 29, 2006 4:26 am |
|
|
|
|
dj wrote:
Quote: It seems to me that available OpenGL books miss many such small
but important clues. Perhaps in the future I should start
checking other API literature when in a dilemma. After all,
cube mapping is not an exclusive OpenGL feature.
One last clue: Cube maps use a top bottom scanline ordering
instead of the bottom up scanline ordering of the normal
textures. This is, since the cube map specification was written
to match the "Photorealistic Renderman" specification, for what
reason soever. But this also implies, that cube maps internally
use a left handed coordinate system, since Renderman uses a LHC.
However OpenGL uses a right handed coordinate system.
When I started using cubemaps I got very frustrated, if nothing
worked like expected, but once you understood the reason,
everything gets clear.
But I still wonder, what drove the writers of the cube map
specification to follow Renderman. It's not a bad software, but
I just don't see a sane reason, why they didn't follow the rest
of OpenGL (right handed, bottom top scanline ordering).
Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867
GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E
|
|
| Back to top |
|
|
|
All times are GMT
The time now is Wed May 16, 2012 10:22 pm
|
|
