inconsistent pre-computed fragment shader matrices

1. A concise explanation of the problem you’re experiencing.

When reversing the rendering pipeline in a post-processing fragement shader, different matrices that should be isomorphic behave differently.

2. A minimal code example.

As far as I can tell worldPos and otherWorldPos are not the same, but should be (roughly, allowing for floating point inaccuracies).

void main(void)
{
vec2 screenPos = (gl_FragCoord.xy / czm_viewport.zw) * 2.0 - 1.0;
vec4 clipPos = vec4(screenPos, 1.0, 1.0) / gl_FragCoord.w;
vec4 eyePos = czm_inverseProjection * clipPos;

vec4 worldPos = czm_inverseView * eyePos;
vec4 otherWorldPos = czm_inverseViewProjection * clipPos;
gl_FragColor = length(normalize(otherWorldPos) - normalize(worldPos)) < 0.1
    ? vec4(1.0)  // should be white
    : vec4(0.0); // is in fact mostly black, but not completely O.o

}

``

When using worldPos I get sensible results for my further calculations (see my panorama rendering question), but not when using otherWorldPos.

3. Context

I was just trying to use the most efficient way to compute world coordinates to do “rendering” of a panorama in a fragment shader and was really confused that I got garbage results.

4. The Cesium version you’re using, your operating system and browser.

1.48

Ubuntu 18.04

Firefox Nightly & Google chrome

a screenshot of the result of the shader in Firefox Nightly 65.0a1 (2018-11-05) (64-bit)

I’m not sure off the top of my head where the inconsistency is coming from. I would try to print out the matrices before they are passed to the shader as uniforms to see if they’re being created/updated correctly and track it down that way.

I posted some thoughts in your other thread that might lead to an easier solution. If you haven’t already, make sure to check out the “Post Processing” examples on Sandcastle (https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/). Might provide a simpler interface for some of these tasks.