Help!


I've been banging my head on automatic texture coordinate generation for
too long.
I just don't get it....

To make things worse I'm working with 3D textures.


The application is volume visualization.  Maximum Intensity Projection.


Where do I begin?

I can generate a 3D texture and then manually map text coordinates to
object vertices.

Things even work if I rotate the modelview.

I was told that rotating the texture would give much better results than
rotating an object.

My problems begin when I try to use automatic texture coordinate
generation.

More specifically when I try to rotate the texture.


I really can't figure out the rotation of the S,T and R planes and
concept of the OBJECT_PLANE vs the EYE_PLANE.

To tell you the truth I don't know where to begin asking questions on
this.  The texts I've read don't seem to be helping
and I've yet to see a good graphical explanation of what is going on.

Even an example of rotating a 2D texture map on a fixed polygon would be
helpful.

"JustSomeGuy" <NoOne@ucalgary.ca> wrote in message 
news:416C443E.8CE2F5D8@ucalgary.ca...
> I've been banging my head on automatic texture coordinate generation for
> too long.
> I just don't get it....
>
> To make things worse I'm working with 3D textures.
>
> The application is volume visualization.  Maximum Intensity Projection.

Maximum Intensity Projection (MIP) does not involve 3D
texture coordinate generation.  MIP does involve computing
the maximum intensity of a volumetric image along a ray.
On current generation CPUs, you can compute MIP quite
rapidly without the need for hardware acceleration.  Bresenham's
algorithm for line drawing, extended to 3D, works well.  You
can also use shear warp rendering (by Marc Levoy) to accelerate
the software rendering.

To use the volumetric image as a 3D texture, you need to
introduce "geometry" somehow.  The standard method is
to produce parallel rectangles, one per image slice.  As the
image is rotated, you determine the most appropriate of the
3 coordinate directions in which to slice.  The texture
coordinate generation is obvious for this application.

--
Dave Eberly
http://www.magic-software.com

Dave Eberly wrote:

> "JustSomeGuy" <NoOne@ucalgary.ca> wrote in message
> news:416C443E.8CE2F5D8@ucalgary.ca...
> > I've been banging my head on automatic texture coordinate generation for
> > too long.
> > I just don't get it....
> >
> > To make things worse I'm working with 3D textures.
> >
> > The application is volume visualization.  Maximum Intensity Projection.
>
> Maximum Intensity Projection (MIP) does not involve 3D
> texture coordinate generation.  MIP does involve computing
> the maximum intensity of a volumetric image along a ray.
> On current generation CPUs, you can compute MIP quite
> rapidly without the need for hardware acceleration.  Bresenham's
> algorithm for line drawing, extended to 3D, works well.  You
> can also use shear warp rendering (by Marc Levoy) to accelerate
> the software rendering.
>
> To use the volumetric image as a 3D texture, you need to
> introduce "geometry" somehow.  The standard method is
> to produce parallel rectangles, one per image slice.  As the
> image is rotated, you determine the most appropriate of the
> 3 coordinate directions in which to slice.  The texture
> coordinate generation is obvious for this application.
>
> --
> Dave Eberly
> http://www.magic-software.com

Well its working Dave... :)
The only problem is I have to rotate the texture and not the modelview...
This is what is causing me grief.

Dave Eberly wrote:
> "JustSomeGuy" <NoOne@ucalgary.ca> wrote in message 
> news:416C443E.8CE2F5D8@ucalgary.ca...
> 
>>I've been banging my head on automatic texture coordinate generation for
>>too long.
>>I just don't get it....
>>
>>To make things worse I'm working with 3D textures.
>>
>>The application is volume visualization.  Maximum Intensity Projection.
> 
> 
> Maximum Intensity Projection (MIP) does not involve 3D
> texture coordinate generation.  

I assume the OP is using texgen to avoid storing texture coordinates for 
the proxy geometry. I don't know if it is worth while doing or not.

> MIP does involve computing
> the maximum intensity of a volumetric image along a ray.
> On current generation CPUs, you can compute MIP quite
> rapidly without the need for hardware acceleration.  Bresenham's
> algorithm for line drawing, extended to 3D, works well.  You
> can also use shear warp rendering (by Marc Levoy) to accelerate
> the software rendering.

