Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Mar 2012
Offline Last Active Today, 06:35 AM

Posts I've Made

In Topic: Convert view space to world space issues

18 August 2014 - 03:29 AM

Thanks, I'll check that. If nothing else, it at least would serve as proof for or against the correctness of the matrix provided by the engine (and my code using that one).

In Topic: Convert view space to world space issues

17 August 2014 - 01:45 PM

Have you tried to invert view matrix at shader by hand?


I have asked how to do that earlier in this thread but unfortunately nobody replied on it. And in other threads here people keep just replying " don't ! " when somebody asks for it. This said, I would have tried if I would know how...

In Topic: Convert view space to world space issues

17 August 2014 - 07:36 AM

That seems fine, there must be something else wrong then. wacko.png


As I said, I suspect that the engine passes some strange / unusual / wrong data to the shader, maybe the transformation matrix is not intended to be used that way in the post-processing stage or something. Not sure, though. Unfortunately I've met nobody so far who could confirm or explain this.

In Topic: Convert view space to world space issues

16 August 2014 - 02:38 PM

You are right, there must be some (implicit) vertex shader which has probably just not been made accessible / changeable by the devs.


I didn't mean running two pixel shaders simultaneously, nor did I mean "helper" function. I just wanted to say that I do not have (or have access) to any vertex shader on the post processing stage, so the buffer input I get in that post process shader is basically the output (i.e. color etc.) from the last pixel shader before the pipeline passed the data to the post processing - it doesn't matter in this case whether there's a "hidden" vertex shader inbetween because it would basically just handle over its own inputs without doing any vertex manipulations or the like.


So, here's the portion showing the input of the coordinates to the pixel shader:


struct v2p
  float4 tc0:         TEXCOORD0;    // Center
  float4 tc1:         TEXCOORD1;    // LT         
  float4 tc2:         TEXCOORD2;    // RB
  float4 tc3:         TEXCOORD3;    // RT
  float4 tc4:         TEXCOORD4;    // LB
  float4 tc5:        TEXCOORD5;    // Left    / Right    
  float4 tc6:        TEXCOORD6;    // Top  / Bottom


float4 main(v2p I):COLOR {

float2 center=I.tc0.xy;





Normally quite all stuff (sampling color / position and the like) is done using the center coordinate (that's also the case in the original / unmodded ) shader. That's why I'm using that coordinate as input to all my stuff as well.

In Topic: Convert view space to world space issues

16 August 2014 - 01:56 PM

float3 uv_posxy = tex2D(s_position, center).xyz;

The varibale name "center" used for uv coordinate suggest that it is constant for every pixel (center of screen?), tho it should not because you need to sample view-pos from g-buffer, how/is it passed from vertex shader?



Sorry to have missed that when extracting the relevant parts from the shader code. "center" refers to the uv coordinate passed from the previous shader unit (which is in this case not a vertex but another pixel shader as I'm in post-processing stage), not the screen center. Misleading, I know.