Godot: 3d screen reading shaders documentation issue

[Zireael07]

Godot version:
3.0.2

OS/device including version:
Radeon 6630M, Win 7 x64

Issue description:
Either there's a bug, or documentation isn't entirely truthful.

https://i.imgur.com/nHkqAG2.gifv

http://docs.godotengine.org/en/latest/tutorials/shading/screen-reading_shaders.html

As a result, this simple 2D fragment shader:

void fragment() {}
COLOR=textureLod( SCREEN_TEXTURE, SCREEN_UV, 0.0);
}

results in an invisible object, because it just shows what lies behind.

Umm, no, if I toggle the shadered quad, I don't see the clouds anymore. I suspect there is some problem with alpha-using materials (the clouds custom shader uses alpha and I am seeing the same problem in game with barriers, which use a bog-standard spatial material with a partially transparent png).

Steps to reproduce:
See above.

Minimal reproduction project:

Possibly tomorrow? don't have time today

[Zireael07]

Stof on Discord cleared up the confusion, screen texture grabs after opaque pass but before transparent pass (and it's supposedly mentioned elsewhere in the documentation).

I can't tag, but this is then clearly a documentation issue and not a rendering bug.

[Megalomaniak]

I think for your clouds fragment discard might work?

[Zireael07]

I found another workaround yesterday, that is - simply making the shadered quad partially transparent (giving it some alpha).

As for discard, reportedly alpha 0 is more performant than discard.

[Zireael07]

Bumpity bump. Two years passed, and that incredibly important bit still is not called out in documentation.

[nathanfranke]

I still don't get how this is a renderer issue when it works in Unity and (assuming) most other game engines.

Screen texture should give you what's on the screen.

[Calinou]

@nathanfranke Different renderers have different limitations. We can't magically lift them overnight :slightly_smiling_face:

I don't know if this will be changed in Godot 4.0.

[clayjohn]

@nathanfranke Maybe it serves a different purpose in Unity. In Godot SCREEN_TEXTURE is used as a way to have highly customized transparency (including reflections and refractions). This means that objects that use SCREEN_TEXTURE must be treated like transparent objects and must be sorted into the transparent pass. You have to capture a texture before you use it, so the SCREEN_TEXTURE needs to be captured before the transparent pass.

If we captured the texture after after the transparent pass and then rendered the object after, it wouldn't properly blend with the transparent objects, and it will capture objects that appear in front of it.

These limitations are unique to Godot because Unity and many other 3D engines use deferred rendering (which comes with its own limitations regarding transparent objects.

[clayjohn]

For the record, it is explained in the doc already. But I will add bold warnings for users as it is currently easy to miss.

In the above image, the second sphere (top right) is using the same
source for SCREEN_TEXTURE as the first one below, so the first one
"disappears", or is not visible.

In 3D, this is unavoidable because copying happens when opaque rendering
completes.

In 2D, this can be corrected via the :ref:BackBufferCopy <class_BackBufferCopy>
node, which can be instantiated between both spheres. BackBufferCopy can work by
either specifying a screen region or the whole screen:

[Zireael07]

No, the quote is about two spheres using the same screen_texture, and not about alpha...