When you have a large volume (say 512-cubed or larger), main memory and 
cache become very important, but I don't see how shear-warp will help 
much. Instead, a tiled approach is probably better -- for both software 
and GPU acceleration.

> To use the volumetric image as a 3D texture, you need to
> introduce "geometry" somehow.  The standard method is
> to produce parallel rectangles, one per image slice. As the
> image is rotated, you determine the most appropriate of the
> 3 coordinate directions in which to slice.  

3D texture mapped approaches are also common, and generally use proxy 
geometry that is parallel to the screen, rather than parallel to a 
volume side.

> The texture
> coordinate generation is obvious for this application.

The OP is trying to do this, but is having difficulty.

JustSomeGuy wrote:

> The only problem is I have to rotate the texture and not the modelview...
> This is what is causing me grief.

Think of texgen as a 4x4 matrix converting geometric coordinates into 
texture coords. You could do everything in the texture matrix and just 
set the texgen parameters to be the identity matrix.

Rotating the texture is most simply done by changing the modelview 
matrix to rotate the proxy geometry; the texture coordinates should not 
change. Clearly this does not keep the proxy geometry parallel to the 
screen, but it will work for small rotations. You would want to 
regenerate the proxy geometry at 45 degree rotations, just like the 2D 
texture mapping approaches do.

When you regenerate the proxy geometry (possibly for every frame so that 
it stays parallel to the screen) you intersect the volume with the view 
frustum and generate geometric and texture coordinates in parallel.

Now, if you are trying to keep the proxy geometry constant in screen 
space and rotate the texture coordinates, your proxy geometry will need 
to cover every place where the texture could be, and so I don't think 
performance would be great. Your texgen parameters (or the texture 
matrix) would be the inverse of the texture coord to screen space matrix.

--
Andy V

"Andy V" <nobody@nowhere.net> wrote in message
news:9Ejbd.609$Zx3.21596@petpeeve.ziplink.net...
> Dave Eberly wrote:
> > "JustSomeGuy" <NoOne@ucalgary.ca> wrote in message
> > news:416C443E.8CE2F5D8@ucalgary.ca...
> >
> >>I've been banging my head on automatic texture coordinate generation for
> >>too long.
> >>I just don't get it....
> >>
> >>To make things worse I'm working with 3D textures.
> >>
> >>The application is volume visualization.  Maximum Intensity Projection.
> >
> >
> > Maximum Intensity Projection (MIP) does not involve 3D
> > texture coordinate generation.
>
> I assume the OP is using texgen to avoid storing texture coordinates for
> the proxy geometry. I don't know if it is worth while doing or not.
>
> > MIP does involve computing
> > the maximum intensity of a volumetric image along a ray.
> > On current generation CPUs, you can compute MIP quite
> > rapidly without the need for hardware acceleration.  Bresenham's
> > algorithm for line drawing, extended to 3D, works well.  You
> > can also use shear warp rendering (by Marc Levoy) to accelerate
> > the software rendering.
>
> When you have a large volume (say 512-cubed or larger), main memory and
> cache become very important, but I don't see how shear-warp will help
> much. Instead, a tiled approach is probably better -- for both software
> and GPU acceleration.
>
> > To use the volumetric image as a 3D texture, you need to
> > introduce "geometry" somehow.  The standard method is
> > to produce parallel rectangles, one per image slice. As the
> > image is rotated, you determine the most appropriate of the
> > 3 coordinate directions in which to slice.
>
> 3D texture mapped approaches are also common, and generally use proxy
> geometry that is parallel to the screen, rather than parallel to a
> volume side.
>
> > The texture
> > coordinate generation is obvious for this application.
>
> The OP is trying to do this, but is having difficulty.
>
> JustSomeGuy wrote:
>
> > The only problem is I have to rotate the texture and not the
modelview...
> > This is what is causing me grief.
>
> Think of texgen as a 4x4 matrix converting geometric coordinates into
> texture coords. You could do everything in the texture matrix and just
> set the texgen parameters to be the identity matrix.
>
> Rotating the texture is most simply done by changing the modelview
> matrix to rotate the proxy geometry; the texture coordinates should not
> change. Clearly this does not keep the proxy geometry parallel to the
> screen, but it will work for small rotations. You would want to
> regenerate the proxy geometry at 45 degree rotations, just like the 2D
> texture mapping approaches do.
>
> When you regenerate the proxy geometry (possibly for every frame so that
> it stays parallel to the screen) you intersect the volume with the view
> frustum and generate geometric and texture coordinates in parallel.
>
> Now, if you are trying to keep the proxy geometry constant in screen
> space and rotate the texture coordinates, your proxy geometry will need
> to cover every place where the texture could be, and so I don't think
> performance would be great. Your texgen parameters (or the texture
> matrix) would be the inverse of the texture coord to screen space matrix.
>
> --
> Andy V
>

