Pages: 1 ... 4 5 [6] 7 8
  Print  
Author Topic: GLSL  (Read 141938 times)
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #125 on: March 07, 2014, 03:03:34 PM »

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
« Last Edit: March 07, 2014, 09:31:24 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #126 on: March 08, 2014, 07:22:37 PM »

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

Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4382


WWW
« Reply #127 on: March 10, 2014, 03:28:56 AM »

@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.
« Last Edit: March 10, 2014, 04:16:14 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #128 on: March 10, 2014, 08:48:40 AM »

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

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

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #129 on: March 10, 2014, 05:32:12 PM »

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.
Logged
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #130 on: March 11, 2014, 04:57:05 AM »

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 Sad ).
Logged
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #131 on: March 11, 2014, 05:08:06 AM »

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

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

yes, I agree.


Logged
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #132 on: March 11, 2014, 07:09:58 AM »

@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?)
Logged
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #133 on: March 11, 2014, 07:36:29 AM »

@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

Quote
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
  }
}
------------

Quote
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.
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #134 on: March 11, 2014, 09:18:23 AM »

@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 Sad
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4382


WWW
« Reply #135 on: March 11, 2014, 09:28:25 AM »

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...

Quote
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).

Quote
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.
« Last Edit: March 12, 2014, 03:19:45 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #136 on: March 11, 2014, 12:01:03 PM »

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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4382


WWW
« Reply #137 on: March 12, 2014, 03:21:14 AM »

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...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #138 on: March 12, 2014, 01:38:48 PM »

Hi, I know where it is. Have seen it, now fixed.
Thanks for your help with this Smiley
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #139 on: March 13, 2014, 08:54:43 PM »

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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #140 on: March 14, 2014, 02:37:17 PM »

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?).
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #141 on: March 16, 2014, 04:43:03 PM »

This video should show off how PowerVR handled alpha


And then there's the Voodoo2 handling
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #142 on: March 27, 2014, 01:42:19 PM »

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.

Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #143 on: March 27, 2014, 02:59:43 PM »

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.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #144 on: March 27, 2014, 03:58:25 PM »

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.
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #145 on: March 27, 2014, 04:00:52 PM »

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.
« Last Edit: March 28, 2014, 03:44:22 AM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #146 on: April 04, 2014, 10:47:56 AM »

@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?
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14519



WWW
« Reply #147 on: April 04, 2014, 04:53:05 PM »

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).
« Last Edit: April 04, 2014, 04:55:26 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #148 on: April 05, 2014, 05:55:18 AM »

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.
Logged
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #149 on: April 06, 2014, 05:54:19 AM »

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
Logged
Pages: 1 ... 4 5 [6] 7 8
  Print  
 
Jump to: