# A very basic question about texture projection

This topic is 3006 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi everybody, Sorry if this is a stupid question to you, but I really can't figure it out so please help me out. My understanding of the position output of a vertex shader is that it is a homogeneous 4D vector, so I'm thinking, the following two pieces of codes should have exactly the same results:
PS_OUTPUT vs(PS_INPUT In)
{
PS_OUTPUT Out;
Out.vPos = mul(float4(In.vPos, 1.0f), mtWorldViewProjection);
Out.vTexCoord = In.vTexCoord;
return Out;
}

and
PS_OUTPUT vs(PS_INPUT In)
{
PS_OUTPUT Out;
Out.vPos = mul(float4(In.vPos, 1.0f), mtWorldViewProjection);
Out.vPos /= Out.vPos.w;
Out.vTexCoord = In.vTexCoord;
return Out;
}

The only difference is the additional division by Out.vPos.w which will happen anyway. But this additional instruction changed the look of the texture from "perspective correct" to "perspective incorrect" (I don't know if I'm saying the right way, so here's an image to show what i mean: http://en.wikipedia.org/wiki/File:Perspective_correct_texture_mapping.jpg). Apparently it has something to do with the way the "perspective correction" is performed, but I really don't understand why that additional division would mess anything... Any idea? [Edited by - fang on December 4, 2009 7:23:54 AM]

##### Share on other sites
Quote:
 Original post by fangThe only difference is the additional division by Out.vPos.w which will happen anyway.
If it will happen anyway, then won't it happen twice if you also do it manually?

##### Share on other sites
but doesn't Out.vPos /= Out.vPos.w already achieves setting Out.vpos.w to 1? I mean it would be equivalent to this:
Out.vPos.x = Out.vPos.x / Out.vPos.w;
Out.vPos.y = Out.vPos.y / Out.vPos.w;
Out.vPos.z = Out.vPos.z / Out.vPos.w;
Out.vPos.w = Out.vPos.w / Out.vPos.w;

the last one sets Out.vPos.w to 1.

##### Share on other sites
Ah yes sorry.
The w component of the position is used to perform perspective correction of the texture coordinates though. So if it's always 1.0 then you're going to break the perspective correction logic.

Maybe you want:
Out.vPos.xyz /= Out.vPos.w;

What is the actual problem you're trying to solve here anyway?

##### Share on other sites
well I run into this thing when trying to implement deferred shading -- rendering a light source's bounding gemoetry (a cube for a point light source in my case) during the lighting pass. The pixel shader needs screen space coordinates, so I transform the vertexes in the vertex shader and then pass the transformed positions to the pixel shader as TEXCOORD0. But when these positions are interpolated and sent into the pixel shader, I found the positions twisted, just like the hardware didn't do "perspective correction" when it is needed. see the following image:

http://www.mediafire.com/?gmyljtn1omj

however I didn't mess with Out.vPos.w when getting this result. What I think is happening is that the texture (which is the scene in G-buffer) is parallel to the screen plane so perspective correction is NOT needed, but the positions from my geometry (the cube) indicates that the triangle to be textured is at an angle to the screen plane and SHOULD be corrected. So I tried to add that division instruction to the vertex shader to set w to 1, and surprisingly it solved the problem:

http://www.mediafire.com/?njjbt3maygo

But I still don't know how come the w component, not the z component or anything else gets to decide the perspective correction.

##### Share on other sites
btw I don't know how I'm supposed to attach images to my post here, would appreciate it if you can tell me...