Andy could we continue this thread via email?

moc.oohay@81neirbob  (Backwards...)

"Andy V" <nobody@nowhere.net> wrote in message 
news:9Ejbd.609$Zx3.21596@petpeeve.ziplink.net...

> When you have a large volume (say 512-cubed or larger), main memory and 
> cache become very important, but I don't see how shear-warp will help 
> much. Instead, a tiled approach is probably better -- for both software 
> and GPU acceleration.

The shear warp method is cache friendly and provides
a significant improvement over standard ray tracing
through a volumetric data set.  When coupled with
information about skipping transparent voxels, the
display is extremely fast, even for large images.  My
experience is in implementing this, both in C++ and
in Java, for medical image display, although the lack
of pointers and pointer incrementing in Java causes it
not to perform as well as the C++ version.

> 3D texture mapped approaches are also common, and generally use proxy 
> geometry that is parallel to the screen, rather than parallel to a volume 
> side.

In my experience, using geometry parallel to the screen is
slower than when using geometry parallel to the image
axes.  Then there is the issue of how many slices to choose.
You can get strange artifacts if too many or too few are
chosen.  In the package I work on, we scrapped the
screen-parallel version.

>> The texture
>> coordinate generation is obvious for this application.
>
> The OP is trying to do this, but is having difficulty.

In the case of using the image directly as a 3D texture, the
natural mapping of the unit cube [0,1]^3 to the image slice
geometry is a straightforward computation, so I stick to
my use of the term "obvious".  I suspect this is *not* the
OP's problem, but I suppose he should clarify for himself.

--
Dave Eberly
http://www.magic-software.com

Dave Eberly wrote:

> "Andy V" <nobody@nowhere.net> wrote in message 
> news:9Ejbd.609$Zx3.21596@petpeeve.ziplink.net...
> 
> 
>>When you have a large volume (say 512-cubed or larger), main memory and 
>>cache become very important, but I don't see how shear-warp will help 
>>much. Instead, a tiled approach is probably better -- for both software 
>>and GPU acceleration.
> 
> 
> The shear warp method is cache friendly and provides
> a significant improvement over standard ray tracing
> through a volumetric data set.  When coupled with
> information about skipping transparent voxels, the
> display is extremely fast, even for large images.  My
> experience is in implementing this, both in C++ and
> in Java, for medical image display, although the lack
> of pointers and pointer incrementing in Java causes it
> not to perform as well as the C++ version.

Shear warp is a bit friendlier than standard, but when the ray length 
grows long enough you will still thrash the cache. Empty space leaping 
is great when you have empty space and not otherwise.

>>3D texture mapped approaches are also common, and generally use proxy 
>>geometry that is parallel to the screen, rather than parallel to a volume 
>>side.
> 
> 
> In my experience, using geometry parallel to the screen is
> slower than when using geometry parallel to the image
> axes.  Then there is the issue of how many slices to choose.
> You can get strange artifacts if too many or too few are
> chosen.  In the package I work on, we scrapped the
> screen-parallel version.

