GLSL

[fromhell]

and now i've attempted to port it. Sorry for the Q3TA shot here




I have problems with the dithering in the shader itself at the moment.  I had to tear up tr_backend a little to get this working above everything (and not just in the game - I intend to have even the menus without a game running post-processed).  This is a SIX PASS shader.


Pass1: leifx_dither
Pass2: leifx_gamma
Pass3: leifx_filter
Pass4: leifx_filter
Pass5: leifx_filter
Pass6: leifx_filter


Also on the way there I fixed your typo in the depth texture memory allocation so I have shaders working in 1920x1080 now

[fromhell]

Also I was able to combine parts of the EGAfilter, LeiFX, SSAO and Edges shader to produce this odd looking shader reminiscent of visuial novels

[Gig]

@Fromhell: Odd, but interesting.

@Hitchhiker: Do you remember the posts where I tried to suggest possible ways to improve glsl usage (most notably, to workaround the problem of needing different blendfunctions in the same shader, depending from the rendering mode)?
http://openarena.ws/board/index.php?topic=4767.msg48875#msg48875
http://openarena.ws/board/index.php?topic=4767.msg48889#msg48889
Some time ago I tried to see if "commenting a block" with "/*" and "*/" works in shaders (that would have allowed to "comment out" entire shader passes in standard mode -considering them in glsl mode only- with something like "/*glsl" and "glsl*/", without the need to specify "//GLSL" at the beginning of every single line of that stage). Well, it seems that "/*" "*/"does not work in shaders (test it yourself to be sure). D'oh! However you could still allow to manually "//GLSL" all lines of a certain stage (Note: IIRC, currently there is some bug with 0.8.8 glsl behavior which makes the glsl code be considered also when it should not? I don't remember exactly.): that, used together with the "skip" glsl program, should allow to make a shader correctly working in both standard and glsl modes.
Of course, both this and what follows can be supported...

Other than that, I still think that the more "clean" way to manage glsl shaders would be (as suggested in the second post linked above) using "sub-shaders": the main shader would "invoke" a glsl shader contained in a distinct text file (with a dedicated file extension?); the sub-shader would contain "stages" only (no surfaceparm, no deformvertexes, etc); in case GLSL is enabled the game would execute the stages contained in the sub-shader only (no even need to use the "skip" program)... in case GLSL is disabled the game would execute those contained in the main shader only; in case any glsl program used by the shader fails compiling, the game should fall back to use the standard shader instead.
At the time of that post, I said maybe it was better to simply place a keyword in the main shader to mention there was a glsl sub-shader for it, and the game would have automatically searched for a sub-shader with the same name of the main one... now, after having created a map for my own with customized shaders (and recently also after having noticed more or less how q3map_flare works by invoking a sub-shader), I think it would be better for the special keyword to require to specify the name of the sub-shader: this would allow to have different versions of the main shader (e.g. emitting light and not) to share the same glsl sub-shader.

[fromhell]

What about a function that's just like the portal rendering

but, it's rendered to a texture?  Logically this would lead to reflections

[Hitchhiker]

hi, I just got back from traveling and am tired a little. posting here just to let you know I'm not gone. So just a quick reply - I'll re-read your posts these days and will reply in a better way.
as for my progress, I've got the r_postprocess to take multiple effects and have the possibility to control each effect (at a basic level.. i.e. quality - fast or good looking). I still have to figure out how to capture the lightmap texture coordinates and the texture used by a shader (I need this globally for a shader so this information could be made available to the glsl at any stage of the shader).
The //GLSL escape keyword is now only used when glsl is activated so this can provide a mechanism for unique set of blend commands when glsl is active. Top of my head now I think using a separate subshader could be a good thing (and if no subshader is found the generic glsl program would be used - which would basically draw things using glsl but it would look as drawn with the classic opengl pipeline). But this subshader would require knowing how to get the correct info for those lightmaps.
@fromhell, which problems are you having with dithering? I can maybe help with that.

[Hitchhiker]

What about a function that's just like the portal rendering

