I am playing around with this chapter and decide to implement it in a X3D file.
Only a single pass is implemented as the rest will need to wait for @michalis to improve current ScreenEffect APIs 
X3D file, open it with view3dscene: https://drive.google.com/file/d/1AxrHGbE8s2R28ocVNiaGBw-DVDv5OCsI/view?usp=sharing
Screenshot: https://i.imgur.com/OEdnrH7.png
Good job that’s nice, screen effects very important
(google drive link dosen’t public)
Fixed. Thanks for noticing it.
Looks cool, thank you!
Note about code: you should not use texture2D(screen_depth, ...) or texture2D(screen, ...) to query the texture. Instead use functions like screenf_get_color, screenf_get_depth to get the values.
Also don’t access tex_coord_frag directly, use screenf_position().
The GLSL functions are referenced on https://castle-engine.io/x3d_extensions_screen_effects.php .
I notice those built-in functions require/return values in resolution range instead of the usual 0…1 range so I don’t like to use it.
That said I think we should expose view matrix and projection matrix as built-in uniforms for ScreenEffect, as I found many use-cases require those 2.
Edit: I also think we need a new set of built-in functions that accept/return values in 0…1 range (if we dont want to access for example tex_coord_frag directly). The current set of functions may be good in current implementation of ScreenEffect, but in the future when we can access different ScreenEffect buffers with different resolutions, these functions will only result in unnecessary conversions between these buffers.
I just improved the https://castle-engine.io/x3d_extensions_screen_effects.php .
That said I think we should expose view matrix and projection matrix as built-in uniforms for ScreenEffect, as I found many use-cases require those 2.
I agree. But it depends on the effect. I have a lot of effects (and “The Unholy Society” and “Escape from the Universe” we have more) where these matrix values are not needed.
Added to TODO, I’ll introduce a boolean like needsViewProjectionMatrix to ScreenEffect node.
I also think we need a new set of built-in functions that accept/return values in 0…1 range
Agreed.
I deliberately wanted to start with more friendly API, and indeed it means that some functions divide by screen size, and later some functions multiply by it. If your effect is not doing anything where this matters (e.g. you don’t want to look “10 pixels to the left”, instead you want to look “1/100 of width to the left”), then the existing functions waste time (and precision) doing useless calculations.
Added to TODO to introduce new set of functions. tex_coord_frag will be then renamed to something better, like screenc_position (if new functions will be named screenc_xxx).
For anyone who finds this forum thread by web search:
This is now a ticket https://trello.com/c/wmKO7kn3/96-make-glsl-api-for-screen-effects-that-avoids-dividing-multiplying-by-screen-sizes
