I don't know what might be wrong now, but i would suggest to try something but in view-space as it should give you same results as in world-space.

You can transform your check_pos in view-space and do the compare with view-space position:

float3 check_pos_vs = mul( m_V, check_pos ) .xyz;
if (distance(view_pos, check_pos_vs) < 1.0)
return float4(1,0,0,1);

and let me know if that works.

Thanks for the suggestion. I just have tried that. Doesn't work with m_V, but using m_VP instead does!

At least approximately. Meanly, the check sphere is rendered correctly on the right spot, but it moves a bit with the players / camera movement. That's another reason why I wanted to do it all in world space. The engine seems to provide either the view space position sampler state (s_position), or the transformation matrix (m_VP) based on an approximate camera position with disregard to any applied camera physics effects such as head bobbing. That way I can't do my calculations precisely enough because the rendering generates graphical glitches. Having it all in world space shouldn't cause those side effects (I was hoping).

BTW, using m_V as intended instead of m_VP causes about the same effect as described before: The check sphere will be rendered when the player / camera is located within a range of < 1.0 meters from the check position. Does that ring a bell?

Head-bobbing does not matter at all, you need to debug and find actual problem elsewhere.

Maybe you should post whole shader so i can see whole picture. How do you obtain view_pos? From g-buffer?

The whole shader contains way too much code irrelevant to the topic to post here, but I've extracted all parts of interest here:

uniform float3x4 m_W;
uniform float3x4 m_V;
uniform float4x4 m_P;
uniform float3x4 m_WV;
uniform float4x4 m_VP;
uniform float4x4 m_WVP;

uniform sampler2D s_position;

float3 pos_1_world = float3( 146.73, 0.70, -85.29);

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

float4 check_pos_vs = mul(m_VP, float4(pos_1_world, 1));

if (distance(uv_posxy, check_pos_vs) < 1.0)
   final +=  float4(1,0,0,1);

That's all I got. All the uniform variables are just references to matrices or sampler states passed by the engine. How the engine calculates those and what buffers or registers might be involved I don't know. I basically just use what the engine gives me.

Whether or not camera (post-)effects such as head-bobbing matter or not I cannot say for sure, but when looking at the result I see that everything is fine and correct as long as the camera only turns around or moves slowly in one direction, but when doing bigger and/or abrupt movement changes such as sprinting, jumping, or leaning sidewards the result starts getting off.

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?

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.

You cannot have 2 pixel shaders run simultaneously, you probably meant "helper" function. If you don't want to post whole shader at least show me the whole "pipeline" for uv coordinates (how it is calculated/obtained). I suspect at this because the rest of code is correct.

It doesn't matter if you are in "post-processing stage", you must have vertex shader, even if you dont set it yourself it is possible that it is set for you behind scene/implicitly by their shader system.

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.

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