• Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

### #ActualMeltac

Posted 17 July 2012 - 02:36 PM

You can certainly do whatever math you want in a pixel shader, but you can't change what pixel is being defined at that point in the pipeline.  The math I posted for the vertex shader would work in a pixel shader if you have the right data, but the pixel being processed has already been defined.

That wouldn't be the issue. I don't need to change any pixel's position either in world nor in screen space. I just need want to do the following:
• Take the world space sun position and mirror that spot on the axis of the camera to get a virtual world point opposite to the sun
• Calculate the screen space coordinate of that point with perspective projection
• Check whether the currently processed pixel is within some screen-space distance (in 2D) range to that projected spot.
• If so, output some color blended into the original pixel color.

When done this would result in a rainbow being drawn as some sort of post process effect from within my pixel shader.

So, is this possible with that code snippet above, and if so, why does the mul(float4(worldPos, 1), m_WVP) result in an incorrect screen position?

EDIT:
I have tested several different projection approaches and matrices. The overall result is always the same: When I turned the camera to the left or right, the calculated screen position is not accurate.

More precisely, I "moves" over the screen while turning in the correct manner as long as near the screen center. Then, when about 1/4 of the screen away from center, it starts moving "faster", meaning the calculated position is further away from the center than it should be. Then, when coming to some 3/4 of the screen (i.e. near the left or right border), the calculated point moves too slow, i.e. is not enough right/left positioned.

This happens not abruptly but fluently, like some roller coaster movement, first the calculated position wanders too much left/right, then too few left/right. Seems to depend on the circular movement of turning, but I couldn't figure out how to express this in a formula or what adjustments must take place to correct this.

### #6Meltac

Posted 17 July 2012 - 09:24 AM

You can certainly do whatever math you want in a pixel shader, but you can't change what pixel is being defined at that point in the pipeline.  The math I posted for the vertex shader would work in a pixel shader if you have the right data, but the pixel being processed has already been defined.

That wouldn't be the issue. I don't need to change any pixel's position either in world nor in screen space. I just need want to do the following:

• Take the world space sun position and mirror that spot on the axis of the camera to get a virtual world point opposite to the sun
• Calculate the screen space coordinate of that point with perspective projection
• Check whether the currently processed pixel is within some screen-space distance (in 2D) range to that projected spot.
• If so, output some color blended into the original pixel color.

When done this would result in a rainbow being drawn as some sort of post process effect from within my pixel shader.

So, is this possible with that code snippet above, and if so, why does the mul(float4(worldPos, 1), m_WVP) result in an incorrect screen position?

### #5Meltac

Posted 17 July 2012 - 09:23 AM

You can certainly do whatever math you want in a pixel shader, but you can't change what pixel is being defined at that point in the pipeline.  The math I posted for the vertex shader would work in a pixel shader if you have the right data, but the pixel being processed has already been defined.

That wouldn't be the issue. I don't need to change any pixel's position either in world nor in screen space. I just need want to do the following:
• Take the world space sun position and mirror that spot on the axis of the camera to get a virtual world point opposite to the sun
• Calculate the screen space coordinate of that point with perspective projection
• Check whether the currently processed pixel is within some screen-space distance (in 2D) range to that projected spot.
• If so, output some color blended into the original pixel color.

When done this would result in a rainbow being drawn as some sort of post process effect from within my pixel shader.

So, is this possible with that code snippet above, and if so, why does the mul(float4(worldPos, 1), m_WVP) result in an incorrect screen position?

### #4Meltac

Posted 17 July 2012 - 09:23 AM

You can certainly do whatever math you want in a pixel shader, but you can't change what pixel is being defined at that point in the pipeline.  The math I posted for the vertex shader would work in a pixel shader if you have the right data, but the pixel being processed has already been defined.

That wouldn't be the issue. I don't need to change any pixel's position either in world or screen space. I just need want to do the following:

• Take the world space sun position and mirror that spot on the axis of the camera to get a virtual world point opposite to the sun
• Calculate the screen space coordinate of that point with perspective projection
• Check whether the currently processed pixel is within some screen-space distance (in 2D) range to that projected spot.
• If so, output some color blended into the original pixel color.

When done this would result in a rainbow being drawn as some sort of post process effect from within my pixel shader.

So, is this possible with that code snippet above, and if so, why does the mul(float4(worldPos, 1), m_WVP) result in an incorrect screen position?

### #3Meltac

Posted 17 July 2012 - 09:23 AM

You can certainly do whatever math you want in a pixel shader, but you can't change what pixel is being defined at that point in the pipeline.  The math I posted for the vertex shader would work in a pixel shader if you have the right data, but the pixel being processed has already been defined.

That wouldn't be the issue. I don't need to change any pixel's position either in world or screen space. I just need want to do the following:
• Take the world space sun position and mirror that spot on the axis of the camera to get a virtual world point opposite to the sun
• Calculate the screen space coordinate of that point with perspective projection
• Check whether the currently processed pixel is within some screen-space distance (in 2D) range to that projected spot.
• If so, output some color blended into the original pixel color.

When done this would result in a rainbow being drawn as some sort of post process effect from within my pixel shader.

So, is this possible with that code snippet above, and if so, why does the mul(float4(worldPos, 1), m_WVP) result in an incorrect screen position?

### #2Meltac

Posted 17 July 2012 - 09:23 AM

You can certainly do whatever math you want in a pixel shader, but you can't change what pixel is being defined at that point in the pipeline.  The math I posted for the vertex shader would work in a pixel shader if you have the right data, but the pixel being processed has already been defined.

That wouldn't be the issue. I don't need to change any pixel's position either in world or screen space. I just need want to do the following:
• Take the world space sun position and mirror that spot on the axis of the camera to get a virtual world point opposite to the sun
• Calculate the screen space coordinate of that point with perspective projection
• Check whether the currently processed pixel is within some screen-space distance (in 2D) range to that projected spot.
• If so, output some color blended into the original pixel color.

When done this would result in a rainbow being drawn as some sort of post process effect from within my pixel shader.

So, is this possible with that code snippet above, and if so, why does the mul(float4(worldPos, 1), m_WVP) result in an incorrect screen position?

PARTNERS