[FTEQW][REL]GLSL showreel - also mini tutorial

[toneddu2000]

Hello guys! It was quite a lot that I had the idea to create some code that showed the muscles underneath GLSL's post processing and shader support in FTE, so.. here it is!
When I was creating the skeleton of the project I asked myself: "What if I create a project without neither models, maps, nor textures, just procedural models and GLSL shaders?"
The idea behind this GLSL showreel is double face: the project (that lives in this page, with no additional physical contents, except for sounds files) and a mini-tutorial that explains how GLSL shaders and postprocessing are possible with FTE engine. Yeah, I know, mini-tutorial part is a bit lame, but, for now, it's the maximum I can do. If you have any input to share, please post it below and I'll add it with your credits

This is . It's not wonderful but I liked it for many reasons, first of all is that, for creating it, you'll need just the pieces of code I'll write in this topic: that's it, no 3d models, no textures, no maps! Crazy, isn't it? Well, let's see..

CSQC Warning: this mini-tutorial requires basic/mid knowledge of CSQC to understand it (otherwise you can just follow the steps and obtain the final project anyway, but that's half of the fun imo..)
a
License warning: GLSL showreel code is 100% written by me (Antonio Latronico) and placed under , so you can do basically what you want with it without any kind of restrictions, BUT (and this is very important) every GLSL file present in this mini-tutorial is not written by me (I downloaded from and "just" adapted to FTEism GLSL syntax), so you MUST pay attention to every GLSL file license header to be sure to credit every single author to avoid license infringement (unfortunately, 70% of GLSL files are released under CC non commercial license, so, forget about using those files for commercial projects..ugh..)

Nomenclature warning: When I talk about a shader, I describe .shader files stored in scripts subfolder in game data folder, when I talk about a GLSL file I mean glsl files in glsl subfolder in game data folder

GLSL files external licenses:

Overcast Sky
author: CaliCoastReplay


Warp Speed
author: David Hoskins 2013.


Synthetic aperture
author: FabriceNeyret2


Tileable Water Caustic
author: David Hoskins


Post Processing effect: ASCII
author: mattdesl


Post Processing effect: Black&White
author: lezard


Post Processing effect: Bloom
author: mAlk


Post Processing effect: Barrel Blur Chroma
author: hornet


Post Processing effect: Fast, Small-Radius GPU Median Filter
author: Morgan McGuire


Post Processing effect: GLSL depth of field (used as Motion Blur)
author: martins upitis

[toneddu2000]

[toneddu2000]

[Nahuel]

thats GREAT documentation about GLSL and FTE

Did you try something like sung light beams!! ??


Fte is so powerful, this helps a lot to all who want to get into this engine (I include myself)

I think I'm going to add some shader of these and test them with FREE-CS !!

I would really like to see some of those powerful shaders acting on counter strike 1.5 !!

I wonder what limitations there are in FTE for glsl !!! And if there is a distant possibility of doing something similar in DP (you know, csqc interacting with shaders) I still hope

Incredible, thank you very much.

[toneddu2000]

[Julius]

Really helpfull, thanks!

Maybe we should start a wiki on github or so where we can put all the nice documentation in one place? I wish Spike would finally use it or gitlab for the code and bugtracker as well... the current svn sourceforge repository is atrocious (not even talking about the outdated website ).

By the way, do GLSL shaders work seamlessly with the Vulkan renderer as well?

[toneddu2000]

[Spike]

depth: be aware that depth buffers are non-linear. the lpp_light.glsl fragment shader has some function to convert a depth value and texture coord back into a 3d worldspace coord. if you just try drawing the depth buffer as-is then yeah, you'll probably just get something really close to black.

regarding vulkan, the renderer I wrote does not contain its own glsl compiler thus it currently requires precompiled glsl, which means that all the ifdef stuff cannot work the same as with the gl renderer. instead it depends upon vulkan's specialisation constants for permutations and parms.
this sucks, of course so I really ougt to try and figure out some better solution some time.
nvidia drivers embed a glsl compiler but have no reflection stuff, iirc my implementation of it is also limited and can't handle permutations, and of course vendor specific so whatever.
but yeah, (optimised) spirv not having any reflection info means that fte depends upon metadata which requires specialised tools... specifically the 'makevulkanblob.c' program on fte's svn. it depends upon glslang's spirv compiler (which has various bugs with specialisation constants so I had to keep it using some old version of the vulkan sdk to avoid the worst of it). really the whole thing sucks.
so yeah, I don't really expect anyone to try writing any glsl/spir-v for fte's vulkan renderer.

toneddu2000, you might want to use s_diffuse/s_specular etc in your glsl instead of assuming that s_t0, s_t1 etc match them. doing so means that you can skip the extra {map foo} blocks in your .shader (although annoyingly you normally still need one, in order to specify the blend mode properly).


god rays: http://triptohell.info/moodles/junk/fte00016.jpg - just set r_sun_colour (and don't use a skybox)

[toneddu2000]

[toneddu2000]

[Spike]

regarding depth, remember to divide any projected texture coords by w before passing them to that function. read up on homogeneous coords some time for why this is needed.

deferred lights are basically just a sprite that covers the parts of the screen that the light should affect. These 'sprites' can either be provided via the engine from the .rtlights file/adddynamiclight builtin, or you can provide them as actual sprites yourself.
If your shader has the lpp_light directive inside it, then it will be 'drawn' after the regular gbuffer pass and before the lpp_wall stuff. its input texture will be the normalmap and depth values from the lpp_depthnorm shaders over the underlaying geometry, and its output is the raw lighting values. the lpp_wall shader is then given the output of those lighting 'sprites', and combines the lighting values with the diffuse textures.
its all single outputs right now, which means specular with deferred shading cannot really work right now. I'd like to come up with some nice configurable way to make the gbuffers extensible to allow for other effects, but I've not really gotten around to finalising anything in that regard (especially as I'd want it to apply to the vk+d3d11 renderers eventually too).

[toneddu2000]

[toneddu2000]