Yes, too few slices loses details, and too many slices runs into 
precision problems due to alpha correction. I have noticed a trend back 
to 2D textures and object parallel proxy geometry. More interesting, 
however, is the pre-integrated rendering methods -- rendering slabs 
instead of slices. Another new idea is doing ray-casting on the GPU.

--
Andy V

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message
news:r1kbd.3593$SZ5.2909@newsread2.news.atl.earthlink.net...
>
> "Andy V" <nobody@nowhere.net> wrote in message
> news:9Ejbd.609$Zx3.21596@petpeeve.ziplink.net...
>
> > When you have a large volume (say 512-cubed or larger), main memory and
> > cache become very important, but I don't see how shear-warp will help
> > much. Instead, a tiled approach is probably better -- for both software
> > and GPU acceleration.
>
> The shear warp method is cache friendly and provides
> a significant improvement over standard ray tracing
> through a volumetric data set.  When coupled with
> information about skipping transparent voxels, the
> display is extremely fast, even for large images.  My
> experience is in implementing this, both in C++ and
> in Java, for medical image display, although the lack
> of pointers and pointer incrementing in Java causes it
> not to perform as well as the C++ version.
>
> > 3D texture mapped approaches are also common, and generally use proxy
> > geometry that is parallel to the screen, rather than parallel to a
volume
> > side.
>
> In my experience, using geometry parallel to the screen is
> slower than when using geometry parallel to the image
> axes.  Then there is the issue of how many slices to choose.
> You can get strange artifacts if too many or too few are
> chosen.  In the package I work on, we scrapped the
> screen-parallel version.
>
> >> The texture
> >> coordinate generation is obvious for this application.
> >
> > The OP is trying to do this, but is having difficulty.
>
> In the case of using the image directly as a 3D texture, the
> natural mapping of the unit cube [0,1]^3 to the image slice
> geometry is a straightforward computation, so I stick to
> my use of the term "obvious".  I suspect this is *not* the
> OP's problem, but I suppose he should clarify for himself.
>

I will try to clarify... However it seems that when ever I
go near this subject I get bombarded with things I have not
yet learned in OpenGL and can find no 'good' step by step tutorials on.

As I said I'm able to do a MIP to my satisfaction by passing
planes (in MODELVIEW) through a fixed 3D texture map.  However
it was suggested that I should attempt to fix the viewpoint and rotate
the texture map.  This is where I get lost.  I do not understand the
way automatic texture generation works.  In particular the S, T and R
planes.

In particular I don't understand what these calls do:

float planeS[]={1.0f, 0.0f, 0.0f, 1.0f};
float planeT[]={0.0f, 1.0f, 0.0f, 1.0f};
float planeR[]={0.0f, 0.0f, 1.0f, 1.0f};


glTexgenfv(GL_S, GL_EYE_PLANE, planeS);
glTexgenfv(GL_T, GL_EYE_PLANE, planeT);
glTexgenfv(GL_R, GL_EYE_PLANE, planeR);

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

If the texture is rotated then shouldn't these planeS/T & R
be multiplied by some matrix?

I've managed to rotate a texture in 2D and map it onto a
square without the use of these functions.  I can not
see why this example shouldn't extend itself to a 3D texture.
I've attached some sample code here.