but, it's rendered to a texture?  Logically this would lead to reflections

The portal functionality should (I'd even say 'will') produce a texture usable for the reflections. The part which I find difficult here is knowing how to store the rendered portal's texture in a way it could be referenced later when needed. i.e. Having multiple mirrors at different heights and directions - I think here multiple portal surfaces would be needed.
The way I understand portals, they are a complete q3 scene so cannot be rendered while one scene (i.e. main scene) is in the process of being rendered. not sure also at which time they are rendered (before or after the main scene) - to use them one would need to render them before the 'main' scene and have the reflected scene stored with some unique id & reference the right id during the main scene drawing. My level of knowing the Q3 renderer is not good enough to work this one out. I can check to see if Rend2 has reflections and see if this can be ported (but quick look now it seems it does not ).

[Hitchhiker]

Hitch, I know I have been too "verbose", but please read!  

I think this is important, for better GLSL support in future OA versions.

yes, I agree.

[Hitchhiker]

@Gig, I'm sorry for posting like this. I've read your post and wrote down your questions but when I tried replying with quoting got lost half way. A lesson learned for me - next time I'll write down my answers directly to the post form.
here goes, I hope you can find all the information you need.

re: difficulty to make things look good in both glsl and standard
I think this should no longer be a problem. I've corrected the error in processing of the //GLSL keyword and now it is done only when glsl is enabled. Will test and confirm.

re:backward compatibility
I think //glsl keyword should cover for this now that it is working.

adding //GLSL and the glsl parameters will make the stage run in glsl mode.
If a glsl program fails - stage becomes a standard one (one reason for not having separate glsl-only stage?). And if that stage has no non-glsl features it is marked invalid.

using:
[...]
//GLSL {
//GLSL program <name>
//GLSL }
[...]

very good idea! it might work, yes. I need to test this. This could actually be a solution to keeping things clean. so one would have a shader that works on older versions (with each stage having //GLSL program skip) and a last stage that would be entirely behind the //GLSL keywords and that invokes the glsl programs. I like this.

With this I think /*GLSL ... GLSL*/ would be just a different way of doing the same thing. It would make shader code a more human readable though.

If a glsl program fails compilation, the stage that uses it is brought back to the standard drawing method. with skipping the standard stages this would cause the 'missing texture' behavior I think. The missing texture would also appear in this case if we use the subshader way (as part of the standard q3 shader or as a separate file).

As for glsl support in 088, i'm not happy to say it but yes, it would be more of a beta-test drive and a way to get the technology included. even though it is functional (with few bugs that should now be fixed). For one, it is missing normals which play a good deal of information in glsl - now corrected. So I would say next version would be usable.

It is really a matter of organising more than technical because the patch for hardware specific shaders done by andrewj is a way of having a 'glsl' folder which can then have glsl specific shaders in it. it will make the developers keep their shader in two places though - so it comes down to having shader in one place with //GLSL keywords towards the end or have it in two places but without any //GLSL at all.
Not sure where the preferred way could be discussed (in the mapping forum or dev?)

[Hitchhiker]

@Hitchhiker:
Some time ago I tried to see if "commenting a block" with "/*" and "*/" works in shaders (that would have allowed to "comment out" entire shader passes in standard mode -considering them in glsl mode only- with something like "/*glsl" and "glsl*/", without the need to specify "//GLSL" at the beginning of every single line of that stage). Well, it seems that "/*" "*/"does not work in shaders (test it yourself to be sure). D'oh! However you could still allow to manually "//GLSL" all lines of a certain stage (Note: IIRC, currently there is some bug with 0.8.8 glsl behavior which makes the glsl code be considered also when it should not? I don't remember exactly.): that, used together with the "skip" glsl program, should allow to make a shader correctly working in both standard and glsl modes.
Of course, both this and what follows can be supported...

Yes, I belive /* would make OA ignore anything after that, until the */ escape sequence

Other than that, I still think that the more "clean" way to manage glsl shaders would be (as suggested in the second post linked above) using "sub-shaders": the main shader would "invoke" a glsl shader contained in a distinct text file (with a dedicated file extension?); the sub-shader would contain "stages" only (no surfaceparm, no deformvertexes, etc); in case GLSL is enabled the game would execute the stages contained in the sub-shader only (no even need to use the "skip" program)... in case GLSL is disabled the game would execute those contained in the main shader only; in case any glsl program used by the shader fails compiling, the game should fall back to use the standard shader instead.

I think this should be possible but kind of tricky to do. At the moment (what is ready made) is this:
either of the two options:
---------
option1 (one shader, in one file):
shadername
{
  surfparams
  {
   stage1, does everything we want for this shader in standard drawing
  //GLSL program skip
  }
  //GLSL {
  //GLSL stage2
  //GLSL program vertex
  //GLSL program fragment
  //GLSL }
}
--------------
option2 (two shaders, in two files)
in standard scripts folder:
shadername
{
  surfparams
  {
   stage1, does everything we want for this shader in standard drawing
  }
}

in another file, in glsl scripts folder:
shadername
{
  surfparams
  {
  stage2
  program vertex
  program fragment
  }
}
------------

At the time of that post, I said maybe it was better to simply place a keyword in the main shader to mention there was a glsl sub-shader for it, and the game would have automatically searched for a sub-shader with the same name of the main one... now, after having created a map for my own with customized shaders (and recently also after having noticed more or less how q3map_flare works by invoking a sub-shader), I think it would be better for the special keyword to require to specify the name of the sub-shader: this would allow to have different versions of the main shader (e.g. emitting light and not) to share the same glsl sub-shader.

I will need to check the q3map_flare and how it works. I need to understand at which point of game loop is this processed.

[fromhell]

@fromhell, which problems are you having with dithering? I can maybe help with that.

It's not ordered.  3dfx Voodoo had an ordered dither matrix.  Mine is just alternating dots, which works well for PC98 dithering but not 3dfx.

I've looked at code on shadertoy for ideas, but then I read that i's all CC-BY-NC-SA

[Gig]

Yes, I belive /* would make OA ignore anything after that, until the */ escape sequence

From a test I did time ago, I had the impression is shaders this did not work as expected. However I may have done something wrong back then, so do your own tests. If that does not work, it cannot be adapted for glsl purposes due to backwards compatibility...

option2 (two shaders, in two files)
in standard scripts folder:
shadername
{
  surfparams
  {
   stage1, does everything we want for this shader in standard drawing
  }
}

in another file, in glsl scripts folder:
shadername
{
  surfparams
  {
  stage2
  program vertex
  program fragment
  }
}

I have to think more about that (writing from cell phone now), however two different versions of the shader, with theoretical different surfaceparms may sound risky (side note: many surfaceparms are considered by map compiler -which I can guess we don't want to "fork"-... a few are considered by game -such as surfaceparm nomarks, IIRC).

I will need to check the q3map_flare and how it works. I need to understand at which point of game loop is this processed.

Note about that... From the little I understood, there are at least two ways to get flares in a shader. The simpler one is to set "light 1" line in the shader... the other one (which I can guess may allow more customization) is to set "q3map_flare [flareshaderpath/name]" instead, invoking a specific sub-shader. Some are in oaflares.shader, IIRC.
In both cases, IIRC, a q3map2 option has to be specified at map compiling time, otherwise flares won't be shown.

[fromhell]

also another shader idea... Motion blur?

But done by analyzing the changed refdef vectors between frames or something like that, and then using that to blur

Doom3 BFG did this kind of motion blur and it's much better than the lazy framebuffer blur

[Gig]

Also on the way there I fixed your typo in the depth texture memory allocation so I have shaders working in 1920x1080 now

Do you mean you found a bug in Hitch's code? Maybe you should tell exactly where it is, so hitch can fix it in his own sources, too...

[Hitchhiker]

Hi, I know where it is. Have seen it, now fixed.
Thanks for your help with this

[fromhell]

Does the generic shaders actually work? Like will I be able to have a shader replace the alpha blending function, for example?

Because I want to try a silly shader idea for alpha blending, like 4-bit alpha value modulation, to simulate PowerVR PCX1/2.   Also I want to try adding dithering to the blending functions since that's another thing 3dfx did

[Hitchhiker]

If I recall correctly, generic glsl shaders were disabled due to compilation warnings on some cards? But it would be a good idea to enable them back and sort these warnings out as it (the way I understand things) should slightly decrease rendering times. I'll have a look at it.
As for crunched alpha channel, It could be incorporated in the generic glsl programs - we'd just need to define a new uniform variable and a corresponding cvar.
For the blending, the multitexture generic glsl program has the blending mode supported (through the use of one uniform variable), but I imagine some proofing should be done at the shader level as well (to disable the OpenGL blending which runs in parallel with glsl processing?) as it would be simulated in the glsl program by dithering.. honestly, I'm not sure if this would work like that as I don't know how this was done on PowerVR (i.e. was the dithered pixel drawn with blending or just opaque... if you understand what I mean?).

[fromhell]

This video should show off how PowerVR handled alpha


And then there's the Voodoo2 handling

[Hitchhiker]

I think it should be possible to do (though am not sure to have understood well the difference)

Just few minutes ago I've managed to get the lightmaps sorted out (I plan on using them as ambient or diffuse component in glsl programs - more likely the diffuse one I think). With dynamic lightmaps for weapons lights excluded (so fewer polygons to render) and replaced with glsl lights (so some added processing but worth it I think).
The next step is tiding all up and getting those glsl programs updated (as now they can use the OpenGL normals so i.e. parallax bump mapping can be used on all surfaces). As soon I have everything ready I'll send you the modified files. Hopefully all is done within a week-two.

[fromhell]

What about the github?


p.s. Recently I got the 3dfx ordered dithering down with a table even.   I'm going to try to make that an internal GLSL shader similar to how renderergl2 does things.

[Hitchhiker]

I'll have to learn how github works but yes, will make things easier.

I think I'll pinch your dithering code and apply it to lightmaps (now that glsl can handle them.. still need to test this thoroughly) to get a little more quality out of them. Will let you know if an how it looks to decide if usable.

[fromhell]

This may be useful.  It doesn't use a loop or a table though, and you don't have to have the color quantization.


Also i'm working on my cel shader right now (horribly butchered from water/stream_*p.glsl) and yes normals would be a very nice thing to have.

[Hitchhiker]

@fromhell, I've cloned the engine from the Git repo. Is it OK to just commit changes? I'm worried I might mess things up if I do something wrong - if I do mess things up, can you restore the older version?

[fromhell]

Fortunately a lot of the changes I made aren't related to the GLSL backend so your improvements should be nicely mergeable.


A lot of my changes went into the image loader (paletted, 3dfx texture limiting, software ICD speedup), the backend (r_slowness, sun flare checking, and additional postprocess effects) the flare system, and some of the shader parser (for placeholders and determining detail textures to fade).

[Hitchhiker]

I'll try to merge my changes to the cloned image I have and commit this weekend. Then the glsl programs will change slightly and I'll try to upload these during the week.
Already normals should be accessible in glsl after the engine changes commit (they will be accessible using the glsl predefined variable gl_Normal) - I saw you tried implementing them already using uniform variables so I won't touch that part.
I'll post here to keep you updated on the progress I make.

[Hitchhiker]

Hi,
I did 'git commit' and got this at the console:
[master 244e874] - '//GLSL' keyword processing fix - 'dynamic lights' for glsl - 'sending normals to opengl' for glsl - 'loading of tonemap' for glsl postprocessing - 'multipart post process' for glsl - 'uploading lightmaps' for glsl
 6 files changed, 175 insertions(+), 13 deletions(-)
But the repo does not show the changes yet. I'm thinking the changes need to be approved/accepted or it simply takes some time?
Anyway, the magic of these changes will only show once I send the glsl programs that use them. I'll work over the week to do this and hopefully will be posting a good .pk3 file with the glsl programs by next weekend.
Cheers