My suggestion was done before somebody mentioned a portal. I guess that somehow changes the requirement, but I don’t have a solution to suggest, I’ve never done portals. The linked video sounds like it should have plenty of suggestions?
I assumed you wanted to show a rendered texture in a 3d quad in the world.
Ah, OK. Fair enough.
Yes, I’m almost there, it’s just this one final step (I hope), keeping the render inside the rectangle.
Just had a quick look and first thing I noticed is your camera near plane, which is set to 0.1 which might introduce clipping if you are near the portal. I would set it to something like 0.001 and decrease the far plane to 100.
Also in your ApplyAndCropTextureBlue script on Line #113 you are converting your vertex world position to screen space. But what happens if this is not possible? Meaning the vertex is not in screen space. Does this result in undefined behaviour?
Seems like this is somehow related with your problem, as it only happens when the portal does not fit on screen.
Reducing “Near Clip” was one of the first things I tried but it doesn’t help (in fact, it introduces an artefact and flickering).
I, too, though that it might be an issue with the world-to-screen conversion. Indeed, these values look like a likely cause:
Renders correctly
[
-2026791.601781152, 1372756.0914588473,
-2026791.6017792993, -1446096.2382574677,
761.787857167391, 1289.666117420334,
761.7878571673912, -415.70118738656015
]
Renders incorrectly
[
415889.4951735449, -279507.14710722025,
415889.4951736223, 295579.9674720668,
757.3918015702643, 1292.6350019286103,
757.3918015702645, -418.84295230932025
]
But after further experimentation (PlayCanvas | HTML5 Game Engine) I’m not so sure.
Correct
[
3603.666493061614, -1150.3482577680213,
3603.666493061615, 2177.2492314664587,
-1683.9788478775722, 2069.2388950468257,
-1683.9788478775727, -1258.3585941876547
]
Incorrect
[
3602.5581986625775, -1150.3482577680213,
3602.5581986625784, 2177.2492314664587,
-1682.870553478536, 2069.2388950468257,
-1682.8705534785363, -1258.3585941876547
]
Oh, and bear in mind that the render error occurs inconsistently: occurring when some vertices are out-of-bounds but not for others.
And never when the following is not used
gl_Position /= gl_Position.w;
I don’t want to jinx it, but I think I’ve finally fixed it.
Vertex shader
gl_Position = matrix_viewProjection * matrix_model * vec4(aPosition, 1.0);
vPosition = gl_Position;
vW = gl_Position.w;
Fragment shader
vec4 position = vPosition / vW;
vec2 uv = (position.xy + 1.0) / 2.;
gl_FragColor = texture2D(uColorBuffer, uv);
Basically, I’m applying w after the interpolation. Which seems wa-a-a-ay too easy.
This has taken me over a year to work out, so I honestly don’t believe it’s correct. And removes the need for the frame corner calculation?!?
I’ll test it further and if I’m hallucinating I’ll remove this comment!
That’s what texture2DProj I suggested does. Try using that.
The second parameter needs to be a vec4.
I unsuccessfully tried:
vec4 position1 = vPosition;
position1 = (position1 + 1.0) / 2.;
gl_FragColor = texture2DProj(uColorBuffer, position1);
It still seems to need dividing by w, i.e.:
vec4 position1 = vPosition / vW;
position1 = (position1 + 1.0) / 2.;
gl_FragColor = texture2DProj(uColorBuffer, position1);
or am I missing something?
try
gl_FragColor = texture2DProj(uColorBuffer, vPosition);
Sadly not. 
I think this is the correct way. Sebastian Lague does the same in his tutorial.
Indeed he does. That’s the difference what he said and what I thought it he said. 
PS Thanks for the help, guys. Much appreciated and very helpful.