begin 666 main.cpp
M(VEN8VQU9&4@/&EO<W1R96%M/@H*(VEN8VQU9&4@/$=,550O9VQU="YH/@HC
M:6YC;'5D92 \<W1D;&EB+F@^"B-I;F-L=61E(#QS=&1I;RYH/@H*(V1E9FEN
M90EI5VED=&@@*#$V*S(I"B-D969I;F4):4AE:6=H=" H,38K,BD*"G-T871I
M8R!'3'5B>71E(&EM86=E6VE(96EG:'1=6VE7:61T:%U;,UT["G-T871I8R!'
M3'5I;G0@=&5X3F%M93L*"G9O:60@;6%K94EM86=E*'9O:60I"GL*(" @(&EN
M="!S+"!T.PH@(" @9F]R("AS/3 [(',@/" Q.#L@*RMS*0H@(" @>PH@(" @
M(" @(&9O<B H=#TP.R!T(#P@,3@[("LK="D*(" @(" @("!["B @(" @(" @
M(" @(&EM86=E6W1=6W-=6S!=(#T@,#L*(" @(" @(" @(" @:6UA9V5;=%U;
M<UU;,5T@/2 P.PH@(" @(" @(" @("!I;6%G95MT75MS75LR72 ](#(U-3L*
M(" @(" @("!]"B @("!]"B @("!F;W(@*',],3L@<R \(#$W.R!S*RLI"B @
M("!["B @(" @(" @9F]R("AT/3$[('0@/" Q-SL@="LK*0H@(" @(" @('L*
M(" @(" @(" @(" @:6UA9V5;=%U;<UU;,%T@/2 H1TQU8GET92D@*"AS+3$I
M("H@,3<I.PH@(" @(" @(" @("!I;6%G95MT75MS75LQ72 ]("A'3'5B>71E
M*2 H*'0M,2D@*B Q-RD["B @(" @(" @(" @(&EM86=E6W1=6W-=6S)=(#T@
M*$=,=6)Y=&4I("@Q*3L*(" @(" @("!]"B @("!]"GT*"G9O:60@:6YI="AV
M;VED*0I["B @("!G;$-L96%R0V]L;W(@*# N,"P@,"XP+" P+C L(# N,"D[
M"B @("!G;%-H861E36]D96PH1TQ?1DQ!5"D["B @("!G;$5N86)L92A'3%]$
M15!42%]415-4*3L*"B @("!M86ME26UA9V4H*3L*"B @("!G;%!I>&5L4W1O
M<F5I*$=,7U5.4$%#2U]!3$E'3DU%3E0L(#$I.PH*(" @(&=L1V5N5&5X='5R
M97,H,2P@)G1E>$YA;64I.PH@(" @9VQ":6YD5&5X='5R92A'3%]415A455)%
M7S)$+"!T97A.86UE*3L*"B @("!G;%1E>%!A<F%M971E<FDH1TQ?5$585%52
M15\R1"P@1TQ?5$585%5215]74D%07U,L($=,7T-,04U0*3LO+U]43U]"3U)$
M15(I.PH@(" @9VQ497A087)A;65T97)I*$=,7U1%6%154D5?,D0L($=,7U1%
M6%154D5?5U)!4%]4+"!'3%]#3$%-4"D[+R]?5$]?0D]21$52*3L*"B @("!G
M;%1E>%!A<F%M971E<FDH1TQ?5$585%5215\R1"P@1TQ?5$585%5215]-04=?
M1DE,5$52+"!'3%].14%215-4*3L*(" @(&=L5&5X4&%R86UE=&5R:2A'3%]4
M15A455)%7S)$+"!'3%]415A455)%7TU)3E]&24Q415(L($=,7TY%05)%4U0I
M.PH*(" @(&=L16YA8FQE*$=,7U1%6%154D5?1T5.7U,I.PH@(" @9VQ%;F%B
M;&4H1TQ?5$585%5215]'14Y?5"D["@H@(" @9VQ497A);6%G93)$*$=,7U1%
M6%154D5?,D0L(# L($=,7U)'0BP@:5=I9'1H+"!I2&5I9VAT+" Q+"!'3%]2
M1T(L($=,7U5.4TE'3D5$7T)95$4L(&EM86=E*3L*(" @(&=L16YA8FQE*$=,
M7U1%6%154D5?,D0I.PI]"B @(" O+V9L;V%T('!L86YE4UM=(#T@>S$N,&8L
M(# N,&8L(# N,&8L(#$N,&9].PH@(" @+R]F;&]A="!P;&%N951;72 ]('LP
M+C!F+" Q+C!F+" P+C!F+" Q+C!F?3L*(" @("\O9VQ497A'96YF=BA'3%]3
M+"!'3%]%645?4$Q!3D4L('!L86YE4RD["B @(" O+V=L5&5X1V5N9G8H1TQ?
M5"P@1TQ?15E%7U!,04Y%+"!P;&%N950I.PH@(" @+RH*(" @(&=L5F5R=&5X
M,V8H+3$N,"P@+3$N,"P@,"XP*3L*(" @(&=L5F5R=&5X,V8H*S$N,"P@+3$N
M,"P@,"XP*3L*(" @(&=L5F5R=&5X,V8H*S$N,"P@*S$N,"P@,"XP*3L*(" @
M(&=L5F5R=&5X,V8H+3$N,"P@*S$N,"P@,"XP*3L*(" @("HO"B @(" O+V=L
M5&5X1V5N:2A'3%]3+"!'3%]415A455)%7T=%3E]-3T1%+"!'3%]%645?3$E.
M14%2*3L*(" @("\O9VQ497A'96YI*$=,7U0L($=,7U1%6%154D5?1T5.7TU/
M1$4L($=,7T5915],24Y%05(I.PH*=F]I9"!D:7-P;&%Y*'9O:60I"GL*(" @
M('-T871I8R!F;&]A="!R/3 N,#L*"B @("!G;$-L96%R*$=,7T-/3$]27T)5
M1D9%4E]"250@?"!'3%]$15!42%]"549&15)?0DE4*3L*(" @( H@(" @9VQ-
M871R:7A-;V1E*$=,7U1%6%154D4I.PH@(" @9VQ,;V%D261E;G1I='DH*3L*
M(" @(&=L5')A;G-L871E9B@K,"XU+" K,"XU+" P+C I.PH@(" @9VQ2;W1A
M=&5F*'(L(# N,"P@,"XP+" Q+C I.PH*(" @(&=L36%T<FEX36]D92A'3%]-
M3T1%3%9)15<I.PH@(" @9VQ,;V%D261E;G1I='DH*3L*(" @( H@(" @9VQ"
M96=I;BA'3%]154%$4RD["B @(" @(" @9VQ697)T97@S9B@M,2XP+" M,2XP
M+" P+C I.PH@(" @(" @(&=L5F5R=&5X,V8H(#$N,"P@+3$N,"P@,"XP*3L*
M(" @(" @("!G;%9E<G1E>#-F*" Q+C L(" Q+C L(# N,"D["B @(" @(" @
M9VQ697)T97@S9B@M,2XP+" @,2XP+" P+C I.PH@(" @9VQ%;F0H*3L*(" @
M( H@(" @9VQ&;'5S:"@I.PH@(" @9VQU=%-W87!"=69F97)S*"D["B @(" *
M(" @('(@/2!R("L@+C U.PI]"G9O:60@<F5S:&%P92AI;G0@=RP@:6YT(&@I
M"GL*(" @(&=L5FEE=W!O<G0H,"P@,"P@*$=,<VEZ96DI('<L("A'3'-I>F5I
M*2!H*3L*(" @(&=L36%T<FEX36]D92A'3%]04D]*14-424].*3L*(" @(&=L
M3&]A9$ED96YT:71Y*"D["B @("!G;'5097)S<&5C=&EV92@V,"XP+" H1TQF
M;&]A="D@=R\H1TQF;&]A="D@:"P@,2XP+" S,"XP*3L*(" @(&=L5')A;G-L
M871E9B@P+C L,"XP+"TS+C I.PH@(" @9VQ-871R:7A-;V1E*$=,7TU/1$5,
M5DE%5RD["B @("!G;$QO861)9&5N=&ET>2@I.PI]"@IV;VED(&ED;&4H=F]I
M9"D*>PH@(" @9VQU=%!O<W12961I<W!L87DH*3L*?0H*=F]I9"!K97EB;V%R
M9"AU;G-I9VYE9"!C:&%R(&ME>2P@:6YT('@L(&EN="!Y*0I["B @("!S=VET
M8V@@*&ME>2D@>PH@(" @8V%S92 R-SH*(" @(" @("!E>&ET*# I.PH@(" @
M8G)E86L["B @("!]"GT*"FEN="!M86EN*&EN="!A<F=C+"!C:&%R*BH@87)G
M=BD*>PH@(" @9VQU=$EN:70H)F%R9V,L(&%R9W8I.PH@(" @9VQU=$EN:71$
M:7-P;&%Y36]D92A'3%547U-)3D=,12!\($=,551?4D="('P@1TQ55%]$15!4
M2"D["B @("!G;'5T26YI=%=I;F1O=U-I>F4H,C4P+" R-3 I.PH@(" @9VQU
M=$EN:717:6YD;W=0;W-I=&EO;B@Q,# L(#$P,"D["B @("!G;'5T0W)E871E
M5VEN9&]W*&%R9W9;,%TI.PH@(" @:6YI="@I.PH@(" @9VQU=%)E<VAA<&5&
M=6YC*')E<VAA<&4I.PH@(" @9VQU=$1I<W!L87E&=6YC*&1I<W!L87DI.PH@
M(" @9VQU=$ED;&5&=6YC*&ED;&4I.PH@(" @9VQU=$ME>6)O87)D1G5N8R H
M:V5Y8F]A<F0I.PH@(" @9VQU=$UA:6Y,;V]P*"D["B @("!R971U<FX@,#L@
#"GT*
`
end

"JustSomeGuy" <nope@nottelling.com> wrote in message 
news:YMlbd.735024$gE.516330@pd7tw3no...

> As I said I'm able to do a MIP to my satisfaction by passing
> planes (in MODELVIEW) through a fixed 3D texture map.  However
> it was suggested that I should attempt to fix the viewpoint and rotate
> the texture map.  This is where I get lost.  I do not understand the
> way automatic texture generation works.  In particular the S, T and R
> planes.
>
> In particular I don't understand what these calls do:
>
> float planeS[]={1.0f, 0.0f, 0.0f, 1.0f};
> float planeT[]={0.0f, 1.0f, 0.0f, 1.0f};
> float planeR[]={0.0f, 0.0f, 1.0f, 1.0f};
>
>
> glTexgenfv(GL_S, GL_EYE_PLANE, planeS);
> glTexgenfv(GL_T, GL_EYE_PLANE, planeT);
> glTexgenfv(GL_R, GL_EYE_PLANE, planeR);
>
> glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
> glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
> glTexGeni(GL_R, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
>
> If the texture is rotated then shouldn't these planeS/T & R
> be multiplied by some matrix?

Yes, they should be multiplied, but not directly by you.  You
tell OpenGL how to do that.

The Red Book has a description of how the texture coordinates
are generated.  Let a vertex have eye coordinates (xe,ye,ze,we).
Let M be the modelview matrix.  Let prodS[] be the 4-tuple that
is obtained by multiplying planeS[] by M^{-1}, the inverse of M.
Similar definitions for prodT[], prodR[].  In their most general
form, the texture coordinates are homogeneous vectors (s,r,t,q),
which are analogous to (x,y,z,w) coordinates.  If you were to
also enable generation of q coordinates in the manner you have
shown, then planeQ[] = { 0,0,0,1} and there is a corresponding
prodQ[].  The generated coordinates are
    s = prodS[0]*xe + prodS[1]*ye + prodS[2]*ze + prodS[3]*we
    t = prodT[0]*xe + prodT[1]*ye + prodT[2]*ze + prodT[3]*we
    r = prodR[0]*xe + prodR[1]*ye + prodR[2]*ze + prodR[3]*we
    q = prodQ[0]*xe + prodQ[1]*ye + prodQ[2]*ze + prodQ[3]*we

In the special case of the plane*[] vectors you have chosen, these
equations reduce to
    column(s,t,r,q) = M^{-1}*column(xe,ye,ze,we)
where column() indicates the quantity is a 4-by-1 column
vector (such is the fate of ASCII mathematics on news groups).

For example, if the modelview matrix is the identity, then
(s,t,r,q) = (xe,ye,ze,we), in which case the generated texture
coordinates for a vertex are the eye coordinates for that vertex.

The way you generate modelview matrices for the "projector
camera" is to tell OpenGL to use the texture matrix stack:
    glMatrixMode(GL_TEXTURE);
As you move the projector camera about, you can use calls
such as glFrustum and gluLookAt to push matrices onto this
stack.

--
Dave Eberly
http://www.magic-software.com