OpenArena Message Boards

OpenArena Contributions => Development => Topic started by: Hitchhiker on May 05, 2013, 02:47:11 pm



Title: GLSL
Post by: Hitchhiker on May 05, 2013, 02:47:11 pm
Hi y'all,

as per Gig's suggestion I've made a short glsl tutorial. Here attached. Just a draft for the moment but should get you started..

Please let me know your comments, things to add to the tutorial, corrections, etc...

Eventually, if you have a piece of glsl code to share why not post it here?

Cheers,
Hitchhiker


Title: Re: GLSL
Post by: Gig on May 06, 2013, 01:54:04 am
Interesting reading. Nice work!  :) What about moving that to a page on the wiki? E.g. (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Main_Page/wiki/GLSL
If you need any help for that, I'm available. If you wish, I could try the first "conversion" from OpenOffice to MediaWiki...

Quote
This is done using the '/r_postporcess' command.
"r_postprocess", of course.  :)

Quote
A new cvar has been added to enable/disable the GLSL rendering path (default: disabled)
I would specify "In OpenArena 0.8.8, a new cvar has been added...."

Quote
Getting a bit more techinical
"Technical", of course... :)

Quote
if vertex shaders are disabled/unsupported
"if" --> "If"  :)

Quote
Newer builds will skip-over the //GLSL' keyword and process the shader line as if the //GLSL keyword was not there.
Maybe you may add something like ", hence executing the command." at the end. A ' is missing (or one should be removed) next to the first //GLSL.

Quote
Note: If you intend to use your shaders only on new version of OA the '//GLSL' keyword is not needed.
I would add something like "However, it's advisable to always use it, to prevent problems in case someone would play the game with old binaries, and to easily distinguish "standard" shader commands from GLSL-related commands in shader sources."

Quote
vertex shader is concerned with modifying...
vertex --> Vertex.

Quote
Vertex program (a simple example – save sa zmix_vp.glsl
"Save sa"? I suppose "save as"...

Quote
In example we will modify the shader in detailtest.shader file of the pak6-patch088.pk3.
Modifying stock pk3 files in any way is usually a bad idea (would cause problems when connecting to servers, e.g. forcing to re-download the package). I suppose you may suggest to make a copy of detailtest.shader and place it (under the correct sub-folder), in a z_glslstest.pk3 file.
Also, if it is possible to do these tests without the need to package it into a pk3 file (would the modified shader work out-from-pk3 if using sv_pure 0? Or the original one in the pk3 would "win" anyway?), you may mention it.

Quote
You should see something like this: (SCREENSHOT)
What about placing also a normal screenshot of the same scene, but without GLSL active, to compare the differences?

OTHER THINGS:
- I imagine also the "skip" program "works" only when r_ext_vertex_shader is 1, right? I suppose this could be expressly said.

- You could place example screenshots of GLSL postprocess effects. If you want, one already exists:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/File:R_postprocess_edges.jpg (a screenshot with the "edges" GLSL program active)
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/File:Islanddm.jpg (a screenshot of the same map, but without GLSL)

- Is there a way to distinguish a GLSL program adapt to be used in a shader from one adapt to be used for postprocessing?

- When you will have some time, can you write down a list of the GLSL programs included in OA 0.8.8 package, explaining what they do?

- I suppose one should say that the artist MUST test the shader in-game with both GLSL support enabled and disabled: the shader has to display something "reasonable" for all users.

- Do all video cards supporting GLSL give the same results, or could some GSLS programs do not work, or give different results, with different hardware (e.g. using NVIDIA or AMD cards)?

- I cannot really help you with the most "technical" part, I'm noob with shaders!


Title: Re: GLSL
Post by: Hitchhiker on May 06, 2013, 11:36:36 am
Hi Gig,

thanks! lol. i'm dyslexci..
I agree about the glsl pak.. i actually need to remove the changes I did to the pak files in order to play online again :)
"skip" program -> I guess so.. shaders with 'program' keyword execute correctly with glsl disabled
screenshot -> no problem

- Is there a way to distinguish a GLSL program adapt to be used in a shader from one adapt to be used for postprocessing? -> I guess engine could be modified for this to work (i.e. define a variable in the glsl program and if that is detected only allow this program for postprocessing). Until this is done, a way of telling the difference are few uniform variables that should be part of the postprocessing program and have no place in shader glsl programs.

- When you will have some time, can you write down a list of the GLSL programs included in OA 0.8.8 package, explaining what they do? -> sure, I'll also try to comment them. but really anybody who thinks of writing glsl programs should learn glsl using Polydraw or similar, reading tutorials on glsl, etc

- I suppose one should say that the artist MUST test the shader in-game with both GLSL support enabled and disabled: the shader has to display something "reasonable" for all users. -> ok

- Do all video cards supporting GLSL give the same results, or could some GSLS programs do not work, or give different results, with different hardware (e.g. using NVIDIA or AMD cards)? -> I imagine they should.. there are few things that nvidia will accept but ati will not but this shows at compile time.. since nobody here is well versed in glsl the only way is for everybody to help test them.

I've never worked with wiki before.. when i catch some time I can upload the tutorial there.

Thanks for all your help! I'll correct the doc. I am interested to know, at which step, did the tutorial jump off in a strange direction for you? i.e. reading the tutorial if you've found yourself understanding what it is about and then finding the next paragraph talks about "something completely different"!

I'll add an example or two more of a complete glsl program in hope it will help someone.

for what is worth, some great examples (glsl programs drawn on a single flat square polygon) -> http://glsl.heroku.com/  -> maybe someone gets inspired and makes an alternative glsl background for the main menu? ;)
[edit] you would need a webgl browser to see these in action..




Title: Re: GLSL
Post by: Gig on May 07, 2013, 02:11:11 am
If you are completely new to the wiki, converting a long article could be a problem for you. I may create the page on the wiki when I will have some time, and you may start learning the wiki by making changes to it (meanwhile, you may take a look to wikipedia markup help pages... although wikia has something different than wikipedia, both of them use mediawiki software).
In the meanwhile, you may prepare another .odt version...

Well, I would not say that the tutorial jumped in a strange direction. My problem is just that I'm noob with shaders.

For the examples in that web page, unfortunately it looks like Firefox does not support WebGL yet, so I had to use Google Chrome instead. And the machine from which I'm writing now has got stupid integrated Intel graphics, with no (or very very limited) GLSL support: most of those programs report compiling errors and do not work. I'll try from a machine with a proper video card.
UPDATE: It's not Firefox, it's that machine.


Title: Re: GLSL
Post by: pelya on May 07, 2013, 05:33:00 am
It works on my Firefox, with Intel HD4000 graphics, however there are glitches in some examples.


Title: Re: GLSL
Post by: Gig on May 07, 2013, 06:41:04 am
It works on my Firefox, with Intel HD4000 graphics, however there are glitches in some examples.
You're right, from the PC with a real video card, the message does not appear, and effects work.
So, maybe with Firefox it detects that the GPU sucks and triggers the message "WebGL not supported, but code will be shown." (now that I think about it, it does not specify if the browser or the graphic card does not support it)... while with Chrome, it does not detect the problem, and finds errors only while actually trying to run those webgl programs.

By the way, what happens in OA when a GLSL program compiling fails? And if compiling works, but there is some other kind of error (that would cause a "normal" program to crash)?


Title: Re: GLSL
Post by: Hitchhiker on May 07, 2013, 11:45:50 am
I think in Firefox you need to 'visit' a virtual webpage of the Firefox to enable it. Could also depend on the version of the Firefox. Googling says this for enabling:
"- Type “about:config” in your browser’s URL bar - Do a search for “webgl” in the Filter field - Double-click the “enabled_for_all_sites” preference to change it to “true”

that should do it... "
some programs there will fail compiling. in some cases restarting the browser helps but not for all of them.

at the moment the glsl part is skipped as far I remember (if the compiling fails). also, if any error or warning is encountered the console will show it. probably a candidate for another section in the tutorial.
 


Title: Re: GLSL
Post by: Hitchhiker on May 07, 2013, 11:50:04 am
please post your wishlist of glsl programs in this thread.

[glsl programs wishlist so far]
    -running water - 'stream'
    -still water - 'water'
    -simple 2d plasma - 'plasma'
    -simple 3d plasma - '3dplasma'
    -sparks - 'sparks'



Title: Re: GLSL
Post by: Gig on May 08, 2013, 04:45:26 am
Hitch... Pelya created a page in the wiki with your tutorial.
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/GLSL
I've had a long work to fix its markup. However, other than moving the GLSL licensing infos to the bottom and adding a pre-intro at the beginning, I have done very VERY FEW changes to the text.
Most "issues" I told you previously about the tutorial still require fixing. (E.G. there is still to say that one MUST check the result playing in BOTH standard and GLSL modes... and to explain how to do the test without modifying stock pk3 files, which is bad -suggesting to create a z_glsltest.pk3 file instead?-, etc. Them all should be checked.).

Could you please take a look to it? I hope I correctly created the structure of the sections.
Then, if you are already working on a fixed .odt file, can I ask you to apply all the changes you did to the file also to the wiki? It would not be easy for me to "compare" them... it would be better if you could apply your changes also in the wiki.

Wiki markup is relatively easy, but however requires some practice. First of all, as I suggest in DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/WikiWorks]WikiWorks (http://([b) page, I suggest to DO NOT use Wikia's WYSIWYG editor -it can make damages-, but use its plain text editor instead.

Basic MediaWiki markup is
'' for italic ''
''' for bold '''
''''' for italic + bold '''''
<br /> for new line (a single carriage return does nothing; two carriage returns make a separate paragraph)
: at the beginning of a line makes the text begin more at right (more :: for more indentation) - just placing "spaces" at the beginning of a line would do nothing.
* makes a line of a list
** for a sub-list
<nowiki> text </nowiki> makes it ignore markup on the "text" part.
[http://www.openarena.ws Official site] creates an external link showing "official site"
[[Manual]] creates an internal link (Wikilink) to the "Manual" page - Please remember they are CASE SENSITIVE (except for the very first character only).
[[Manual/Graphic options]] creates an internal link to the Manual/Graphic options page
[[Manual/Graphic options#GLSL effects]] creates an internal link to the "GLSL effects" section of that page (if source and destination are IN THE SAME PAGE, one can also simply write [[#Section]], in the example [[#GLSL effects]])
[[Manual|Byebye]] creates an internal link showing "byebye" as text
==Section A title==
===Sub secton===
====Sub-sub section====
==Section N title==
To write text in "courier" style (I usually use it when I mention console commands), you can use <tt>text</tt> or <code>text</code>. I don't remember the difference now, however I usually use <tt> </tt>.
To paste sections of programs source code, the <code> tag would continue to use various mediawiki features (e.g. ignoring a single carriage return)... so I use <pre> text </pre> instead. I think that means "pre-formatted": that text will IGNORE most mediawiki conventions: you can use spaces at the beginning of the line -I suggest to use them instead of TABs-, a single carriage return will go to a new line, etc.). Unfortunately, I don't know how to use "bold" or other effects inside that, so where you had used bold in some source codes in your tutorial, I "said" to pay attention to those lines instead.
For more infos about mediawiki markup, you can take a look to Wikipedia markup help (http://en.wikipedia.org/wiki/Help:Wiki_markup), it's similar to Wikia.

Will help you with images (uploading -only for registered wikia users-, licensing infos, markup) when you will need.

We have a forum thread about the wiki: http://openarena.ws/board/index.php?topic=4046.0
And each wiki page has got its "talk" page.


Title: Re: GLSL
Post by: Hitchhiker on May 08, 2013, 11:26:56 am
Thanks Gig and Pelya!
I'll try to look into this over the weekend.


Title: Re: GLSL
Post by: Gig on May 16, 2013, 12:20:55 am
Trying to move here GLSL discussion from the OACMP thread...

as for tech demo, I edited the bsp file with hex editor and changed all texture/something/... :) to glshader/something/.. so basically it can be an independent map.. I'm not sure about creating a map by myself..
I think that tweaking an existing bsp file is not a good thing for a tutorial. I think you really should include the .map file to allow people take a look inside it, change something and recompile.
A fully glsl-powered version of my map could be interesting for me... but I think other people would need a simpler test map for the GLSL tutorial.



Title: Re: GLSL
Post by: GrosBedo on May 17, 2013, 05:06:38 am
I'm not a graphics developer, but that's a great initiative! Great work too, I've read your tutorial and it's very clear for me, and the concrete example at the end is simple and concise.

I agree with Gig (who often has very good ideas and feedbacks ;) ), you should provide an example .map for people to have a good basis to start from. It's always better to learn by experimenting on a practical case than from theory alone.


Title: Re: GLSL
Post by: Gig on May 17, 2013, 06:40:14 am
NOTE: I originally posted what follows in another thread (http://openarena.ws/board/index.php?topic=4679.msg47176#msg47176). Now I move this here because I think this thread is more appropriate. I think this is an important thing...


@ALL - A GENERAL THING ABOUT GLSL SHADERS. Let's decide this now that we actually start creating and using GLSL shaders. Fromhell's opinion would be welcome.

Guys, do you think we should "identify" shaders including GLSL in their name (e.g. adding _glsl -or simply _g- suffix to all of those shaders) -or placing all of them in a specific folder-, as a way to help mappers?
1) To help them finding shaders that include GLSL effects, if they wanna make their maps more cool
2) To help them reminding that they should test their maps with both GLSL support enabled and disabled, to be sure of the result in both cases?
OR should we assume that in future having shaders with GLSL support will became quite normal, or that GLSL code will be added also to "old" (already existing) shaders -that should not be renamed or moved for compatibility reasons-, hence specifying _glsl suffix (or placing them in a separate folder) for new shaders names only would become useless?


-----------------------------------------------
PS:
@Hitch
In the previous post I forgot to mention that, although the first alpha of my "udestruction" map was called "test2", I don't wish that map to be identified as a test map. It's true that I'm learning things during its creation, and that's not really a "pro" or "cool" map... but anyway I don't like people to think about it as a mere tech test or tutorial map. Hence, I'd prefer if you could create a specific map also for this reason (other than those I already told before)


Title: Re: GLSL
Post by: fromhell on May 17, 2013, 11:21:17 am
Are we still doing the comments workaround for shader parser compatibility?


Title: Re: GLSL
Post by: matija123 on May 17, 2013, 03:29:40 pm
I Have no idea what ur talking about *Getting sleepd of DeFRag* what is GLSL dude can i make some maps OR textures. ..  >:(  ;D  ;)  :D


Title: Re: GLSL
Post by: fromhell on May 17, 2013, 03:58:59 pm
GLSL is a way to manipulate teh pixels on the screen for new effects

before GLSL, you were quite limited and had to play with combines and strange arb assembly


Title: Re: GLSL
Post by: Hitchhiker on May 17, 2013, 04:31:59 pm
hi

@matija :) yup, I'm playing with an idea of creating one, a sort of 'universal' glsl program - shader that might shade easily an entire map - could be a good thing for defrag - to be seen and tested

@fromhell, yes - the comments are still present. as far I can see this system works well.

@Gig, your map is actually useful for me to test different things while preparing different glsl programs. not a problem to create a final glsl test map but I'll probably need to do it in Blender and will have to learn a thing or two about how Blender and q3map2 interact (mainly if texture coordinates are exported, will Radiant remove those once I import the map into it in order to add spawn points, etc..) - to be seen. But before posting anything I'll try to make a map myself and use these glsl programs in it.
as for shaders and their naming I guess keeping the original name should be ok but the glsl program will have to be done in a way so that it behaves and does only a simple thing - I've made few example 'banding' programs that are geometry/position dependent and I imaging when a mapper decides to use these, they are the only ones that will probably be best left in a completely new shader (this new shader could then include both non-glsl shading commands as well as glsl ones).
I believe OA now has a patch to load shaders depending on the renderer which is used? Not useful in this situation but maybe something to consider when discussing the naming? I dont know at the moment - need to think it over.

@GrosBedo, thank you! I was starting to think I would not finish the tutorial - not knowing if I'm making any sense there at all.. once I finish all the programs I'm making I believe I'll be able to re-do the tutorial so it will be even simpler to understand.

I'll try to post a simple glsl map this weekend.


Title: Re: GLSL
Post by: Gig on May 18, 2013, 03:49:20 am
Just a small post.
I know that "fake comments" workarounds are not elegant... but I think that having the glsl part clearly separed from the rest of the shader is a good thing, so I suggest to continue using the //GLSL thing.

A note for Sago and Fromhell: I suppose we should add the GLSL option in the GUI in the next OA version. It could still be disabled by default for compatibility reasons if you wish... but people should be able to know it exists and to enable and disable it comfortably. Who could imagine what the long-named variable does, unless occasionally reading about it on the wiki or on the forum?


Title: Re: GLSL
Post by: Hitchhiker on May 19, 2013, 02:07:34 pm
I agree with a menu option and using the //GLSL comment. Also, trying to see different blendfunc options for water effect I find that it might be a good idea to have a separate shader stock that could be looked up first to find a specific shader (only if glsl is enabled). I dont know if this can be done with the existing patch for different renderers?
Today trying to get the stream glsl program in 'final' version I've found that the //GLSL keyword is processed even if glsl is disabled so this might be a good thing to correct in the next release (i.e. to skip the comment/keyword characters only if glsl is enabled).

An advantage of using separate shader files for glsl would also be less passes (less polygon drawn if I understand the passes correctly).

Here is the 'stream' glsl program for you to try. Please read the .shader file for more instructions on how to use it.



Title: Re: GLSL
Post by: Hitchhiker on May 19, 2013, 02:12:17 pm
Not much sparks as I was hoping it'd be but still a nice effect. Different variants inside.


Title: Re: GLSL
Post by: CGB01 on May 19, 2013, 02:42:56 pm
Hitchhiker, can you upload the following images.  They are used in your shaders but are not in the zip file.

gig_stripes1.tga
pebbles1.jpg
3605-normal.jpg

Looking forward to trying the shaders :)

Thanks.


Title: Re: GLSL
Post by: Gig on May 20, 2013, 12:29:26 am
Hitchhiker, can you upload the following images.  They are used in your shaders but are not in the zip file.

gig_stripes1.tga
pebbles1.jpg
3605-normal.jpg

Looking forward to trying the shaders :)

Thanks.

Gig_stripes1.tga and pebbles1.jpg are two files from my udestruction v7 pk3:
http://openarena.ws/board/index.php?topic=4679.msg46959#msg46959

About 3605-normal.jpg... I have no idea.
In a note in the shader file, Hitch tells "find a normal map file (the one I have is not GPL)"... but I have no idea of what kind of image should I find.



Title: Re: GLSL
Post by: Gig on May 20, 2013, 01:41:04 am
Hitch, we have a problem here.

I tried to test the sparks shader.
1) I placed glsl_sparks.shader in my "scripts" folder.
2) I edited it, replacing references to "glshader" folder with "textures" folder (so, shader would appear as/be applied to "textures/gig/gig_stripes1", and would load my "textures/gig/gig_stripes1.tga").
3) I removed (by changing its extension) my existing .shader file that holds the original version of the stripes shader. This way, I'm sure the GLSL version is loaded instead of my original one.
4) I placed sparks_fp.glsl and sparks_vp.glsl (the version in the main folder of your zip) into a "glsl/sparks" folder.
5) I started OA and loaded my map (sv_pure 0, devmap udestruction)
6) I set r_ext_vertex shader 1, then vid_restart
7) I see the sparks as usual. Something went wrong!
8) I pull down the console. It says that:
Quote
Error:
Vertex shader failed to compile with the following errors:
ERROR: 0:6: error(#160) Cannot convert from 'attribute4-component vector of
float' to 'default varying 3-component vector of float'
ERROR: error(#273) 1 compilation errors. No code generated

Couldn't compile vertex shader for program sparksWARNING:
RE_GLSL_registerProgram failed for 'program sparks' in shader
'textures/gig/gig_stripes1'

Did I do something wrong?

PS: same happens also if I try with the other three versions of the "sparks" glsl program.


Title: Re: GLSL
Post by: Hitchhiker on May 20, 2013, 09:07:44 am
I'll check the error part and try to find why it fails.
As it fails to compile, OA disables the glsl so things show as usual.
as for normal map just google images for 'normalmap water' and take one with size in power of 2 (128x128, 256x256, 512x512..).
I've just made one so I can say it is GPL and here attached. :)


Title: Re: GLSL
Post by: Hitchhiker on May 20, 2013, 09:18:31 am
Hitch, we have a problem here.

I tried to test the sparks shader.
1) I placed glsl_sparks.shader in my "scripts" folder.
2) I edited it, replacing references to "glshader" folder with "textures" folder (so, shader would appear as/be applied to "textures/gig/gig_stripes1", and would load my "textures/gig/gig_stripes1.tga").
3) I removed (by changing its extension) my existing .shader file that holds the original version of the stripes shader. This way, I'm sure the GLSL version is loaded instead of my original one.
4) I placed sparks_fp.glsl and sparks_vp.glsl (the version in the main folder of your zip) into a "glsl/sparks" folder.
5) I started OA and loaded my map (sv_pure 0, devmap udestruction)
6) I set r_ext_vertex shader 1, then vid_restart
7) I see the sparks as usual. Something went wrong!
8) I pull down the console. It says that:
Quote
Error:
Vertex shader failed to compile with the following errors:
ERROR: 0:6: error(#160) Cannot convert from 'attribute4-component vector of
float' to 'default varying 3-component vector of float'
ERROR: error(#273) 1 compilation errors. No code generated

Couldn't compile vertex shader for program sparksWARNING:
RE_GLSL_registerProgram failed for 'program sparks' in shader
'textures/gig/gig_stripes1'

Did I do something wrong?

PS: same happens also if I try with the other three versions of the "sparks" glsl program.

Hi Gig,

I think you did all right!

Can you please try changing the line in spark_vp.glsl from:
vertex=gl_Vertex;
to:
vertex=gl_Vertex.xyz;

That should fix it.



Title: Re: GLSL
Post by: Gig on May 20, 2013, 09:59:10 am
Okay, this seems to avoid the error. Now I can see something actually different.
But the result isn't exactly "cool"...
Take a look to the screenshot.
I think this is the version that was in the folder "3" of your zip, but I'm not sure. Is it supposed to look like that?

I must go now, I will try again the various versions of the sparks, and I will try the water shader (although some more usage infos would be welcome for that...) tomorrow.


Title: Re: GLSL
Post by: Hitchhiker on May 20, 2013, 10:46:50 am
thanks for trying Gig, actually that is the effect I made  :)
for some reason I could not get the entire box but only vertical stripes so the space to do more was limited.
all the other versions are more or less the same thing so no need to try them.
I'll see if I can get something else drawn there.


Title: Re: GLSL
Post by: Gig on May 20, 2013, 11:51:42 pm
For "the entire box", do you mean the six sides of the brush?
For my "sparks" brushes I used my gig_stripes1 shader on one face, and "nodraw" on the other five (if you check with r_showtris 1, you can see the other faces are not rendered at all): the "box" effect looked bad with my shader, so I made it "2D".

For the GLSL effect of the sparks I thought about something like adding some sort of "bump mapping with light from changing angle" to my texture.
Of course my texture is quite small since the beginning, hence the "space" available to draw cool effects there is very little... if it is a problem, you can focus your attention on other shaders instead.


Title: Re: GLSL
Post by: Gig on May 21, 2013, 12:51:11 am
Well, I'm trying to test the water effect, but I have some problems.
- I placed your waternormal.jpg in my "textures/gig" folder.
- I placed stream_fp.glsl and stream_vp.glsl in a "glsl/water" folder.
- I placed "stream.shader" in my "scripts" folder.
- I edited it, adjusting two paths, and removing all your comments starting with "-" (I thought comments begin with "//" ... I see you used "-" instead, is that ok?) and removing the second (short) version of the shader, trying to avoid conflitcs (more infos about the two versions in your shader file would be welcome). Now the shader file looks like this.
Quote
textures/liquids/clear_ripple2
{
   qer_editorimage textures/liquids/pool3d_3.jpg
   surfaceparm trans
   surfaceparm nonsolid
   surfaceparm water
   cull disable
   deformVertexes wave 64 sin .25 .25 0 .5   

   {
      map textures/liquids/pool3d_5.jpg
      blendFunc gl_dst_color gl_one
      rgbgen identity
      tcmod scroll -.025 .001
      //GLSL blendFunc gl_dst_color gl_src_color
      //GLSL map2 textures/gig/pebbles1.jpg
      //GLSL map3 textures/gig/waternormal.jpg
      //GLSL program stream
      //GLSL vertexProgram glsl\water\stream_vp.glsl
      //GLSL fragmentProgram glsl\water\stream_fp.glsl   
   }

   {
      map textures/liquids/pool3d_6.jpg
      blendFunc gl_dst_color gl_one
      rgbgen identity
      tcmod scroll .03 -.001
   }
   {
      map textures/liquids/pool3d_5e.jpg
      blendFunc gl_dst_color gl_one
      rgbgen identity
      tcmod scroll .001 .025
   }
   {
      map $lightmap
      blendFunc gl_dst_color gl_zero
      rgbgen identity      
   }
   

}
I loaded my map, and the water looks like as usual. I've done a vid_restart and checked the console. I can see this error:
Quote
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:63: error(#202) No matching overloaded function found dot
ERROR: 0:64: error(#202) No matching overloaded function found reflect
ERROR: 0:64: error(#202) No matching overloaded function found dot
ERROR: error(#273) 3 compilation errors.  No code generated

Couldn't compile fragment shader for program streamWARNING:
RE_GLSL_RegisterProgram failed for 'program stream' in shader
'textures/liquids/clear_ripple2'
What's the matter?

I also tried keeping the "short" version instead:
Quote
textures/liquids/clear_ripple2
{
   qer_editorimage textures/liquids/pool3d_3.jpg
   surfaceparm trans
   surfaceparm nonsolid
   surfaceparm water
   cull disable
   deformVertexes wave 64 sin .25 .25 0 .5   

   {
      map textures/liquids/pool3d_5.jpg
      blendFunc blend
      rgbgen identity
      tcmod scroll -.025 .001
      //GLSL map2 textures/gig/pebbles1.jpg
      //GLSL map3 textures/gig/waternormal.jpg
      //GLSL program stream
      //GLSL vertexProgram glsl\water\stream_vp.glsl
      //GLSL fragmentProgram glsl\water\stream_fp.glsl   
   }
   {
      map $lightmap
      blendFunc gl_dst_color gl_zero
      rgbgen identity      
   }
}
Glsl program compiling still fails with the same errors as above (predictable, calling the same exact glsl program)... but this time the "classic" shader looks very bad, showing a non-transparent greyscale texture.


Title: Re: GLSL
Post by: Hitchhiker on May 21, 2013, 11:30:57 am
Hi Gig and again THANKS for testing!
I see I will have to be more careful about mixing vec3 and vec4 variables as ATI cards seem to be more strict than nvidia..

Could you try replacing the lines 63 and 64 with this:
//calculate diffuse and specular values   
   float diffuse= clamp( dot (bump.xyz,normalize(lpos)) ,0 , 0.8 );
   float specular = pow(clamp(dot(normalize (reflect(normalize(-vpos), bump.xyz) ), normalize(lpos)), 0.0, 1.0), 64.0 );

I think this should do it.

The gray texture shows as I don't know how to switch off the blendfunc once it was set in a shader. So you could remove the  //GLSL blendFunc gl_dst_color gl_src_color from the shader but then the water and refraction effect is kind of lost.

Possibly (as I have few additions to the renderer) I could create a separate renderer dll and then the patch that loads shaders particular to the renderer could resolve these foldername, blendfunc, shader-name and other issues. To be considered.. and maybe Sago007 or fromhell can share their thoughts on this. But I think for this to work for everybody a new release of OA would be needed as the patch for different renderers was added after 0.8.8?

As for sparks, I've remembered a line from tutorial.. the one that says that glsl can modify vertex positions. so I did that and scaled the box a little - the new shader is a bit nicer. I'll post it tonight.


Title: Re: GLSL
Post by: Hitchhiker on May 21, 2013, 02:50:37 pm
hi again,
the project fail.. not so fancy sparks effect here attached. I know it sounds fake but I had a much better effect towards the end but being so well organized I managed to overwrite the latest version with the one from the beginning of the evening.. :(
hopefully will manage to recreate it.. :( not even worth posting this one


Title: Re: GLSL
Post by: fromhell on May 21, 2013, 05:40:09 pm
Gig, what's your video chipset again? Are you certain it properly supports GLSL?


Title: Re: GLSL
Post by: Gig on May 22, 2013, 12:52:41 am
Gig, what's your video chipset again? Are you certain it properly supports GLSL?
ATI Radeon HD 5670.
GLSL works, it correctly shows things such as "r_postprocess edges" program.

UPDATE: With that fix (http://openarena.ws/board/index.php?topic=4767.msg47231#msg47231) in stream_vp.glsl, the water works. AND IT'S AWESOME.
It's so nice I had to immediately post a video of it.
I will comment more in a later post.
Video is .avi in xvid format. I had to place it into a .zip because the forum does not allow .avi extension. Sorry for the poor quality, but the forums allow to upload very little files only.


Title: Re: GLSL
Post by: Gig on May 22, 2013, 02:57:54 am
Hitch, first of all, congratulations for that water: it's really cool!!!! :) Thank you for that, you just got a cake! Q3 water should have looked like that since the beginning!

Then... I've done more tests, and I noticed some problems.

Using the "short" version of the .shader (see this post (http://openarena.ws/board/index.php?topic=4767.msg47229#msg47229)), my "pebbles1" texture is the only one players see "under the surface". The shader surface is not transparent: as you can see in the first screenshot, the part of the proximity mine that is under it is not visible at all. "Marks on walls" are not shown.

Using the "long" version of the .shader, my "pebbles1" texture is semi-transparent, and I can see the aqueduct texture below: I like that effect very much (although I suppose transparent pebbles do not exist in real world, and the aqueduct texture does not have refraction -as you can see, blocks lines are not distorted-... but the glance is cool anyway)! :) As told, the shader is transparent: as you can see in the second screenshot, I can see the part of the proximity mine that is under the water surface, good. Small problem: "marks on walls" appear "doubled", especially if you are not vertically above them (like if a mark is left on the bottom of the pool, and a second mark is left on the water surface?).

Major problem: with both shaders, if I disable r_ext_vertex_shader, then the water looks in ugly black and white (see third screenshot). I really hope there is some way to workaround this problem without the need of a new OA engine version, otherwise that effect could not be in OACMP1, and that would be a shame.
PS: also the non-glsl version of the shader should show "flowing" water (e.g. like in that shader from Akom (http://openarena.ws/board/index.php?action=dlattach;topic=4759.0;attach=4348)).

I have not tested yet what happens if applying this water to a proper "pool" deep enough to swim. I imagine pebbles could suddently disappear when you go underwater, but I have to test yet... however for this particular map I don't need to go underwater.


Title: Re: GLSL
Post by: Gig on May 22, 2013, 03:34:00 am
About that second "sparks" package:

Sorry, the glsl program does not compile:
Quote
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:38: error(#202) No matching overloaded function found pow
ERROR: 0:38: error(#160) Cannot convert from 'const float' to 'highp
3-component vector of float'
ERROR: error(#273) 2 compilation errors.  No code generated

Couldn't compile fragment shader for program sparksWARNING:
RE_GLSL_RegisterProgram failed for 'program sparks' in shader
'textures/gig/gig_stripes1'

For completion, I post here also the .shader file (that is the same of the previous sparks .zip... maybe there is something that should be updated to fit the new version of the glsl program?):
Quote
textures/gig/gig_stripes1
{
        surfaceparm trans   
        surfaceparm nomarks   
        surfaceparm nonsolid
      surfaceparm nolightmap
        cull none
               
   {
      map textures/gig/gig_stripes1.tga
      //GLSL program sparks
      //GLSL vertexProgram glsl\sparks\sparks_vp.glsl
      //GLSL fragmentProgram glsl\sparks\sparks_fp.glsl
        tcMod Scroll .5 .6
        blendFunc GL_ONE GL_ONE
        }
           
}


Title: Re: GLSL
Post by: CGB01 on May 22, 2013, 06:08:04 am
Very cool water effect Hitchhiker and nice video Gig.  Wanted to see if I could do the same and sadly, it's not working for me.

From the console, I'm getting the following message;

glsl programs: enabled  (Ok, so I did the /r_ext_vertex_shader 1)
Warning:  Cannot locate postprocessing glsl program stream (I did the /r_postprocess stream)

The stream_vp.glsl and stream_fp.glsl are in the glsl/water/ directory and I've copied Gig's shader code.

What am I doing wrong?  :(


Title: Re: GLSL
Post by: Gig on May 22, 2013, 06:58:37 am
glsl programs: enabled  (Ok, so I did the /r_ext_vertex_shader 1)
Warning:  Cannot locate postprocessing glsl program stream (I did the /r_postprocess stream)
What am I doing wrong?  :(

GLSL programs can be user-side (to be used with /r_postprocess <programname> from console), or mapper-side (invoked from a shader used on a certain brush in a map). In the first case (postprocess mode), they affect the whole screen; in the second case, they affect only that shader/texture. They are two completely different things... Hitch said there is no easy method to guess if a certain glsl program is to be used for postprocess mode or to be invoked by a shader: I suppose the glsl author should mention this in some comment line inside the shader itself (another thing that should be said in the tutorial!).

However, we are talking about glsl programs invoked by shaders ("stream" glsl program requires some texture names as "input variables", and this info comes from the shader).
I had to put together a few files from different posts, place them in the correct folders, apply some fixes Hitch mentioned in other posts, and fix some paths mentioned in the shader (very simple work compared with what Hitch did, but it's not so automatic for a shader beginner like me).

For your convenience, I've just packed them up into pk3, so you can use them more easily. It's only the "flowing water" shader, not the "sparks" one (that does not yet work for me).

So:
1) get udestruction v7 (BETA map from mine) .pk3 from here (http://openarena.ws/board/index.php?topic=4679.msg46959#msg46959), and save it under your baseoa folder (it contains textures/gig/pebbles1.jpg, and the map uses textures/liquids/clear_ripple2 on the aqueduct).
2) download the two .pk3 files you find attached to this post, and place GLSL_TEST_SHORT.PK3 in your baseoa folder (this gives you the shader -a glsl powered version of clear_ripple2 that of course will require a different name in the "final" map, because the original clear_ripple2 is not supposed to be "flowing"-, the glsl program, and Hitch's waternormal.jpg file).
3) Launch openarena, be sure you have r_ext_vertex_shader 1, then do /DEVMAP UDESTRUCTION, and go on the aqueduct. You should see the cool water flowing, with the water surface non-transparent.

Then close the game, remove GLSL_TEST_SHORT.PK3 from baseoa and place GLSL_TEST_LONG.PK3 there. Launch the game and load udestruction again. This time, the water surface will be semi-transparent.

If you wanna do experiments on your own, you could extract the content of the .pk3 file (at that point, you can even delete the .pk3), and modify the .shader (e.g. to load a different texture in the place of gig/textures/pebbles1.jpg).
Please remember that, if you need to use stuff that is not packaged into a pk3 (e.g. your personal edited version of the shader), you need to set /sv_pure 0 before loading the map.


Title: Re: GLSL
Post by: CGB01 on May 22, 2013, 08:47:14 am
Quote
1) get udestruction v7 (BETA map from mine) .pk3 from here, and save it under your baseoa folder (it contains textures/gig/pebbles1.jpg, and the map uses textures/liquids/clear_ripple2 on the aqueduct).
2) download the two .pk3 files you find attached to this post, and place GLSL_TEST_SHORT.PK3 in your baseoa folder (this gives you the shader -a glsl powered version of clear_ripple2 that of course will require a different name in the "final" map, because the original clear_ripple2 is not supposed to be "flowing"-, the glsl program, and Hitch's waternormal.jpg file).
3) Launch openarena, be sure you have r_ext_vertex_shader 1, then do /DEVMAP UDESTRUCTION, and go on the aqueduct. You should see the cool water flowing, with the water surface non-transparent.

This is the console log after downloading the files ...

ERROR: 0:28: '[' :  array must be redeclared with a size before being indexed with a variable
WARNING: 0:52: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:56: 'texture' : function not available in current GLSL version
WARNING: 0:58: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:58: 'texture' : function not available in current GLSL version
WARNING: 0:63: 'clamp' : implicit conversion is allowed from GLSL 1.20
WARNING: 0:63: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:67: 'texture' : function not available in current GLSL version
WARNING: 0:67: 'texture' : function not available in current GLSL version
WARNING: 0:67: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:69: 'assing' : implict conversion between types allowed from GLSL 1.20


Couldn't compile fragment shader for program stream
WARNING: RE_GLSL_RegisterProgram failed for 'program stream' in shader 'textures/liquids/clear_ripple2'


Guess there's still something wrong somewhere.  :(


Title: Re: GLSL
Post by: Gig on May 22, 2013, 10:24:59 am
Did you try also the "long" shader? I can see it noone downloaded it yet.

Which video card are you using? Maybe its glsl support is not good, or for that some other tweak is needed... or I did something wrong in the pk3 (I tried it on a separate oa install, but on the same machine).

Do things like "r_postprocess edge" work with you?


Title: Re: GLSL
Post by: CGB01 on May 22, 2013, 12:22:02 pm
Sorry Gig, had to run out this morning.  Yes, I just tried downloading the file and the same error occurs.

"\r_postprocess edge" and a "\vid_restart" gives me an error as well 'Cannot locate postprocessing glsl program edge'.

Hmm, wonder if it's because I'm trying to run this on my laptop.  It has a built in graphics card (Intel based), although I'm not getting any errors during the R_init phase of the game start.



Title: Re: GLSL
Post by: Gig on May 22, 2013, 02:07:47 pm
AFAIK, Intel integrated graphic cards are not good for gaming. I would suggest you to try on another pc.

By the way, I suppose that adding glsl option to the menu would be good, but that should continue being disabled by default.. cards compatibility is uncertain...


Title: Re: GLSL
Post by: fromhell on May 22, 2013, 02:18:10 pm
Generally anything made after 2002 with shader model 2.0 (Radeon 9500/GeforceFX 5200 and above) supports GLSL IIRC




Title: Re: GLSL
Post by: Gig on May 23, 2013, 12:51:42 am
Sorry, yesterday I wrote that post from the cell phone and I didn't notice I left a character out. That was supposed to be 'r_postprocess edges', with the final "s". My fault.

Anyway, I have a PC (dated around 2008-2009) with integrated Intel graphics, where GLSL doesn't work.

@Hitch. Another thing for when you will update the GLSL tutorial: I suppose it would be good to link a GLSL language specification document (http://en.wikipedia.org/wiki/GLSL#References), but which one?
I read that GLSL language evolved with various OpenGL versions (http://en.wikipedia.org/wiki/GLSL#Versions), and each version has got its own document (examples, version 1.1 and version 4.3: http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.10.59.pdf http://www.opengl.org/registry/doc/GLSLangSpec.4.30.8.pdf). Which one should we tell users to follow? The one that OA GLSL implementation follows more stictly? The very first one, in hope to assure compatibility with older video cards? Or what?


Title: Re: GLSL
Post by: CGB01 on May 23, 2013, 04:14:22 am
Sorry, yesterday I wrote that post from the cell phone and I didn't notice I left a character out. That was supposed to be 'r_postprocess edges', with the final "s". My fault.

No problem :)  Yes, I tried this morning with the "edges" and it does work.  So the question still remain, why are your pk3 files not working?


Title: Re: GLSL
Post by: Gig on May 23, 2013, 04:47:33 am
I don't know. Maybe your graphic chipset requires even more strict "formal language" following than AMD cards (Hitch already had to write down small fixes to have the same effects that worked on his NVIDIA card to also work on my AMD card).
Or, looking at the error messages you posted (http://openarena.ws/board/index.php?topic=4767.msg47241#msg47241), the "stream" glsl program may use some GLSL features that are not supported by your video card (or by its drivers). From the very little I can guess from those messages, it looks like that GLSL program uses GLSL 1.2 version features, and maybe your graphic card (or its driver!) supports GLSL 1.1 features only. Maybe the "edges" program, instead, just requires 1.1 features. Just guessing. I suppose Hitch could be able to give a better analysys of the problem.

However, Intel drivers GLSL support sounds like a problem also for other people:
http://www.ozone3d.net/blogs/lab/20080611/glsl-support-in-intel-graphics-drivers/
I have not yet found a page listing all the various GLSL versions supported by the various Intel chipsets.
However, I found a page about OpenGL support for Intel 4 Series chipsets (and it mentions Vista and XP driver versions only...):
http://software.intel.com/en-us/articles/opengl-extensions-supported-in-intel-4-series-express-chipsets-and-beyond
It says that GLSL 1.2 is supported since 14.39 drivers for Vista and since 15.14 drivers for XP.

I would suggest you to try updating your Intel video drivers, if possible. Otherwise, try on another machine.


Title: Re: GLSL
Post by: CGB01 on May 23, 2013, 06:51:37 am
There's a program on ozone3d.net to test your GPU's capabilities called "Geek3D GPU Cap Viewer".  I've downloaded it and it reports that I have OpenGL version 3.1 (with 116 extensions) and that I support GLSL version 1.40.  My driver version is 15.10 and HP does not have a newer version for my laptop :(

Guess I'm SOL for getting Hitch's stream version going  >:(

Once I get settled into the new place (I'm currently moving) I'll get the desktop system setup and try again.

Thanks for your help Gig!

Cheers.


Title: Re: GLSL
Post by: Hitchhiker on May 25, 2013, 10:12:28 am
the message about glsl version 1.20 is just a warning. I've modified the 'stream' program so it might work on Intel as well. version 1.1 here attached.


Title: Re: GLSL
Post by: Hitchhiker on May 25, 2013, 10:15:15 am
worked also on pool kind of water (basically a modified version of the water in ZEQ thread).
program and screenshot here attached. I did try to verify all the variables are of the correct type and hope it will work out of the box on ATI and Intel.


Title: Re: GLSL
Post by: CGB01 on May 25, 2013, 12:17:12 pm
the message about glsl version 1.20 is just a warning. I've modified the 'stream' program so it might work on Intel as well. version 1.1 here attached.

Hey Hitch, thanks for trying.  It didn't work either, I get the same compile errors.


Title: Re: GLSL
Post by: Hitchhiker on May 26, 2013, 03:32:24 am
Hi CGB01 and thank you for trying as well :)
If you want to give it another go, I've cleaned the programs of multitexturing stuff and the updated version is here attached. If you try and it gives an error again, could you post the error message again please?
Thanks!


Title: Re: GLSL
Post by: CGB01 on May 26, 2013, 05:04:55 am
Tried your new version and still getting the errors.  This is proving to be a hard one to fix :(  Sorry about that Hitch.  Here's the errors I'm getting;

glsl programs: enabled
Initializing Programs
Error:
ERROR: 0:28: '[' :  array must be redeclared with a size before being indexed with a variable
WARNING: 0:52: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:56: 'texture' : function not available in current GLSL version
WARNING: 0:58: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:58: 'texture' : function not available in current GLSL version
WARNING: 0:63: 'clamp' : implicit conversion is allowed from GLSL 1.20
WARNING: 0:63: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:67: 'texture' : function not available in current GLSL version
WARNING: 0:67: 'texture' : function not available in current GLSL version
WARNING: 0:67: 'assign' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:69: 'assing' : implict conversion between types allowed from GLSL 1.20


Couldn't compile fragment shader for program postprocess





Title: Re: GLSL
Post by: Hitchhiker on May 26, 2013, 05:35:20 am
Thanks for testing CGB01, it seems the problem is the postprocessing programs? which one do you use?


Title: Re: GLSL
Post by: CGB01 on May 26, 2013, 05:37:12 am
I did \r_postprocess water\stream and placed your source code files in \glsl\water directory.  Is this not correct?


Title: Re: GLSL
Post by: Gig on May 26, 2013, 12:08:07 pm
Hitch, it would be better if you could attach pk3 to use out-of-the-box.

One needs to modify the .shader files you posted, in order to make it work.

I'm extremely in hurry, but I can tell you that I tested the "old" version of the stream shader (the one from my previous screenshots in this page) with an older ATI Radeon card (X1600, dated around 2005-2006 I think), and GLSL encountered errors.

Then I tried your version 1.1b.
To do that, I extracted all the content of my glsl_test_long.pk3 (to have the correct subfolders and gig/waternormal.jpg), and then deleted the pk3.
Then I took the files inside your glsl_stream_v1_1b.zip and placed them into the appropriate folders (/glsl/water and /scripts) overwriting the previous files.
Then I had to modify the shader file, to point to the right files folders (/textures/gig) and to keep only one of the two shaders there.

Quote
textures/liquids/clear_ripple2
{
   qer_editorimage textures/liquids/pool3d_3.jpg
   surfaceparm trans
   surfaceparm nonsolid
   surfaceparm water
   cull disable
   deformVertexes wave 64 sin .25 .25 0 .5   

   {
      map textures/liquids/pool3d_5.jpg
      blendFunc gl_dst_color gl_one
      rgbgen identity
      tcmod scroll -.025 .001
      //GLSL map2 textures/gig/pebbles1.jpg
      //GLSL map3 textures/gig/waternormal.jpg
      //GLSL program stream
      //GLSL vertexProgram glsl\water\stream_vp.glsl
      //GLSL fragmentProgram glsl\water\stream_fp.glsl   
   }

   {
      map textures/liquids/pool3d_6.jpg
      blendFunc gl_dst_color gl_one
      rgbgen identity
      tcmod scroll .03 -.001
   }
   {
      map textures/liquids/pool3d_5e.jpg
      blendFunc gl_dst_color gl_one
      rgbgen identity
      tcmod scroll .001 .025
   }
   {
      map $lightmap
      blendFunc gl_dst_color gl_zero
      rgbgen identity      
   }
   

}

The result (tested with sv_pure 0) does not give errors, and the "standard" shader version is not black and white. However, the GLSL effect is way TOO transparent, it's almost unnoticeable!

See you tomorrow, I have to RUN now! Bye!


Title: Re: GLSL
Post by: Hitchhiker on May 26, 2013, 03:06:03 pm
the stream glsl program goes into the map shaders like the one Gig shows. There are only a few glsl postprocessing programs in OA at the moment -> Brightness, BWfilter, edges and EGAfilter

the postprocessing programs can be loaded from within the game using the /r_postprocess command

if a glsl program is used in map then they need to be specified in script files and within a specific shader that is used in a map.

I'll try to get a map for learning use of glsl ready (wanted to do a full version map using glsl but that will likely take a long time).. should be ready within few days.

@Gig, I'll try to modify it further - add diffuse and a bit more specular components.


Title: Re: GLSL
Post by: Hitchhiker on May 26, 2013, 03:11:08 pm
@CGB01, the error message possibly relates to glsl program trying to use textures that a map shader would specify but which postprocessing does not.. just a long shot guess
I'll make a simple map that makes use of some glsl programs - possibly better to wait until this is done before testing again.
Thanks to you both Gig and CGB01 for taking time to beta test!
Cheers
 


Title: Re: GLSL
Post by: Gig on May 27, 2013, 05:42:06 am
Okay, I've done some more tests (this time with the Radeon HD 5670, the recent card).  :)

After fixing the shader file (file paths you post are still different than mine, e.g. I have to write "textures/gig/waternormal.jpg" in the place of of "glshader/3605-normal.jpg".... and I have to delete all the "second" -short- shader from the file... I don't know why you place it there.).

Both glsl_stream_v1_1.zip and glsl_stream_v1_1b.zip versions technically work with this video card, and they look like the same thing. But, unlike the previous version, they are no longer "awesome", because -as I told you yesterday... sorry for repeating, but I mention it again for completeness of this post- now the "pebbles" layer is really too much transparent, and almost unnoticeable (see the first screenshot attached here). I liked the previous version more.
The good thing of them is that now the "standard" version of the shader does not show a black and white oddity anymore, but shows the classic shader.
Other bad things of them include still having the problem of "doubled" marks on walls (an extra "burn" mark appears on water surface), and having the "standard" version of the shader that does not flow like Akom's shader (or like the glsl version if you prefer), while it should.

Other test I've done is to try your water_pool.zip.
I extracted the glsl files to /glsl/water folder, then the hydrowater.shader to the /scripts folder, and then modified it in a way to have it "create" /textures/liquids/clear_ripple3 (the other kind of water used in my map, that does not use hydrowater shader!), and to use textures/gig/waternormal.jpg instead of glshader/3605-normal.jpg.
I launched the map and, as you can see in the second screenshot, it does show it like "standard" hydrowater (which is not exactly adapt for the use in my cistern, because it has got too huge waves), just a little darker. It does not seem to give compiling errors, but it does not look like in your screenshot (http://openarena.ws/board/index.php?topic=4767.msg47256#msg47256). I have no ideas about the reason....  ???

PS: there is still also the problem with the sparks not working (http://openarena.ws/board/index.php?topic=4767.msg47238#msg47238)...
It looks like these GLSL shaders are a more wild beast than expected...

PPS: I hope my comments do not seem "harsh" in any way. I mean, I really appreciate your efforts, I'm just providing feedback, and at the moment there are some problems...  :)


Title: Re: GLSL
Post by: Hitchhiker on May 28, 2013, 08:20:03 am
hey Gig! :)

The problem with ripple water and pebbles not showing is the q3 shader blendfunc's doing. Changing the blendfunc will show the pebbles. I guess an easy way out of this is putting to use the patch that loads different shader files depending on the renderer used or if we add a check to the engine for glsl enabled cvar (so if glsl is enabled the shader files would be loaded from a separate folder - which would also remove need for the //GLSL keyword and possibly make the folder structure easier to maintain). I dont see how the blendfunc could be changed from within the glsl program and am sorry about this.
As for pool water.. i am not sure.. possibly the glsl program failed compilation?
And dont worry about the comments being harsh.. they are not and if we are to have any use of glsl in OA then I guess this is the road we have to walk..
I'm actually trying to get my map from Blender to OA... not an easy task :) but no matter.. few dozen tutorials later and I'm still at point zero..but looking forward. If I even manage to do this then I guess the glsl demo map will be an easier way to get this up and running.


Title: Re: GLSL
Post by: Gig on May 28, 2013, 08:43:13 am
I don't get... what's the reason you are trying to make a map in blender?
I've heard this is actually possible (maybe you can try to take a look to this page: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Modelling_a_map)... however I don't get the reason to get into a such (relatively?) difficult thing.

Why don't you just create the simple map with NetRadiant (http://openarena.ws/board/index.php?topic=2722.0), GTKRadiant or even Q3Radiant (the last one probably is easier to use, but correctly configuring it with OA is a pain... e.g. I've got some problems due to too many shader folders in OA...)?

PS: If I understand the problem, it's that the current way GLSL shaders work is "flawed" in the sense that you may require to specify different "blendfunc" options (that are part of Q3 shaders, not GLSL specific) for the GLSL version and for the normal version, but at the moment there is no way to tell the engine that a specific line of the shader has to be ignored when using the standard version of the shader (or vice versa). Correct?
Maybe when finding //GLSL the program should have not simply ignored the //GLSL, but should have actually applied the line only if GLSL support was enabled (and only if all glsl programs invoked by that shader do not encounter compiling errors). But a such change would require a new OA version (and may also break compatibilty -or simply change the final result- with shaders designed with the current system... not that at the moment there are many around, but...)... d'oh!


Title: Re: GLSL
Post by: Hitchhiker on May 28, 2013, 12:46:03 pm
yeah, the //GLSL keyword is processed at the moment regardless of the r_ext_vertex_shaders command being 0 or 1.. it's a bug easily fixed but does require at least a patch of the game executable. The other way is to create shaders that can work around this.
I've just spent few hours trying to get Gmax and Tempest to make a map but it seems this combination has a mind of its own and while seems OK for quick draft of a map, the moment one tries to do something more interesting things start to break apart. I'll try the Q3radiant next as I've had not much luck with Blender exporters either. The reason for a separate map is that I understood you would not like your map to be used as a demo map. But no worries, I'll get to making a simple one! :) I gotta :D , not because its easy but because it's hard :p


Title: Re: GLSL
Post by: Hitchhiker on May 28, 2013, 02:21:32 pm
forgot to send this one:
textures/liquids/clear_ripple3
   {
      qer_editorimage textures/liquids/pool3d_3c.tga
      qer_trans .5
      q3map_globaltexture
      surfaceparm trans
      surfaceparm nonsolid
      surfaceparm water
   
      cull disable
      deformVertexes wave 64 sin .5 .5 0 .5   
 
        {
         map textures/liquids/pool3d_5.jpg
         blendFunc GL_one GL_one
         tcmod scale 1 1
         tcmod transform 0 1.5 1 1.5 2 1
         tcmod scroll .025 -.001
      //GLSL map3 glshader/3605-normal.jpg
      //GLSL program water
      //GLSL vertexProgram glsl\water\water_vp.glsl
      //GLSL fragmentProgram glsl\water\water_fp.glsl

      }

   {
         map textures/liquids/pool3d_5.jpg
         blendFunc GL_dst_color GL_one
         rgbgen identity
         tcmod scale .5 .5
         tcmod transform 1.5 0 1.5 1 1 2
         tcmod scroll -.05 .001

      }


   
      {
         map textures/liquids/pool3d_5.jpg
         blendFunc GL_dst_color GL_one
         rgbgen identity
         tcmod scale .5 .5
         tcmod transform 0 1.5 1 1.5 2 1
         tcmod scroll .025 -.001
   
      }
      {
         map $lightmap
         blendFunc GL_dst_color GL_zero
         rgbgen identity     
      }
}

this is clear_water ripple3 I have.. hope it works for you - if it does not then probably glsl program didn't compile right?


Title: Re: GLSL
Post by: Hitchhiker on May 28, 2013, 02:39:21 pm
And a plasma effect. glsl program, screenshot and shader included. Please test when you get a moment ( not necessarily Gig! ;) )
Cheers


Title: Re: GLSL
Post by: Gig on May 29, 2013, 07:50:02 am
So, I removed the "clear_ripple3" replacement shader file (that I did from your previous "hydrowater" file), and created a new .shader file, copy-pasting your code from this post (http://openarena.ws/board/index.php?topic=4767.msg47290#msg47290), and making one only change: from
Code:
//GLSL map3 glshader/3605-normal.jpg
to
Code:
//GLSL map3 textures/gig/waternormal.jpg
.

The result is as shown in these screenshots, with r_ext_vertex_shader 0 and 1, respectively.

No GLSL-related warning seems to be shown in console.

Maybe some other blendfunc-related problem?

UPDATE: with "developer 1", I can see it loads glsl/water/water_fp.glsl and water.vp.glsl... but it does not mention "clear_ripple3"...


Title: Re: GLSL
Post by: Gig on May 29, 2013, 08:11:11 am
And a plasma effect. glsl program, screenshot and shader included. Please test when you get a moment ( not necessarily Gig! ;) )
Cheers

Considering the shader file "creates" textures/liquids/plasma_glsl and my map does not search for that file, I copied the shader code to make the shader file "create" also textures/liquids/clear_ripple2 and textures/liquids/clear_ripple3.

... and I got this:
Quote
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:10: error(#162) Wrong operand types no operation '*' exists that
takes a left-hand operand of type '4-component vector of float' and a right
operand of type 'highp 2-component vector of float' (or there is no
acceptable conversion)
ERROR: 0:10: error(#162) Wrong operand types no operation '-' exists that
takes a left-hand operand of type '4-component vector of float' and a right
operand of type '2-component vector of float' (or there is no acceptable
conversion)
ERROR: 0:10: error(#160) Cannot convert from '4-component vector of float' to
'highp 2-component vector of float'
ERROR: 0:18: error(#162) Wrong operand types no operation '+' exists that
takes a left-hand operand of type 'const highp 2-component vector of float'
and a right operand of type '4-component vector of float' (or there is no
acceptable conversion)
ERROR: error(#273) 4 compilation errors.  No code generated

Couldn't compile fragment shader for program plasma4WARNING:
RE_GLSL_RegisterProgram failed for 'program plasma4' in shader
'textures/liquids/clear_ripple2'
WARNING: RE_GLSL_RegisterProgram failed for 'program plasma4' in shader
'textures/liquids/clear_ripple3'
WARNING: RE_GLSL_RegisterProgram failed for 'program plasma4' in shader
'textures/liquids/clear_ripple3'

Water appears "still" (just inflating and deflating a little) and greyscale.

I also noticed that simply calling the shader file zplasma.shader made nothing happen (I saw the water like in the previous tests)... quite strange: I appositely called the file zplasma.shader instead of plasma.shader thinking about game's resources loading order... but...
I thought that (due to alphabetical order of file loading) a shader contained in a file a "zplasma.shader" would override a shader with the same name contained in a file called "clear_ripple3.shader" or "stream.shader", but it has been ignored instead. I had to remove my "clear_ripple3.shader" and "stream.shader" files from the "scripts folder" to have the game trying to use the effects in zplasma.shader (this way, the game tried to applied it and showed the errors I reported above).  ??? ??? ???
Taking a look with "developer1", it seems that the game loads the .shader files that are in my "scripts" folder in the OPPOSITE ALPHABETICAL ORDER than those it loads previously (from pk3 files). Example:
Quote
[...]
...loading 'scripts/oapowerups.shader'
...loading 'scripts/oasfx.shader'
...loading 'scripts/oasky.shader'
...loading 'scripts/oquartz.shader'
...loading 'scripts/pulchr.shader'
...loading 'scripts/q3map2_void3.shader'
...loading 'scripts/q3map2_void4.shader'
...loading 'scripts/qtex.shader'
...loading 'scripts/suction.shader'
...loading 'scripts/temporary.shader'
...loading 'scripts/terrain.shader'
...loading 'scripts/trak2.shader'
...loading 'scripts/zz_clear_ripple3.shader'
...loading 'scripts/gig_shaders02.shader'
...loading 'scripts/gig_shaders01.shader'

What a strange thing...  ???

P.S.: Hitch, you can use "screenshotjpeg" command (obviosly binded to a key) instead of "screenshot" to capture in-game screens in jpg instead of tga... smaller files. :)


Title: Re: GLSL
Post by: Hitchhiker on May 30, 2013, 05:13:58 am
Thanks for testing Gig! And thanks for the hint about the screenshots - I was wondering how to insert a screenshot that actually shows is a thread as graphics preview.
As for plasma errors, the corrected version here attached - I hope, but according to the errors you received this one should work.


Title: Re: GLSL
Post by: Gig on May 30, 2013, 07:14:54 am
Hi, the new plasma effect works. Very nice! :) (See first screenshot)

I was wondering if that could be used for the GLSL version of my sparks...

Lately I've added sparks around a few gametype-oriented things such as flags. This time, not as small "bars" but as a small circle (see second screenshot).
Using your plasma glsl effect for that gives the interesting result you see in the third screenshot.
In the fourth screenshot, instead, you can see that also in the place of the old sparks it shows its nice glsl colors... but maybe in that case the shape of the sparks polygons is too noticeably. What do you think?  :-\

However, when I turn off GLSL, it looks a little like water (my simple stripes animation is not in this shader)... Do you think you may make a single shader with actually your GLSL plasma for the GLSL part and my gig_stripes1 for the standard part?

UPDATE: I've just noticed a very strange thing... any suggestion about the possible reason is welcome. It's about the problem of the doubled "marks on walls"... it's not due to Hitch' shaders... I can notice them, in my map, even in Quake3, with the original clear_ripple2 and clear_ripple3. How to explain that????


Title: Re: GLSL
Post by: Hitchhiker on May 31, 2013, 06:46:36 am
I've modified the plasma glsl program to generate the alpha value on the fly.. Also, I've added some more math so that the pixels are more visible depending on where on the Z axis the pixel is. It is here attached if you want to try it with your stripes shader. Also included is a small shader file.
As for the glsl off version of the shader looking like water .. it is corrected in this version of the 'pak' file.. as each shader pass needs an image for OA to consider using it, I've used in the past an image from the water shader - now a plasma jpg is added.
As for your version of stripes shader - basically just use the version you have (that is not glsl enabled) and add in the first shader stage the following lines:

        //GLSL program plasma2
   //GLSL vertexProgram glsl\plasmas\plasma2\plasma_vp.glsl
   //GLSL fragmentProgram glsl\plasmas\plasma2\plasma_fp.glsl

And to make the glsl effect less visible, one could modify the glsl fragment program to include a line like this:
    if (alpha>0.5) { alpha=0.5; }    // this would cutoff all the color where alpha is larger than 0.5
OR a line like this:
    alpha=alpha/2;     // this would half the value of alpha

but I guess this is more something for the tutorial.. :|

[edit] removed the pak file


Title: Re: GLSL
Post by: Hitchhiker on May 31, 2013, 07:34:32 am
Here is another effect glsl can do easily. Here called texmix, and what it does is mix two textures using the red color component from the mask texture.

Pak file here attached.


Title: Re: GLSL
Post by: fromhell on May 31, 2013, 07:36:50 pm
Ok that's an interesting one because it works around the trouble of vertex painting terrain. I believe this is what Halo did on the PC


Title: Re: GLSL
Post by: Gig on June 01, 2013, 05:01:25 am
Sounds interesting. I hope to have some time to try it on monday...


Title: Re: GLSL
Post by: Hitchhiker on June 01, 2013, 09:22:33 am
I've added few variants of the texmix program. as texmix in its generic form uses scaling of texture coordinates, sometimes it will not tile well. to remedy this I've added a version for horizontal surfaces (or slopes for that matter but slopes might show stretching of the textures) and a 3d version of the texmix program (this one will almost certainly stretch texture in a strange way on some maps - to be used with this in mind).
Added also a fake aluminum texture - procedural texture that is sort of good for hangars?
Also added bands program - that draws bands using geometry position. and a texmix version of bands program - texbands.
screenshots:
1-bands
2-textured bands
3-texmix variant
4-fake aluminum (in the next post)


Title: Re: GLSL
Post by: Hitchhiker on June 01, 2013, 09:23:35 am
aluminum screenshot


Title: Re: GLSL
Post by: GrosBedo on June 01, 2013, 11:03:43 am
Just as a side-note, I've met a few demosceners at a conference and they gave me two interesting links that I thought I'd share here:

- Shadertoy.com (https://www.shadertoy.com/) : an online repository for shaders where you can execute them in-browser using JavaScript and you can also directly edit and try your own code.
- I.Q.'s website (http://www.iquilezles.org/www/index.htm) : where you can find tutorials, explanations and maths calculus for a lot of the shaders posted on Shadertoy.

Can be interesting resources for training.


Title: Re: GLSL
Post by: Hitchhiker on June 03, 2013, 05:34:56 am
Really a nice find GrosBedo, Thanks!

@all,
I've realized few days ago that OA, even though it uses normals in computations and can draw them on the screen, never actually sends those to the OpenGL. This is simple to fix but will have to be done in the next release. So, FYI and to save you possibly hours or trying and failing, if anybody tries working with glsl in OA and your glsl programs depend on the normals keep that in mind. And possibly (I'm not sure) this is true only for the map geometry and entities will have their geometry's normals available in glsl.
Bump mapping and parallax mapping can still be done but for simplicity they can only be made to work correctly on i.e. floors as the normal can be provided directly in the glsl program. So this is probably the next glsl program I'm posting.


Title: Re: GLSL
Post by: Gig on June 03, 2013, 06:50:12 am
       //GLSL program plasma2
   //GLSL vertexProgram glsl\plasmas\plasma2\plasma_vp.glsl
   //GLSL fragmentProgram glsl\plasmas\plasma2\plasma_fp.glsl
Tried (I had to change something in the path)... still nice... very similar to the previous one, isn't it?

Quote
And to make the glsl effect less visible, one could modify the glsl fragment program to include a line like this:
    if (alpha>0.5) { alpha=0.5; }    // this would cutoff all the color where alpha is larger than 0.5
OR a line like this:
    alpha=alpha/2;     // this would half the value of alpha
but I guess this is more something for the tutorial.. :|
Simply adding a such line before the final "color+=" is not enough (the variable "alpha" is not initialized). I've not further tested this.

However, for the moment it looks like your plasma, applied to my stripes shader, is the only effect (that I have been able to actually have working) that I think I can actually use in my map, because both standard version and GLSL versions of the shader look good. However, only in the "circular" brush (around the white flag in my previous screenshot (http://openarena.ws/board/index.php?action=dlattach;topic=4767.0;attach=4426;image))... in its current state, it's not so adapt for the current way I created the stripes brushes above the jump-pad. Of course I may divide into gig_stripes1 (standard only) and gig_stripes2 (standard+glsl), for example.
Would the energy around gametype-related items (flags, skull generator, obelisks) be enough? Maybe I could place the circular energy field also over jump-pads, instead of the current "stripes" brushes... but I spent some work on them and I don't enjoy the idea of removing all of them (maybe I could keep them over the accelerator pads only?).

However, considering that changes to the way GLSL currently works will be required for the next OA release (inability to use different blendfunc options for glsl and standard versions, etc.), I don't know if releasing maps which follow the current implementation is a good idea or not. My fear is that the GLSL version map may become "broken" when the next OA version will be released. What do you think? Do you already have a precise idea of how GLSL behavior will change in the next OA release?

I've added few variants of the texmix program. ...
I've not been able to have them work. As usual, I had to fix some file paths (e.g. it didn't find mask.jpg, so I had to make the shader look for your mix_mask.jpg instead)... but then I still encountered some compiling errors.
Quote
Error:
Vertex shader failed to compile with the following errors:
ERROR: 0:37: error(#160) Cannot convert from 'attribute 4-component vector of
float' to '2-component vector of float'
ERROR: error(#273) 1 compilation errors.  No code generated

Couldn't compile vertex shader for program bands2WARNING:
RE_GLSL_RegisterProgram failed for 'program bands2' in shader
'textures/organics/dirt'
WARNING: RE_GLSL_RegisterProgram failed for 'program bands2' in shader
'textures/organics/dirt'

Quote
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:28: error(#202) No matching overloaded function found mix
ERROR: 0:28: error(#174) Not enough data provided for construction
constructor
ERROR: error(#273) 2 compilation errors.  No code generated

Couldn't compile fragment shader for program texmixWARNING:
RE_GLSL_RegisterProgram failed for 'program texmix' in shader
'textures/organics/dirt'
WARNING: RE_GLSL_RegisterProgram failed for 'program texmix' in shader
'textures/organics/dirt'

However, in your screenshots they look quite interesting...


Title: Re: GLSL
Post by: Hitchhiker on June 03, 2013, 02:41:56 pm
Hi Gig and thanks for testing!
the glsl behavior should not change and anything that works now will work in the next release - things will only be added. I think I'll have to get an ATi and an Intel card to make sure these things work on all three vendors.
for plasma, yes, not much changed. the second version of the program is changing intensity with time and all this on z axis.
I think I managed to correct the lines that give errors. New pak here attached and I'll have a look at missing images and shader files.
It is not an obligation to use glsl in your map. Just make it as you would without the glsl.
I've found a possible way of easily making maps so will try to work on that and post a glsl map soon.. well, 'soon' if a month or two count as soon :)

@all, If anybody has a question or glsl program request please let me know. As you can see some testing will be required for each new program. Also a question, has anybody except Gig and CGB01 tried these programs?

I'll focus on the map making for now but remain available to look into the glsl programs if you need.

As for the tutorial, I'll try to make the changes suggested but will likely look into that only in week-two's time.


Title: Re: GLSL
Post by: Gig on June 04, 2013, 01:07:52 am
Hi Gig and thanks for testing!
the glsl behavior should not change and anything that works now will work in the next release - things will only be added.
Are you sure? I thought that when that //GLSL blendunc thing behavior would be changed, existing shaders using it (if any) would change look, at least in one of the two rendering modes.

However, I was also thinking about another possible solution. What about releasing OACMP1 without any GLSL effect, and later releasing a small patch file that would add 0.8.8 GLSL effects to some of the customized textures/shaders that are in the OACMP? This way, the main OACMP itself would not be tied to a specific OA engine version. If the next OA release (I have no idea when it will be released) would break the old glsl shaders, updating the small patch file would be enough to use the same oacmp pack with the new release.
If you think you will add that "texmix" effect to the ground ("dirt" texture, IIRC), but we don't want to apply it to all Q3/OA maps that use that "dirt" texture, I may include a slightly modified version of that texture in the "textures/gig" folder, and later the patch may include a shader with the same path/name, hence applying that shader to my map only.
Of course, we may decide to have the GLSL patch not affect OACMP-specific stuff only, but also "standard" textures used in baseoa... but maybe this could be done in a later step, considering that would require more time to do and to test.

What are your opinions, guys?


-UPDATE-
@Hitch:
From your latest package, I've been able to have the "texmix_detail" effect working. Well, at the current state the final result give too much the impression of "stripes" and the grass has some strange purple parts (see screenshot)... however it's interesting.

Also "dirtrock" works. It's similar to texmix_detail, but a little better (no strange purple parts in the grass). See screenshot.

I have not been able to make "texbands" shader work, instead. Here it is the log.
Quote
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:41: error(#202) No matching overloaded function found mix
ERROR: 0:41: error(#174) Not enough data provided for construction
constructor
ERROR: error(#273) 2 compilation errors.  No code generated

Couldn't compile fragment shader for program bands2WARNING:
RE_GLSL_RegisterProgram failed for 'program bands2' in shader
'textures/organics/dirt'
WARNING: RE_GLSL_RegisterProgram failed for 'program bands2' in shader
'textures/organics/dirt'
I don't know if there were something more to test.


Title: Re: GLSL
Post by: Hitchhiker on June 04, 2013, 02:09:00 pm
Hi Gig,
the stripes effect is due to scaling of the mask image. this scaling is controlled from within the glsl program - that's why there are few versions of the program in the 'pak' file - naming of the programs is explained in the readme.txt
The pink color should not happen and I'm thinking the value of the final color is calculated in a wrong way. I haven't yet checked this and will do so soon.
As for the bands and the compile error.. all the errors we've seen so far are due to 'overloading' aka the glsl program tried to use i.e. 4 component variable where it should use a 2 component one or similar. Nvidia seems to take care of this automatically but ATI does not. Anyways..not important..
I've changed the line 41 and the latest 'pak' is here attached.

As for glsl keyword, I think that one needs to be kept if the same shaders are to be used for vanilla and glsl rendering. The only problem with it now is that it is not processed (skipped) "only" when glsl programs are enabled.

Then the shaders I include are not intended for use in OA as they are. Think of them more of an example of how the particular glsl program is loaded and which parameters it needs.

Possibly the glsl enabled shaders can be kept in a separate folder and a check to load them first (or ignore them completely) can be added to OA. Then OA would act accordingly depending on if glsl is enabled or not.

I'd post the parallax bump mapping but am missing some good textures for diffuse, height and normal. If anyone has a suggestion?


Title: Re: GLSL
Post by: Hitchhiker on June 04, 2013, 04:46:57 pm
I've found on the net GPL2 texture and modified it so it tiles, created a heightmap texture and a normal map to go with it. I'll try to clean the 'glsl pak' file and post probably tomorrow. In the meantime, here are two screenshots of the parallax bump mapping - two versions, rocks and snow.


Title: Re: GLSL
Post by: fromhell on June 04, 2013, 04:56:47 pm
Can there just be a generic cubemap+normalmap reflection shader like Darkplaces? Modern games are typically dressed in lots of it (CoD especially).


Title: Re: GLSL
Post by: Gig on June 05, 2013, 12:38:27 am
naming of the programs is explained in the readme.txt
GLSL pack is becoming too big for quick testing. I mean, each time I have to modify the shader files to have them working with my map, and to use them alternately because different shader files would try to use the same shader name (would be applied to the same part of the map). To quickly test the shaders, we really need you appositely prepare a demo map containing more of them at the same time (different effects shown in different places of the same map)...

Quote
I've changed the line 41 and the latest 'pak' is here attached.
This time I have been able to use your "texbands".  :) Very interesting to know that a such thing is possible (even for a japan-flag themed (http://openarena.ws/board/index.php?action=dlattach;topic=4767.0;attach=4437;image) map maybe?). I also noticed you managed to apply it only to vertical walls, while the same texture is used also in the ground, which is unaffected. Interesting!

Quote
As for glsl keyword, I think that one needs to be kept if the same shaders are to be used for vanilla and glsl rendering. The only problem with it now is that it is not processed (skipped) "only" when glsl programs are enabled.
You are the expert, man. I can only guess that glsl and standard versions of a shader may need different "blendfunc" parameters... while the later stages can be completely skipped by simply invoking "skip" glsl program (if I understood correctly), how to prevent the blendfunc/texture/any other "standard" option (e.g. tcMod scroll) in the first stage from being used also in the GLSL version? And if one would like to use the "tcMod scroll" option for the GLSL version only? (I can guess an answer for the latter could be "just make the scroll happen directly inside the glsl program", but...)...
Oh, well... do your tests and always try how shaders look in both "standard" and "glsl" modes... then take note of the problems you encounter. This way, you should be able to better think if the glsl system requires more or less tweaks for the next engine version. Having a shader look good in both glsl and standard mode is a priority.
Quote
Then the shaders I include are not intended for use in OA as they are. Think of them more of an example of how the particular glsl program is loaded and which parameters it needs.
Again, an apposite map, containing all the effects at the same time (a package ready out-of-the-box), would be welcome.

Quote
Possibly the glsl enabled shaders can be kept in a separate folder and a check to load them first (or ignore them completely) can be added to OA. Then OA would act accordingly depending on if glsl is enabled or not.
I can guess this may be an option. Maybe Fromhell is more adapt than me about these "design/behavior" decisions.
Quote
I'd post the parallax bump mapping
I've taken a look to your bump mapping screenshots. Great!  :) :)


Title: Re: GLSL
Post by: Hitchhiker on June 05, 2013, 07:40:00 am
Hi!

@fromhell, I'll try to find an example of this (I'm not sure which effect it creates) - if you have a yt video link you could send?

@Gig, again, thanks for testing! I can only imagine the look on your face each time I send a new pak file :( sorry about that, I've now done an effort to make it cleaner. I think my mapping is not as good as I'd like to so I'll just put around some boxes and make each box show different glsl program.

@all, I've tried to clean the folders so that more or less shaders can be copy/pasted (the shader part, not the name of the shader). I think all the textures are included. And a readme.txt in scripts folder lists the glsl programs - probably next thing to do is add to this readme.txt the //GLSL lines for each shader so it can be easily included in any shader. There are no new postprocessing programs yet.

As for //GLSL keyword, if we can have glsl shaders be looked up in a separate folder first it is not needed. A separate folder could actually make it easier to maintain too. But for the moment this is not in place. Further, looking up a shader in a separate folder can help performance as well as glsl can compact many shader stages into a single one - hence reducing the number of polygons drawn.

For the community pack in progress the following scenario can work:
    -if anyone wants to add the glsl feature, they can do it using the //GLSL keyword
    -possibly, to be 100% sure the glsl does not change anything in another map, use a unique name for the shader
    -when the new OA is out, we remove the //GLSL keyword altogether and move the glsl enabled shaders to a new folder and have OA look up the shader from there when needed
    -removing the support for //GLSL keyword will turn the glsl commands in any shader into a simple comment
    -at that time, any shader containing //GLSL will be rendered as it would without the glsl support and if glsl is enabled the glsl version of the shader will be found in this new folder
Hope this was explained well and makes sense?

As the pak file grew since the beginning I think this is the last complete pack file I'm sending. From now on only the changes will be posted.

I also added caustics glsl program and a sky glsl program. Sky (not skybox) screenshot here attached.


Title: Re: GLSL
Post by: Gig on June 06, 2013, 12:33:31 am
Further, looking up a shader in a separate folder can help performance as well as glsl can compact many shader stages into a single one - hence reducing the number of polygons drawn.
Does this mean that the current "skip" program, to be used in later stages that do not interest GLSL, is not as resource-saver?

Quote
I think my mapping is not as good as I'd like to so I'll just put around some boxes and make each box show different glsl program.
That would be good. The current pack creates shaders under /textures/glshader... a map actually searching for those shaders would be required.

Quote
There are no new postprocessing programs yet.
About postprocessing, I think that when we will have some time, we should think more about that feature at all... I fear in its current behavior it's a little "dangerous" for cheating. Maybe we may include some server-side way to control or limit its use, to prevent abuse for cheating (I suppose a video filter that increases visibility -e.g. by adding brightness or outlines-, and noone else knows you are using it, may be considered cheating). E.g. a new DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Videoflags]videoflags (http://([b) value to forbid r_postprocess use, or a new cvar to force all users that connect to that server to use the same glsl postprocess program (this would allow admins to set up a "edges server", for example... however the problem of this would be that there would still be a difference between GLSL-enabled users and GLSL-disabled users).
However, I just noticed that the current videoflags does not limit r_gamma values as I thought before.

Quote
For the community pack in progress the following scenario can work:
    -when the new OA is out, we remove the //GLSL keyword altogether and move the glsl enabled shaders to a new folder and have OA look up the shader from there when needed
    -removing the support for //GLSL keyword will turn the glsl commands in any shader into a simple comment
Uhm... but the community mappack (OACMP) is thought as a separate package than the main OA game. I mean, probably OACMP maps will not be part of "stock" maps in the next official OA release, but will continue to live as a separate OACMP (of course, decision is for Fromhell), thus having an OA official release "fixing" OACMP shaders is not very probable (also thinking about pak load order, I don't know what name will take the final OACMP package)... maybe better a small OACMP-dedicated patch? I don't know.
I don't even know if separing GLSL shaders into an apposite folder would be comfortable... I mean, how to know that a specific shader you are modifying has got also a GLSL variant, then? Relying on a comment from shader author ("//search for the glsl version of this shader under path/file")?


Title: Re: GLSL
Post by: Hitchhiker on June 06, 2013, 04:07:45 am
@fromhell, I had a look at cubemapping and it seems it needs normals. I just checked and neither entities nor world meshes have them looking from glsl.

the skip program is, at this stage, reducing the number of rendering passes. I meant that if a glsl only version of the shader is made then there will be no stages that will need to be discarded. then, now I'm thinking again, new new version of OA could only change to read anything behind the //GLSL keyword when the glsl is enabled - no need to remove it. and in addition to that if a separate folder for glsl shaders is used, could be an added feature.
as for being able to know if a glsl program/shader mix exist for a shader.. possibly a developer mode console could print out a message from where it is taking the shaders at map loading time?  but then again, this would only work with new version of OA and if anyone is making a map using an older version they would be left in the dark. possibly if anyone wants to use glsl they could copy/paste the shader they need to a new shader with an unique name and use that one in a map? probably a question for the mappers, to tell in a better way how they would like to see this working?



Title: Re: GLSL
Post by: Hitchhiker on June 07, 2013, 05:48:55 am
test map for glsl
 
please test and send back any error message.

[edit: version as of 17 June 2013]


Title: Re: GLSL
Post by: Gig on June 07, 2013, 07:46:31 am
You asked for it, you got it:
Quote
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:33: error(#160) Cannot convert from '3-component vector of float' to
'highp float'
ERROR: error(#273) 1 compilation errors.  No code generated

Couldn't compile fragment shader for program metal1WARNING:
RE_GLSL_RegisterProgram failed for 'program metal1' in shader
'textures/glshader/metal'
WARNING: RE_GLSL_RegisterProgram failed for 'program metal1' in shader
'textures/glshader/metal'
WARNING: RE_GLSL_RegisterProgram failed for 'program metal1' in shader
'textures/glshader/metal'
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:7: error(#247) Function return is not matching type
ERROR: error(#273) 1 compilation errors.  No code generated

Couldn't compile fragment shader for program bands2WARNING:
RE_GLSL_RegisterProgram failed for 'program bands2' in shader
'textures/glshader/bands2'
Error:
Vertex shader failed to compile with the following errors:
ERROR: 0:38: error(#160) Cannot convert from 'attribute 4-component vector of
float' to '2-component vector of float'
ERROR: error(#273) 1 compilation errors.  No code generated

Couldn't compile vertex shader for program texmixdetailWARNING:
RE_GLSL_RegisterProgram failed for 'program texmixdetail' in shader
'textures/glshader/texmixdetail'
WARNING: RE_GLSL_RegisterProgram failed for 'program texmixdetail' in shader
'textures/glshader/texmixdetail'
:D

By the way, nice tech test map. Good work!  :)

About water effects: one does not have "water" properties (it's solid)... and another one shows a glitch near the border (see screenshot).
Maybe it may be caused by having both "deformVertexes" and "fogparms" in the same shader? I don't know. Maybe they are just overlapping brushes, like in a few other places of the map (now that I look more carefully, it seems that it is the grass brush overlapping with the pool side brush).
I have no idea if the directive to always specify also "surfaceparm fog" (mentioned in Q3A shader manual (http://toolz.nexuizninjaz.com/shader/)) when using "fogparms" is still valid also when applying "fogparms" to water.

Some of the shaders look bad if you turn off glsl, but maybe you are not interested to this now.

Speaking about water... did you remember the problem of "double" hit marks on water? Well, it turns out that, for some reason, this happen where the water is not deep enough... where the water is deep about 22 units or more, the glitch (there since Q3A) does not happen. However, just specifying "surfaceparm nomarks" in the water shader is enough to prevent the glitch from happening at all.


Title: Re: GLSL
Post by: Hitchhiker on June 08, 2013, 08:33:55 am
I corrected the three errors reported (hopefully, as I cannot test it).
as for water being solid.. and the glitches I'll do it next weekend. I'm re-uploading the glsl map to the post above.
I've tried adding fog to the sky shader but did not manage. This could give a nice haze effect but shaders are not something I know.
This map is just a way of having all the glsl programs in one place so testing and eventual use could be easier.
So I think we just need someone having an Intel card to test as well?


Title: Re: GLSL
Post by: Gig on June 10, 2013, 04:50:53 am
Hitch, nice job!
A map with all those effects available, ready to test out-of-the box (no more manual tweaks needed!) is very comfortable.  ;D But you forgot to include source .map file.  ::)

Maybe you forgot to explain people an important thing: with this package, anyone can test your GLSL effects in a very easy way.
1) Just download z_glsl.pk3 and place it in your baseoa folder.
2) Launch openarena.
3) set r_ext_vertex_shader 1
4) load map glsltest
5) look around.

-----------
Well, I downloaded the new version of the map, and the errors seem gone.
Can I suggest that for the water (not the one in the pool) a "replicable" texture (like the "pebbles" we used in my map, but well most OA textures are "replicable" -in the sense they fit when placed side-by-side-) may better fit?

I really like what "bump mapping" can do to give more "depth" to surfaces without creating tons of polygons. Sorry I'm not very inside this stuff so I don't know which kind of mapping it is ("normal mapping" maybe? I don't know... so I simply said "bump mapping", hoping that's a generic term that may fit more cases... please correct me if I'm wrong). By the way, took a look to screenshots attached: it's only one brush, but it shows a sort of "depression" in the ground that changes accordingly to my movement. Very good! The only problem is that its colors do not look very natural, but maybe this is due to the textures chosen?
------------

About Q3 fog, it's not to be used in the sky shader, I think.
It's to be used in a brush with a shader with both "surfaceparm fog" and "fogparms <various parameters>" (take a look to Q3 shader manual http://toolz.nexuizninjaz.com/shader/ for more infos).


Title: Re: GLSL
Post by: grey matter on June 10, 2013, 10:29:12 am
Can I suggest that for the water (not the one in the pool) a "replicable" texture (like the "pebbles" we used in my map, but well most OA textures are "replicable" -in the sense they fit when placed side-by-side-) may better fit?
I think the word you are looking for is tileable or seamless.


Title: Re: GLSL
Post by: GrosBedo on June 10, 2013, 02:48:58 pm
Incredible job you're doing here guys! Looks awesome!


Title: Re: GLSL
Post by: Hitchhiker on June 15, 2013, 12:27:39 pm
 ;) thanks GrosBedo!
Even if some things are still missing from OA in order for the glsl implementation to be a fully fledged one, what is in place is already quite usable and stable. We do need people to test the glsl programs and so far Gig was doing almost all of the work there! Also, without Gig we'd probably never have this test map in the first place. So my special thanks go to Gig and CGB01 for testing and to pelya for the wiki upload. Also to all of you who have downloaded and tried the map!
Speaking of wiki upload.. I have a new version of the tutorial here attached but am not sure about the wiki... will try to upload it there - will need some time though.
I don't think I'll manage to correct the glitches in the map this weekend but will get to it eventually. Possibly get the non-glsl versions of the shaders to show correctly as well.
This is not an exclusive thing we're trying to do here so any help is welcome!
Cheers!


Title: Re: GLSL
Post by: Hitchhiker on June 16, 2013, 07:14:47 am
Wiki article created: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Glsl_Tutorial_Test

I used a new page, if you're all Ok with the way the article looks let me know and I'll rename or copy the text to the one already created.


Title: Re: GLSL
Post by: GrosBedo on June 16, 2013, 11:33:34 am
Seems good to me! Seems clear to me plus you added illustrative images.

However I'm not as expert as Gig concerning wikis and docs ;)


Title: Re: GLSL
Post by: Gig on June 17, 2013, 01:18:21 am
Ugh! Huge work approaching!

I would have preferred if you would have direcly updated the existing wiki page, instead of making an almost brand-new odt file....
I will have to somehow compare
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/GLSL
and
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Glsl_Tutorial_Test

and try to merge them... This will require some time.

However, don't worry...


Title: Re: GLSL
Post by: CGB01 on June 17, 2013, 05:46:41 am
test map for glsl
 
please test and send back any error message.

Sorry for the delay in testing this map Hitch, been kind of busy :(

Here's the error I'm getting;

Error:
The fragment shader uses varying vertex, but geometry shader does not write to it.

^3Couldn't link shaders for program plasma^3WARNING: RE_GLSL_RegisterProgram failed for 'program plasma' in shader 'textures/glshader/plasma'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program plasma' in shader 'textures/glshader/plasma'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program plasma' in shader 'textures/glshader/plasma'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program plasma' in shader 'textures/glshader/plasma'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program plasma' in shader 'textures/glshader/plasma'
Error:
ERROR: 0:19: '[' :  array must be redeclared with a size before being indexed with a variable
WARNING: 0:52: 'assing' : implict conversion between types allowed from GLSL 1.20


^3Couldn't compile fragment shader for program zmix^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'
^3WARNING: RE_GLSL_RegisterProgram failed for 'program zmix' in shader 'textures/glshader/zmix'


The screenshot is interesting...


Title: Re: GLSL
Post by: Hitchhiker on June 17, 2013, 11:02:58 am
@Gig, just needs to be read and eventually the wording changed. Everything that is in the original page should be in the temporary one. If the tutorial makes sense then simply copy/pasting the wiki text should do. I think deleting a page on wiki is not complicated.

@CGB01, thanks for testing and no worries, I guess we all have other things happening in our lives than GLSL or OA. I think the errors are now corrected and the pk3 file above updated.



Title: Re: GLSL
Post by: Hitchhiker on June 17, 2013, 11:04:44 am
p.s. @CGB01... if you write '/r_postprocess' in the console what does OA outputs?


Title: Re: GLSL
Post by: Gig on June 18, 2013, 12:54:37 am
@Gig, just needs to be read and eventually the wording changed. Everything that is in the original page should be in the temporary one. If the tutorial makes sense then simply copy/pasting the wiki text should do. I think deleting a page on wiki is not complicated.
It's not the problem of deleting a page (I can do it due to the fact Fromhell game me admin rights for the wiki... other people can add {{delete}} template to request for deletion).
The problem is that i already did a relatively huge work of markup fixing in the first page, so I would have preferred if you would have continued from there, further modifying that page, instead of creating a new page where I will have to fix the markup again. I may fix markup in all the new page, and then move it in the place of the original one... or I may copy-paste it section by section, fixing markup while doing it.
I can do it this time (when I find some some), but I cannot do a such thing everytime you will make a change to the guide. We need you learn to modify the wiki page directly, without copy-pasting from ODT file each time. You know, you can ask me for any kind of help about using the wiki (I don't have all the answers, but I do what I can).

PS: I downloaded the new version of the glsl pack (http://openarena.ws/board/index.php?topic=4767.msg47339#msg47339). Still no error appears with the Radeon HD.
I have to tell you again I really like those bump mapping effects.


Title: Re: GLSL
Post by: CGB01 on June 18, 2013, 04:37:52 am
p.s. @CGB01... if you write '/r_postprocess' in the console what does OA outputs?

Hitch, it reports; "water\stream"


Title: Re: GLSL
Post by: Hitchhiker on June 18, 2013, 11:59:48 am
@CGB01, try using 'r_postprocess none' ?

@Gig, sorry for the trouble. If you tell me what to be careful about (or have a net page about markup for me to read) I can probably do it faster? I'm actually reading the http://en.wikipedia.org/wiki/Help:Wiki_markup so can try to format the tutorial in a good way - if you think (knowing the markup) that this might end in tears, please let me know and I won't touch it.
I probably won't get to it before the weekend so no worries, at least, before Friday evening. ;)

cheers!


Title: Re: GLSL
Post by: Gig on June 19, 2013, 01:35:44 am
Well, I think the markup of the old page, after the edits I did, was acceptable (well, I'm not an "artist" in wiki markup, so someone may do better). I think we may try to follow the same in the new page.

I think the page you are following should be generally okay (although Wikia may have some little difference from Wikipedia).
It should be more detailed than the short reminder I wrote here:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/WikiWorks#Appendix:_Basic_MediaWiki_markup


Title: Re: GLSL
Post by: Hitchhiker on June 23, 2013, 06:11:38 am
I've cleaned a bit the wiki page (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Glsl_Tutorial_Test
Can it work like this or needs more polishing?


Title: Re: GLSL
Post by: Gig on June 23, 2013, 12:09:46 pm
I'll look into it on Tuesday.

(Written from mobile phone)


Title: Re: GLSL
Post by: Gig on June 25, 2013, 11:03:05 am
For today, I checked up to DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Glsl_Tutorial_Test#Shaders_.28Quake_3.29]this section (http://([b). I will continue in the next days.


Title: Re: GLSL
Post by: Gig on June 26, 2013, 08:19:09 am
Okay, I think I've fixed markup in the page. DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Glsl_Tutorial_Test&diff=14276&oldid=14240]Are they ok? (http://([b)
There were many unnecessary carriage returns (e.g. in source code sections), and some "nowiki" where they were not required. I suppose they were added by Wikia's WYSIWYG editor: again, I suggest to NEVER use it, but always switch to the classic source code view before editing (you can even totally disable the WYSIWYG editor in your personal options).

In general, it looks to me a nice work. Congrats, Hitch!

I think you may better tell the difference between the two screenshots with and without glsl effect in ce1m7 map... the texture is different, but how? Does that include some yellow/greenish parts (musk maybe?)?


Title: Re: GLSL
Post by: Hitchhiker on July 02, 2013, 12:17:30 pm
Hi Gig,
I did check the page and corrected one typo I could find. It looks OK for me too.
Do you want me to copy/paste the source to the 'GLSL Tutorial' page or simply rename this page and remove the other one? Let me know.
I think congrats go your way equally for all the testing, editing and all of the good suggestions so I think your name should also show on the tutorial page - hope you're OK for this.


Title: Re: GLSL
Post by: fromhell on July 02, 2013, 05:24:55 pm
Do you have a simple refraction shader?


Title: Re: GLSL
Post by: Gig on July 03, 2013, 01:02:43 am
Do you have a simple refraction shader?
Do you mean something like this?
http://openarena.ws/board/index.php?topic=4767.msg47236#msg47236
(see video attached there; to test exactly that specific effect, see this post (http://openarena.ws/board/index.php?topic=4767.msg47240#msg47240). The problem with that shader was when one had glsl disabled.)

Something similar is in the glsl test map (http://openarena.ws/board/index.php?topic=4767.msg47364#msg47364)...


Title: Re: GLSL
Post by: Gig on July 03, 2013, 01:11:32 am
Do you want me to copy/paste the source to the 'GLSL Tutorial' page or simply rename this page and remove the other one? Let me know.
I can easily delete the old version, and then rename the new version. I think we two were the only authors of that page, so no CC-BY-SA attribution issues.
What will be the final title? "GLSL" or "GLSL tutorial"? And if we choose to use "GLSL tutorial" as the title, what should I do with "GLSL" title? A redirect to the tutorial? A redirect to "Manual/Graphic options#GLSL effects"? A separate page with something (what?) in it?

PS: What about better explaining what one should notice in those screenshots?


Title: Re: GLSL
Post by: fromhell on November 03, 2013, 10:33:17 am
Having more GLSL fun again...  WIP 3dfx shader

(http://leileilol.mancubus.net/crap/3dfx3.jpg)


Title: Re: GLSL
Post by: matija123 on November 03, 2013, 02:40:59 pm
Nice :)


Title: Re: GLSL
Post by: Gig on November 05, 2013, 02:11:05 am
Good job, Fromhell.  :) But with "3dfx" are you menaing the old, glorious 3dfx cards (https://en.wikipedia.org/wiki/3dfx)?
I didn't think 3dfx had GLSL support... latest 3dfx cards are from year 2000, and OpenGL 2.0 (the first OpenGL version that officially included GLSL, IIRC) is from 2004...  :-\

I can guess with "3dfx" you mean "giving more depth to textures", instead... right? Not related to the old "3dfx hardware" at all...


Title: Re: GLSL
Post by: fromhell on November 05, 2013, 10:20:23 am
It's a shader that's meant to mimic their infamous on-chip DAC 4x1 filtering from the Voodoo Graphics and Voodoo2 cards which can play a part of the whole 3dfx nostalgia thing. (96 and 98 respectively)


The actual shader itself requires a video card supporting pixel shader 3.0.


Title: Re: GLSL
Post by: Hitchhiker on November 06, 2013, 05:31:48 pm
Hi, was away from OA source for some time now. But just wanted to let you know I haven't abandoned yet. I think this December I'll have some time to fix those normals, escape keywords and hopefully fix few issues I'm seeing with glsl lights (just fyi..source not sent to the maintainers yet); tangent, binormal calculations (that come in handy in glsl programs); making possible to use multiple postprocessing effects at the same time(maybe send in the DOF, godrays postprocessing programs); ... hope it all works out nicely.
Hope you're all doing well.



Title: Suggestions for GLSL improvements
Post by: Gig on November 07, 2013, 03:24:12 am
Hi Hitch! How are you?  :) I was waiting for the official release of OACMPv1 to ask you about making a GLSL patch for it...
... and to propose you a few ideas to make GLSL support better. Well, for this last part, I'm going to tell you now, then...  :)

1) Current "freedom" of GLSL postprocessing mode may be theoretically used to get unfair advantage over other players (with programs that may allow to more easily see players, similar to brightskins, or adding more gamma in dark places): maybe we may put in a server-side variable (or a new DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Dmflags]dmflags (http://([b) or DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Videoflags]videoflags (http://([b) value?) to let server admins to decide preventing clients from running GLSL postprocessing programs (or, next step, even to force all of them to use the same postprocessing program -example: "connect to my glsl Edges server!"-, however that may not be completely fair anyway, considering that some players may not enable/support GLSL at all, or that a specific GLSL program may not run with some cards). What do you think?

2) The main problem with 0.8.8 implementation of GLSL seems to be the difficulty of making a certain shader look good in both "GLSL" and "standard" modes (e.g. "blendfunc" thought for a mode may completely mess up the shader look in the other one). Thanks to "glsl skip" program, it's possible to prevent extra stages designed only for "standard" shaders to be considered when working in glsl mode, right? But how to make the opposite, I mean be sure that a stage designed for GLSL mode only is not considered when running in standard mode? I can guess the best option would have been something like the "detail" keyword (according to Q3A shader manual, if you set a stage as "detail" -check here for usage infos and limitations (http://www.heppler.com/shader/shader/section6.htm#6.9)-, that stage will not be drawn if the user uses the "r_detailtextures 0" setting), but I can guess that a similar thing would not be applicable for us, due to the lack of backwards compatibily: if the hypothetical "glslstage" keyword would be read by an older version, it would be ignored (then the rest of the stage would be computed in all cases) if behind a comment "//", or would just completely break the shader (showing a "missing texure" while in-game) if without a comment "//". Correct?
Then, how to workaround the problem? I can guess that one may make some stages executed in GLSL mode only, by setting "//GLSL" keyword in front of ALL THE LINES of that stage. Would that work? I'm not sure... IIRC with the current implementation there is some problem of GLSL lines/commands not completely ignored in some cases (when glsl support is disabled? When it is enabled, but the card does not support it? When a GLSL program fails compiling? I don't remember)... however we need some ways to use different "blendfunc"s for GLSL and standard modes.
Example:
Quote
[...]
{
//GLSL program <name>
}
[...]
for running the whole stage in GLSL mode only, would became
Quote
[...]
//GLSL {
//GLSL program <name>
//GLSL }
[...]
Would that work?
Time ago, while taking a look to a gamecode source for some reason, I noticed that some parts for code were "commented out" not by "//" on each line, but at entire blocks contained within "/*" and "*/" characters, IIRC (I'm not 100% sure of which characters they were, but I think they are these). With a quick test, it seems to me that this kind of "comment block" also works within Q3 shaders. Is it correct?
I would suggest you to foresee new "GLSL fake comment start/end" commands (e.g. "/*GLSL" and "GLSL*/"), to allow this:
Quote
[...]
/*GLSL {
program <name>
} GLSL*/
[...]
or (hopefully with the same result)
Quote
[...]
/*GLSL {
//GLSL program <name>
} GLSL*/
[...]
to have the effect of considering that stage ONLY IF you are running in GLSL mode, on a card supporting GLSL. Of course, in this example, the part to comment out is very small, but consider more advanced shaders...
Developers should be able to "GLSL fake comment (comment out if glsl disabled)" single lines or also bigger chunks.

3) Double checking how shader elaboration behaves in the various situations (glsl variable disabled, glsl variable enabled but video card not supporting, glsl enabled but one of the glsl programs failed compiling), allowing to safely display standard shader if necessary. One shader may theoretically contain more glsl programs: if even only one of them fails compiling, the result would be different that expected, so that entire shader should interrupt running in GLSL mode, and start again from the beginning, but in standard mode this time (of course, I'm not telling to disable glsl for all shaders, but only for that one).

4) Check/fix minor issues, e.g. for some reasons I ignore, postprocessing effect does not affect a few parts of the HUD interface (maybe the health meter, only when it's over 100 HP? I don't remember exactly.).

Hitch, I know I have been too "verbose", but please read!  :) I think this is important, for better GLSL support in future OA versions.
Of course, also Fromhell and any other one can say his/her own opinion about this stuff... and correct me if I said something wrong (as you can see, there are various things I'm not 100% sure).

Update: please read also this other post (http://openarena.ws/board/index.php?topic=4767.msg48889#msg48889) from the next day.


Title: Re: GLSL
Post by: fromhell on November 07, 2013, 07:23:56 am
Can there be a possibility for a second GLSL postprocess shader pass? My 3dfx shader could use it... possibly maybe as its own cvar


Title: Re: GLSL
Post by: Hitchhiker on November 07, 2013, 12:38:45 pm
Hi fromhell,
Yes, I think it should be possible to do. Basically how it should work is to have /postprocess take few parameters - each being a separate effect so one could do something like:
/postprocess sRGB edges godrays
doing this would do all three postprocess effects in one pass.


Title: Re: GLSL
Post by: Gig on November 08, 2013, 02:08:29 am
I noticed that some current CVARs that hold more values use "/" to separate values...
Example: g_voteNames "/map_restart/nextmap/map/g_gametype/kick/clientkick/g_doWarmup/timelimit/fraglimit/shuffle"
(from DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here (http://([b)).
If "/" character is not used to identify a postprocess GLSL program (due to all postprocess programs being in the same folder), I suppose you may use the same notation. If the program path (program name including subfolder: e.g. /glsl/hitch/programname or /hitch/programname) is required/supported, instead... I suppose we cannot use the same approach.


Title: GLSL in shaders - Another possible solution
Post by: Gig on November 08, 2013, 03:58:51 am
Hitch, in the message from yesterday (http://openarena.ws/board/index.php?topic=4767.msg48875#msg48875), I forgot to mention another possible solution to problems regarding good working in both glsl and standard modes, for shader glsl effects.... the one based upon an idea from you, IIRC.
That idea was to use a distinct file to contain the "glsl" version of the shader. Now I try to guess how that may work:

One may keep main shader info in the standard .shader file: that would contain general shader properties (e.g. qer_editorimage, deformvertexes, surfaceparm, etc.) that are read by map editor, by map compiler and by the game itself (e.g. unlike some other "surfaceparms", it seems that "surfaceparm nomarks" does not require map re-compiling to be effective), AND the "stages" to be used when running the shader without GLSL. Right, a classic Q3 shader.

Then, one may add a new keyword somewhere (I would suggest before stages begin) in the main shader (using a "fake comment" workaround tor do not crash previous versions of the game), to tell the game (and the user) that there is a GLSL version of that shader available in a separate file. That may be just a keyword that mentions the existence of the GLSL version (then the game would automatically search for the same path/name of the main shader), or may also specify the name/path of the GLSL-powered shader (I don't know which of the two approaches would be better, let's think about that. Maybe the simpler one?). Examples: "//GLSL glslshader", or "//GLSL glslshader hitch/flames01", or "//GLSLshader", or "//GLSLshader hitch/flames01", or "//GLshader" or "//GLshader hitch/flames01" (just examples! One should also also consider that 0.8.8 will not understand the new keyword... what would happen?).

I'll call the GLSL-powered version of the shader "sub-shader" in the rest of this example, just for short. Except the keyword informing of the existence of the sub-shader, no other infos about GLSL rendering should be contained in the main shader.

Then, we would create a file with a specific extension (e.g. .glslshader, or .glshader, or .glsl, or .subshader, or something similar) and place it into either "/scripts" or "/glsl" folder in the filesystem (I don't know which one is better... we would have to decide one of the two). That file would contain one or more "sub-shaders" (like standard shader files do). Those sub-shaders files would be ignored by map editor/map compiler/older versions of the game, but would be considered by new versions of the game.
These sub-shaders would contain only the stages that would be used when displaying the shader in glsl mode: they would NOT contain general shader properties (deformvertexes, surfaceparms, etc.), and would NOT contain the stages used for standard mode. Hence, these sub-shaders would probably have less stages that main shaders.

As you can guess, the game, when having to render a shader, would just start from the main shader, read its general properties, read the keyword that informs it has got GLSL version (also considering it's not necessarily the last line before stages begin), and then:
- IF the user has GLSL disabled (or of it's not supported by the video card), game would continue computing the standard stages in the main shader; or
- IF the user has GLSL enabled, game would ignore the stages from the main shader, and go following the stage instructions of the sub-shader instead. Hence, the GLSL-powered shader would be shown on screen. If one of the glsl programs invoked by the sub-shader fails compiling (or if the sub-shader is not found), the game should abort operation and return to main shader, using the "standard" stages instead.

I suppose this one may be a relatively "clean" way to work, although it's quite different from the current implementation.
If you ask the reason for requiring to place a specific keyword just to tell the game the main shader has got a sub-shader (while it may theoretically auto-detect the thing due to simply finding a main shader and a sub-shader with the same name)... well the main reason is to let human beings reading the main shader know that a GLSL sub-shader for it does exist.

In case we decide to implement it, I don't know if we should force to use this "separate file" mode only, or also allowing the use a mode similar to the current one (letting the mapper decide which approach to use for each shader). Retro-compatibilty reasons would suggest to keep both systems, but I don't know how much 0.8.8 GLSL support has been actually used. I don't know. Should we inform users that 0.8.8 GLSL support is "EXPERIMENTAL" and its markup may drastically change in the next OA version?


Title: Re: GLSL
Post by: Hitchhiker on November 08, 2013, 12:09:49 pm
Thanks for the hint on multiple arguments. I didn't know that. I imagine I can add a function that transforms sRGB*edges*godrays provided to the /postprocess into something readable by the postprocessing pass. Just need to agree on the character sequence that will be the separator (I imagine any character that cannot be part of a filename on dos, linux, macos, etc. can be used).
As for the shaders. Vanilla OA does not yet use //GLSL in any of them. Some maps out there might already. I would chose to use the //GLSL keywords as they are now (I imagine someone might find it easier that way) and would use as a mainstram this patch: Hardware-specific shaders (PATCH) -> http://openarena.ws/board/index.php?topic=4570.0
What do you think?


Title: Re: GLSL
Post by: Gig on November 08, 2013, 12:46:31 pm
About other cvars that use multiple values, checking (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Auto_change_map and (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Controls it looks like that g_mappols variable uses "0\maps_dm.cfg\1\maps_tourney.cfg\3\maps_tdm.cfg\4\maps_ctf.cfg\5\maps_oneflag.cfg\6\maps_obelisk.cfg\7\maps_harvester.cfg\8\maps_elimination.cfg\9\maps_ctf.cfg\10\maps_lms.cfg\11\maps_dd.cfg\12\maps_dom.cfg\", and cg_weaponorder variable uses "/1/2/4/3/6/7/8/9/5/".
I have no idea about the reason why some of them use "\" and some others use "/"... maybe due to some error when they were created? Or maybe it is possible to use both "\" and "/" (maybe someone may check source code)??? I don't know.

About the patch you linked, could you please explain with words what it does? Thank you. Reading the first post there, I have the impression it is meant for something similar to this (http://openarena.ws/board/index.php?topic=4767.msg48889#msg48889) (additional hardware-specific shader files... working similarily to "sub-shaders" I thought, but without indication in main shader about the existence of sub-shader). But I'm not sure.


Title: Re: GLSL
Post by: fromhell on November 08, 2013, 12:58:30 pm
Actually, staring at the 3dfx for awhile, I might need more than 2 passes... probably 5:


1. Dither and reduct the image to 16bpp
2. Blend all pixels just a pixel to the right, but not the ones with contrast (to keep edges)
3. Repeat 2
4. Repeat 2
5. Repeat 2


I don't have any OpenGL game or app that I know of that can do custom multipass shaders so I can't test my theory...


Once the shader is finished it could be part of OA itself as a new extra video option, since it might have practical use in debugging assets for low end machines on high end machines, visual testing for asset developers, as well as nostalgic value, since the 3dfx 4x1 DAC filter hasn't been part of mainstream PC gaming since 1999.

Other 3dfx-based limitations include bilinear filtering (forced bilinear by q3), max texture size being 256x256, and 16-bit textures at best...


Also what about postprocessing outside the game's 3d viewport, i.e. the HUD and UI interface (including the console)?


Title: Re: GLSL
Post by: Gig on November 09, 2013, 05:39:47 am
Just to understand... isn't it possible to make a cycle directly inside the GLSL program, to cause the elaboration repeat various times? Please forgive me if I said something stupid... I'm not inside proper GLSL language features! Maybe they did not include such kind of cycles, to avoid creation of GLSL programs slowing rendering too much? I have to admit I have no idea...

About applying glsl postprocessing to HUD, IIIRC some parts of HUD are already affected... I don't know the reason why some parts are not... I mentioned this thing as "minor issue" a few posts ago.
About extending postprocess to console, too, isn't there the risk of causing console being hard to read, with some effects? Maybe Hitch may add some keyword to be specified somewhere, to let glsl postprocessing program creator decide if the program has to affect 3D world, 2D hud, command console, or combinations of some of them. Just an idea.  :)

Fromhell, what's your opinion for evolution of glsl shaders markup (and behavior) for next OA versions? To fix current limitations...



Title: Re: GLSL
Post by: Hitchhiker on February 05, 2014, 04:16:12 pm
Hi,
sorry I missed your last posts here.
The multiple postprocessing steps are limited to 6 at the moment but this can be increased. Basically each postprocess step will have to be a separate glsl source file. the entire program is assembled in memory at runtime (i.e. load init part of the shader, first fx code, second fx code, ..., final part of the shader ). I imagine a for-loop can be added like this in which case the max number of fx's will need to be increased. So in theory, r_postprocess could take an argument like 'color_LUT+for10+godrays+end_for+dither'. Though this approach is done per-pixel and only a color value of the pixel can be passed between different fx snippets so some elaborate effects might not work all that well (i.e. glow after color-correction... this because the two snippets would not know anything outside their scope.. they can just take the color of the pixel being processed and do their part on modifying the value.. anyway this is just a detail - the system should still be usable like this).

I am fighting a little with lightmap (actually since the beginning of glsl in OA) and if I manage to figure that one out then the only thing remains is lighting correctly the player models/entities (am having issues with finding/calculating their rotation in the world - is probably something very simple but is still hard for me).

Activating a GLSL pipeline in OpenGL is quite easy (once you have a program compiled) a simple glUseProgram(prog#) and everything after that, that is drawn, is drawn using that glsl program. So I imagine HUD and menus should be something that can be done. Just need to figure out where are they drawn. I'm thinking this might be in the QVM? If so, then I would need to check the QVM source and see if any opengl is mentioned there. Anyway.. to be seen. I know the background of the main menu can be drawn using glsl. So I think everything that is using Q3 shader has a good chance of working.

I think I fixed the //GLSL escape keyword (haven't tested yet but from the source seems it should work). So if vertex_shaders are off //GLSL is really a comment in the Q3 shaders. Once I've managed to finish all I'll have a look again at the patch I linked. Possibly I was mistaken.

Sorry about saying the changes would be integrated last December. I was way off.. But should not be long now.




Title: Re: GLSL
Post by: fromhell on February 06, 2014, 08:30:46 pm
BTW I made a page for my shader explaining how it works

http://leileilol.mancubus.net/shaders/


Title: Re: GLSL
Post by: fromhell on March 07, 2014, 03:03:34 pm
and now i've attempted to port it. Sorry for the Q3TA shot here

(http://leileilol.mancubus.net/crap/q3dfx.jpg)


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 (http://leileilol.mancubus.net/shaders/glsl/).


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


Title: Re: GLSL
Post by: fromhell 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

(http://leileilol.mancubus.net/crap/pc98shader.png)


Title: More about GLSL improvements...
Post by: Gig 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.


Title: Re: GLSL
Post by: fromhell 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


Title: Re: GLSL
Post by: Hitchhiker 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.


Title: Re: GLSL
Post by: Hitchhiker 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 :( ).


Title: Re: Suggestions for GLSL improvements
Post by: Hitchhiker on March 11, 2014, 05:08:06 am
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.




Title: Re: GLSL
Post by: Hitchhiker 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?)


Title: Re: More about GLSL improvements...
Post by: Hitchhiker 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.


Title: Re: GLSL
Post by: fromhell 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 :(


Title: Re: More about GLSL improvements...
Post by: Gig 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.


Title: Re: GLSL
Post by: fromhell 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


Title: Re: GLSL
Post by: Gig 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...


Title: Re: GLSL
Post by: Hitchhiker 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 :)


Title: Re: GLSL
Post by: fromhell 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


Title: Re: GLSL
Post by: Hitchhiker 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?).


Title: Re: GLSL
Post by: fromhell on March 16, 2014, 04:43:03 pm
This video should show off how PowerVR handled alpha (http://www.youtube.com/watch?v=JwLeS_KVHP4)


And then there's the Voodoo2 (http://leileilol.mancubus.net/crap/3dpages/voodoo2-additive-nearest.png) handling (http://leileilol.mancubus.net/crap/3dpages/voodoo2-alpha-nearest.png)


Title: Re: GLSL
Post by: Hitchhiker 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.



Title: Re: GLSL
Post by: fromhell 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.


Title: Re: GLSL
Post by: Hitchhiker 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.


Title: Re: GLSL
Post by: fromhell on March 27, 2014, 04:00:52 pm
This (https://www.shadertoy.com/view/XsX3DH) 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.


Title: Re: GLSL
Post by: Hitchhiker 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?


Title: Re: GLSL
Post by: fromhell 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).


Title: Re: GLSL
Post by: Hitchhiker 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.


Title: Re: GLSL
Post by: Hitchhiker 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


Title: Re: GLSL
Post by: grey matter on April 06, 2014, 04:03:44 pm
You need to push your changes to GitHub or any other origin that you've set up.


Title: Re: GLSL
Post by: Hitchhiker on April 07, 2014, 11:47:51 am
Thanks grey matter
I'm trying to make it work.


Title: Re: GLSL
Post by: Hitchhiker on April 10, 2014, 02:24:11 pm
no luck for me and the github.
If it's OK with you, I'll be posting here the modified files together with a test map and new glsl programs in it.


Title: Re: GLSL
Post by: Neon_Knight on April 10, 2014, 04:02:24 pm
Try contacting hairball or sago007.


Title: Re: GLSL
Post by: fromhell on April 10, 2014, 05:59:22 pm
You could probably do a fork and maybe I can pull it somehow.


I did bunch of changes lately to accomodate some unacceptable things in secret progress.


Title: Re: GLSL
Post by: Hitchhiker on April 11, 2014, 12:02:13 pm
Forking the engine I can upload the changes. I think I've uploaded all of the changed files. Will need to sit down and re-check everything and clean a little but this should work as is. As for the glsl programs.. seems its never done by the deadline I give myself so I hope this weekend I can send those as well..
for the engine part I need to add:
-postprocessing uniform u_SunPos (for godrays).. I have like 10 versions of OA source on my 4 hard disks so will be easier to re-write it than find :)
-postprocessing uniform u_ViewDir_Old - for motion blur effect

for the glsl programs I still need to rewrite most of them to use the normals. and do a new set of postprocessing programs because the older ones will not work in this new system. So probably need to create a new cvar - r_postprocess_multi that will load multiple post fx(s) into a single program and restore the original single postprocess program loading part.. run them in parallel.. older one taking precedence? Anyway, we can decide on this once in place..




Title: Re: GLSL
Post by: fromhell on May 18, 2014, 08:15:35 pm
I've committed an attempt at making 'fallbackShader' out of my postprocess shaders as well as the shaders themselves in renderer_oa similar to how renderergl2 does it, but I can't seem to get them included even when extern'd and put through the makefile.  Any idea what's wrong?

tr_init.c is where i'm trying to do it.


i'm trying to integrate my shaders directly into the dll/so if it doesn't find an external to load.  Which is very necessary concerning GLSL brightness....



Title: Re: GLSL
Post by: Hitchhiker on May 21, 2014, 12:35:52 pm
maybe you can paste your glsl shaders code directly in the tr_init.c? Sort of a string constant (?) and pass that to the compile/register function?

i.e.
const GLchar* vert =
"#version 120\n"
"attribute vec2 position;"
"void main()"
"{"
"    gl_Position = vec4( position, 0.0, 1.0 );"
"}"
;

If I understand correctly, you are trying to do this in case the pk3 file does not contain the correct glsl program?


Title: Re: GLSL
Post by: fromhell on May 21, 2014, 01:43:41 pm
Correct, and make it built-into the dll while allowing the glsl shaders themselves to be maintainable via Github.   I would work on the main shaders in the baseoa/glsl folder as working copies to put in the DLL for later.  Note this does not apply to map shaders like stream etc, but rather the 'important' shaders that have no reason being stuck in pak files.

Also O/T:, I did get _cel working.  I had to use va("%s_cel", name) instead in R_FindShader, and renamed the original function with a wrapper function to make it look for an available cel texture for r_anime.  


Title: Re: GLSL
Post by: SharpestTool on July 07, 2014, 02:30:17 am
To make it built into the DLL...you have to build a script to "stringify" them as c files.
I know not everyone here is a fan of MS Tools but there is a script in the MSVC directory...StringifyGLSL.vbs
It turns everything into a c file.  You add that as your externs.   Works like a charm to build under MSVC.   

BTW...tried building the engine.   Ran fine until I got to the new GLSL Shaders:  On an 8800GTS here's what it does.

Here's the dump of my config:
seta r_motionblur "1"
seta r_tvModeAspect "0"
seta r_tvMode "1"
seta r_anime "1"
seta r_retroAA "1"
seta r_leifx "1"
seta r_leiwater "1"
seta r_flaresDlight "1"
seta r_flareMethod "1"
seta r_flareQuality "1"
seta r_shadeMode "1"
seta r_ext_vertex_shader "1"

Here are the relevant lines from the crash dump:
Error:
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(52) : warning C7011: implicit cast from "int" to "float"
0(56) : warning C7549: OpenGL does not allow C style initializers
0(56) : warning C7553: OpenGL array assignments require #version 120
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(59) : warning C7011: implicit cast from "int" to "float"
0(63) : warning C7549: OpenGL does not allow C style initializers
0(63) : warning C7553: OpenGL array assignments require #version 120
0(70) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(70) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(70) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(71) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(71) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(71) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(72) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(72) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(72) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(73) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(73) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(73) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(74) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(74) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(74) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(75) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(75) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(75) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(76) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(76) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(76) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(77) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(77) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals
0(77) : warning C7502: OpenGL does not allow^3Couldn't compile fragment shader for program anime^3WARNING: uniform float u_ScreenSizeX; unrecognized in program anime_film
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program anime_film
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program anime_film
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program anime_film
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program leifx_dither
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program leifx_dither
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program leifx_dither
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program leifx_dither
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program leifx_filter
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program leifx_filter
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program leifx_filter
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program leifx_filter
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program motionblur_accum
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program motionblur_accum
^3WARNING: uniform sampler2D u_mpass1; unrecognized in program motionblur_accum
^3WARNING: uniform sampler2D u_mpass2; unrecognized in program motionblur_accum
^3WARNING: uniform sampler2D u_mpass3; unrecognized in program motionblur_accum
^3WARNING: uniform sampler2D u_mpass4; unrecognized in program motionblur_accum
^3WARNING: uniform float u_ScreenSizeX; unrecognized in program motionblur_accum
^3WARNING: uniform float u_ScreenSizeY; unrecognized in program motionblur_accum
Error:
0(21) : warning C7011: implicit cast from "int" to "float"
0(21) : warning C7549: OpenGL does not allow C style initializers
0(21) : warning C7553: OpenGL array assignments require #version 120
0(33) : error C1115: unable to find compatible overloaded function "texture2D(error, vec2)"
0(34) : error C1115: unable to find compatible overloaded function "texture2D(error, vec2)"
0(35) : error C1115: unable to find compatible overloaded function "texture2D(error, vec2)"
0(36) : error C1115: unable to find compatible overloaded function "texture2D(error, vec2)"
0(37) : warning C7011: implicit cast from "int" to "float"

^3Couldn't compile fragment shader for program motionblur_post^3Couldn't load glsl/crt_vp.glslInitializing Shaders



Title: Re: GLSL
Post by: fromhell on July 23, 2014, 03:44:27 am
A lot of those ScreenSixeX/Y's are ints being cast as floats by accident. Easily fixable


also i've tried to port cgwg and themaister's NTSC effect (https://gitorious.org/bsnes/xml-shaders/source/de81fa4fd2063ca9d4de84f05b6ad0676bccecec:shaders/OpenGL/v1.1/NTSC.shader) to OA for fun and learning, can't seem to decode the picture to a color signal however...  Replace leifx_dither/gamma with these if you want to quickly test this on the latest git engine, set r_leifx 3 after


leifx_dither.glsl/ntsc_encode.glsl
Code:
//    NTSC encoding artifact shader
//
//    This shader renders the input image with added NTSC artifacts, by
//    transforming the input into an NTSC signal, then decoding it again.
//    It was originally developed in this forum thread:
//
// http://board.byuu.org/viewtopic.php?f=10&t=1494
//
//    Copyright (C) 2010-2012 cgwg and Themaister
//
//    This program is free software; you can redistribute it and/or modify it
//    under the terms of the GNU General Public License as published by the Free
//    Software Foundation; either version 2 of the License, or (at your option)
//    any later version.
//

// Buggy porting by fromhell

uniform sampler2D u_Texture0;
varying vec2 texture_coordinate;
uniform float u_ScreenToNextPixelX;
uniform float u_ScreenToNextPixelY;
uniform int u_ScreenSizeX;
uniform int u_ScreenSizeY;
uniform float u_Time;

vec2 rubyTextureSize;
vec2 rubyInputSize;


#define TEX2D(c) texture2D(u_Texture0,(c))


#define PI 3.14159265

#define size_x 720

void main()
{
rubyTextureSize.x = 1 / u_ScreenToNextPixelX;
rubyTextureSize.y = 1 / u_ScreenToNextPixelY;
// rubyTextureSize.x = 720;
// rubyTextureSize.y = 480;
// rubyInputSize.x = 1 / u_ScreenToNextPixelX;
// rubyInputSize.y = 1 / u_ScreenToNextPixelY;
// rubyInputSize.x = 1 / u_ScreenToNextPixelX;
// rubyInputSize.y = 1 / u_ScreenToNextPixelY;

rubyInputSize.x = u_ScreenSizeX;
rubyInputSize.y = u_ScreenSizeY;


float rubyFrameCount = u_Time;

        vec2 xy =  texture_coordinate.st;

        vec2 xyp = xy * rubyTextureSize * 4.0 * PI / 3.0;
        xyp.y = xyp.y / 2.0 + 2.0 * PI / 3.0 * mod(rubyFrameCount,2);

        vec4 rgb = TEX2D(xy);

        mat3x3 rgb2yuv = mat3x3(0.299,-0.14713, 0.615,
                 0.587,-0.28886,-0.51499,
                 0.114, 0.436  ,-0.10001);

        vec3 yuv;
        yuv = rgb2yuv * rgb.rgb;

        float dx = PI/3.0;
        xyp.x = xyp.x * rubyInputSize.x/256.0;
        float c0 = yuv.x + yuv.y * sin(xyp.x+xyp.y) + yuv.z*cos(xyp.x+xyp.y);
        float c1 = yuv.x + yuv.y * sin(xyp.x+xyp.y+dx) + yuv.z * cos(xyp.x+xyp.y+dx);
        rgb = TEX2D(xy + vec2(1.0/rubyTextureSize.x * rubyInputSize.x / 512.0, 0.0));
        yuv = rgb2yuv * rgb.rgb;
        float c2 = yuv.x + yuv.y * sin(xyp.x+xyp.y+2.0*dx) + yuv.z * cos(xyp.x+xyp.y+2.0*dx);
        float c3 = yuv.x + yuv.y * sin(xyp.x+xyp.y+3.0*dx) + yuv.z * cos(xyp.x+xyp.y+3.0*dx);

        gl_FragColor = (vec4(c0,c1,c2,c3)+0.65)/2.3;
}

leifx_gamma.glsl/ntsc_decode.glsl
Code:
//    NTSC encoding artifact shader
//
//    This shader renders the input image with added NTSC artifacts, by
//    transforming the input into an NTSC signal, then decoding it again.
//    It was originally developed in this forum thread:
//
// http://board.byuu.org/viewtopic.php?f=10&t=1494
//
//    Copyright (C) 2010-2012 cgwg and Themaister
//
//    This program is free software; you can redistribute it and/or modify it
//    under the terms of the GNU General Public License as published by the Free
//    Software Foundation; either version 2 of the License, or (at your option)
//    any later version.
//


uniform sampler2D u_Texture0;
varying vec2 texture_coordinate;
uniform float u_ScreenToNextPixelX;
uniform float u_ScreenToNextPixelY;
uniform int u_ScreenSizeX;
uniform int u_ScreenSizeY;
uniform int u_ActualScreenSizeX;
uniform int u_ActualScreenSizeY;
uniform float u_Time;
vec2 rubyTextureSize;
vec2 rubyInputSize;
//uniform vec2          rubyTextureSize;
//uniform vec2          rubyInputSize;

#define TEX2D(c) texture2D(u_Texture0,(c))

#define PI 3.14159265

#define size_x 1024
#define scale_y 4

void main()
      {
//rubyTextureSize.x = ize_x / u_ScreenToNextPixelX;
// rubyTextureSize.x = 720;
// rubyTextureSize.y = 480;
rubyTextureSize.x = 720;
rubyTextureSize.y = u_ScreenSizeY;

//rubyTextureSize.x = 720;
// rubyTextureSize.y = 480;

rubyInputSize.x = 2880;
rubyInputSize.y = u_ScreenSizeY;

// rubyInputSize.x = 629;
// rubyInputSize.y = 480;
float rubyFrameCount = u_Time;
        vec2 xy =  texture_coordinate.st;
       // vec2 xy = gl_TexCoord[0].st;

          vec2 xyf = fract(xy * rubyTextureSize);
        vec2 xyp = floor(xy * rubyTextureSize)+vec2(0.5);
        xy = xyp / rubyTextureSize;
        float offs = mod(rubyFrameCount,2)/2.0;
        vec4 phases = (vec4(0.0,0.25,0.5,0.75) + vec4(xyp.x+xyp.y/2.0+offs)) *4.0*PI/3.0;
        vec4 phasesl = (vec4(0.0,0.25,0.5,0.75) + vec4(-1.0+xyp.x+xyp.y/2.0+offs)) *4.0*PI/3.0;
        vec4 phasesr = (vec4(0.0,0.25,0.5,0.75) + vec4( 1.0+xyp.x+xyp.y/2.0+offs)) *4.0*PI/3.0;
        vec4 phsin = sin(phases);
        vec4 phcos = cos(phases);
        vec4 phsinl= sin(phasesl);
        vec4 phcosl= cos(phasesl);
        vec4 phsinr= sin(phasesr);
        vec4 phcosr= cos(phasesr);
        vec4 phone = vec4(1.0);

        vec2 one = 1.0/rubyTextureSize;

        vec4 c = TEX2D(xy)*2.3-0.65;
        vec4 cl= TEX2D(xy + vec2(-one.x,0.0))*2.3-0.65;
        vec4 cr= TEX2D(xy + vec2( one.x,0.0))*2.3-0.65;

        vec3 yuva = vec3((dot(cl.zw,phone.zw)+dot(c.xyz,phone.xyz)+0.5*(cl.y+c.w))/6.0, (dot(cl.zw,phsinl.zw)+dot(c.xyz,phsin.xyz)+0.5*(cl.y*phsinl.y+c.w*phsin.w))/3.0, (dot(cl.zw,phcosl.zw)+dot(c.xyz,phcos.xyz)+0.5*(cl.y*phcosl.y+c.w*phcos.w))/3.0);

        vec3 yuvb = vec3((cl.w*phone.w+dot(c.xyzw,phone.xyzw)+0.5*(cl.z+cr.x))/6.0, (cl.w*phsinl.w+dot(c.xyzw,phsin.xyzw)+0.5*(cl.z*phsinl.z+cr.x*phsinr.x))/3.0, (cl.w*phcosl.w+dot(c.xyzw,phcos.xyzw)+0.5*(cl.z*phcosl.z+cr.x*phcosr.x))/3.0);

        vec3 yuvc = vec3((cr.x*phone.x+dot(c.xyzw,phone.xyzw)+0.5*(cl.w+cr.y))/6.0, (cr.x*phsinr.x+dot(c.xyzw,phsin.xyzw)+0.5*(cl.w*phsinl.w+cr.y*phsinr.y))/3.0, (cr.x*phcosr.x+dot(c.xyzw,phcos.xyzw)+0.5*(cl.w*phcosl.w+cr.y*phcosr.y))/3.0);

        vec3 yuvd = vec3((dot(cr.xy,phone.xy)+dot(c.yzw,phone.yzw)+0.5*(c.x+cr.z))/6.0, (dot(cr.xy,phsinr.xy)+dot(c.yzw,phsin.yzw)+0.5*(c.x*phsin.x+cr.z*phsinr.z))/3.0, (dot(cr.xy,phcosr.xy)+dot(c.yzw,phcos.yzw)+0.5*(c.x*phcos.x+cr.z*phcosr.z))/3.0);

        mat3x3 yuv2rgb = mat3x3(1.0, 1.0, 1.0,
                 0.0,-0.39465,2.03211,
                 1.13983,-0.58060,0.0);


        if (xyf.x < 0.25)
          gl_FragColor = vec4(yuv2rgb*yuva, 0.0);
        else if (xyf.x < 0.5)
          gl_FragColor = vec4(yuv2rgb*yuvb, 0.0);
        else if (xyf.x < 0.75)
          gl_FragColor = vec4(yuv2rgb*yuvc, 0.0);
        else
          gl_FragColor = vec4(yuv2rgb*yuvd, 0.0);
}


Title: Re: GLSL
Post by: Hitchhiker on July 27, 2014, 09:07:09 am
looks nice fromhell!



Title: Re: GLSL
Post by: fromhell on July 27, 2014, 09:37:54 am
It's not nice at this point :( It's supposed to be in color.

and yeah, i am having a bit of a low res fetish right now, I like sharp artwork but I also want to design OA3 for the lower resolution, and I don't like tiny windows or going fullscreen so I did r_tvMode to render the game to 640x480 and scaling that buffer up.   Adding NTSC artifacts on top of this would simulate the game on a TV played through a console system, helping me design ahead for these artifacts.

it's a convoluted asset debug feature really, but could be used for masochistic retro novelty gameplay if one wanted.


Also, sort of related, I have the colorspace conversion bleed part of the shader working (the third pass), check out the red numbers to the bottom for example.


nothing like using modern technology to make a game look older :)   Doing it the other way around is akin to polishing a turd because I can't just make a proper normal mapped game out of thin air and still expect to hit the important spec targets.


Title: Re: GLSL
Post by: Hitchhiker on August 12, 2014, 02:42:57 am
posting the multipart glsl programs. I modified the EGAfilter and BWfilter postprocessing to work with this new system. I dont think there would be much problems caused by the new system in regards to the earlier postprocessing programs ( as postprocessing programs are packed with the executable so likely the executable will have available to it the programs that it can read).

what this new system does is this:
load default vertex shader source
load initial part of the fragment shader source (definitions of uniforms, variants, define the main function and set color to black)
loop through the r_postprocess string and load each needed fragment shader source code (names of the files to load are in the r_postprocess string, separated by the '+' character) - each of these parts takes 'color' variable as input and after modifying it outputs the 'color' variable for the next part
load the final part of the fragment shader - write 'color' to the gl_FragColor
compile the shader programs

example usage:  /r_postprocess EGAfilter+BWfilter


for the engine source code, TODO: add check that the glsl postprocessing program does not exceed the buffer in size. fail the compilation if it does.

I'll try to finish this soon as it has been a while now.

also, I need advice how to proceed ... for future changes - should I clone sago007's repo, fromhell's or stick to my fork?
In back of my mind there is like a voice telling me Github was made just for that - to make collaborative work easier.. but I dont get it just yet.


Title: Re: GLSL
Post by: Gig on August 12, 2014, 06:49:03 am
(as postprocessing programs are packed with the executable so likely the executable will have available to it the programs that it can read).
IIRC, glsl postprocessing programs are packed into pk3 files. The official site allows you to download both pk3 files and executables at the same time, but that's not always the case.
Currently, it's possible to have 0.8.8 pk3s and 0.8.1 binaries, which should not be a problem, considering glsl isn't supported at all in binaries lower than 0.8.8.

If one starts to try these new glsl programs from you (done for the new post-0.8.8 implementation of glsl -currently only avalable on git as sources, I suppose-) with 0.8.8 binaries, I don't know what will happen. However, I hope it's clear enough this stuff is for testing purposes at the moment, and not to be published in production servers yet.  :)


Title: Re: GLSL
Post by: fromhell on August 12, 2014, 07:30:07 am
The Sago fork was done to attempt fixing up travis building (which libxmp regressed).  It is out of date.


Title: Re: GLSL
Post by: Hitchhiker on August 13, 2014, 07:37:21 am
Hi Gig!

Actually I think I'll add a new postprocessing cvar - r_postprocess_multi. this should keep the things simpler, will make the older programs run on the new build. So if the program was made for the 088 it will work on the new build as well. If both r_postprocess and r_postprocess_multi are specified then one can take precedence - otherwise either of the two being specified is the one that will be executed.
As for the Github.. is just one thing too many for me at the moment to learn. Even though it is probably a simple thing to manage, I dont find the energy to do it. I'll try to do it the old fashioned way- aka have my changes merged to the latest Github version and then post the source code files here on the forum.
As for the production servers.. I just want to finish the basic client glsl functionality, have it working well and give it a 1.0 version. After that, if any other development will ever come from me it will be at a time I'll be able to dedicate both energy and time to it.
These past months even if I was to find the time, I was not up for programming but that's not really something for the forum :)



Title: Re: GLSL
Post by: Hitchhiker on August 13, 2014, 01:07:19 pm
Hi fromhell,

I'm looking at tr_bloom.c and specifically on the part about uploading some 16 'motion' textures. Is this working for you? I ask as I believe 8 texture units could be taken as a limit (some older cards will not know how to handle more than 8 textures. Also, if this is done to have a motion blur effect I think there is a better way of making motion blur (I think someone mentioned doom3 effect which from how I understand it is just a modified godrays shader - I think i can make that effect and it would use the already uploaded framebuffer texture in u_Texture0).

and for Unreal type of tonemapping I would need a texture slot at postprocessing time (to upload the lookup color table)
so I would remove this part:
   if( r_motionblur->integer > 2){
   if (program->u_mpasses > -1) R_GLSL_SetUniform_u_mpasses(program, mpasses);
   GL_SelectTexture(2);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.motion1.texture );
   GL_SelectTexture(3);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.motion2.texture );
   GL_SelectTexture(4);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.motion3.texture );
   GL_SelectTexture(5);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.motion4.texture );
   GL_SelectTexture(6);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.motion5.texture );
   GL_SelectTexture(11);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.mpass1.texture );
   GL_SelectTexture(12);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.mpass1.texture );
   GL_SelectTexture(13);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.mpass1.texture );
   GL_SelectTexture(14);
   GL_State( GLS_DEPTHTEST_DISABLE | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO );
   GL_Bind( postproc.mpass1.texture );

please let me know if you agree?

Thanks!


Title: Re: GLSL
Post by: fromhell on August 13, 2014, 01:11:58 pm
It's implemented that way as I wanted that motion blur effect to work on everything by delayed rendering into five buffers and then showing the pixel shaded frame after all that, as some lazy workaround for offscreen rendering.


I also have another method by accumulation buffer which isn't as effective but doesn't use fragment shaders.


Also please, PLEASE note that tr_bloom.c is heavily reorganized and sorted into sections now and i'm gonna pause on engine updates for awhile to ease this merging process. I just hope you don't pull out the extra postprocessing option cvars i've done (like r_anime, r_tvMode, r_ntsc, r_leifx).  Some are different from just simply r_postprocessing as I have them operate on the whole context instead of only the refdef and I want to turn those into menu options later.  Granted, they don't really 'enhance' the picture, but they do help the low polyness of the assets appear less uncanny.


and finally be wary of snagging any code from Doom3 or Doom3 BFG.  Those are GPLV3+bethesda clause licensed and will conflict.  I do have a similar shader already as leifx_vgasignal which you could base off of by translating motion vectors into it, the real problem is getting those vectors since cgame would require tearing and it would be dependent on a new cgame module.


Title: Re: GLSL
Post by: Hitchhiker on August 14, 2014, 03:35:14 pm
Hi fromhell.

I've had another look and sorry for false alert, no need to remove anything. I was thinking also about a motion blur effect that could work on all cards and think is possible to do (actually it would be rotation blur so different from your effect). If I read your code I think it stores the framebuffers of different frames. If motion blur is done in glsl it will use a single framebuffer (so the effect is different from your and only visible when rotating the view). Anyway, once I get it working in glsl, it could be translated to non-glsl path but for the moment it is just an idea. Basically if one was to take the actual framebuffer and redraw it  - instead of using a single quad but by drawing the quad needed number of times and offsetting it in the correct direction each time (on the same frame) it might give an impression of motion blur (or rather rotation blur).
Anyway... if you wish, please continue working on the tr_bloom.c - not an issue, i'll let you know when I have done all I'd need to do and then I'll merge my changes to your latest version.
As for taking the source from other applications - it is not what I intend to do. I'll make the effect from scratch. I'm not sure what you mean reg. cgame but don't intend to touch it either - no worries. If you mean i.e. camera viewvector between two frames it should not require cgame changes? Need to check it..

r_postprocess still works as before. I've added r_postprocess_multipart for combining multiple effects into a single glsl program ( so this could be used to setup postprocessing using the menus where one would just click which effects one wants). Eventually this new cvar could be made internal to the renderer so it could not be configured from the console but only using the menus.


Title: Re: GLSL
Post by: special on September 03, 2014, 07:53:17 pm
the problem is the retard dickbrain asshole codding it.


Title: Re: GLSL
Post by: Hitchhiker on September 05, 2014, 10:31:49 am
I guess so.. in fact help would be appreciated  :)


Title: Re: GLSL
Post by: Hitchhiker on September 05, 2014, 10:33:58 am
actually, fromhell, if you want to upload your latest changes I can get the latest files and merge what I have so far. Let me know?


Title: Re: GLSL
Post by: fromhell on September 06, 2014, 07:24:23 am
Just pushed my latest changes which is more of a cleanup


Title: Re: GLSL
Post by: Hitchhiker on September 28, 2014, 03:59:04 pm
hi, just few minutes ago I finally managed to get everything lit correctly (!!!! :) ). So will proceed with cleaning up the mess I made on my copy of the source so merging the changes will not pickup anything that's not needed. After that I'll need to fix the glsl programs to incorporate the lighting and if this goes well I'll be ready to shoot the changed files to you. Hopefully by end of this coming week.
p.s. sorry about the late reply - only saw your last post now.



Title: Re: GLSL
Post by: fromhell on December 11, 2014, 10:51:20 am
I'm now attempting at trying to make 3dfx dither shaders for the textures, so there's the familiar artifacts of their overdraws and etc...

However I don't like how the vertex shader needs to calculate the colors, why can't I just use the CPU-calc'd colors directly for more compatibility? :(  I also notice lightmaps disappear when I use it.  I based it off the old generic_fp/vp programs

Also it's a slow shader, but that doesn't take away from its intended appeal when additive overdraw brings back a nice fps dip :)


Title: Re: GLSL
Post by: fromhell on December 11, 2014, 01:32:14 pm
...I realized I can just comment out the calc stuff and use gl_Color directly

same for the texcoord calcs, now I have lightmaps working


Title: Re: GLSL
Post by: Hitchhiker on December 17, 2014, 01:35:49 pm
hi fromhell!

I see you've been busy. I was away from OA for a while now. Back here now. Yes, the gl_color is correct (I realized that as well). Do you think I can try updating my github account so you can pull the changes?
Also, are you using the 'generic' glsl program at the moment?



Title: Re: GLSL
Post by: fromhell on December 17, 2014, 01:40:59 pm
No, i've pretty mcuh split that off into a leifxify_fp/vp shader now.  No vertex color calculations on shader since I only cared to just add dithering the textures instead


I have been way too busy in RL lately though so I haven't been working much on OA3 (RL xmasing)



Nevertheless I have been thinking of getting those generic shader programs to work again in a brute-force way to speed up the game a little as an option.  The real issue are porting those new rgbGen/alphaGen calculation functions over (new rgbGens for things like anime eyes, celshaded models and shiny models), so i'd have to leave them handled in software until then (one new calc function involves using specular for the overbright samples over a clamped lightingDiffuse)  
however vertex shader lighting is only half of the battle - another nice speedup would be from dropping unweighted bones from MDRs (my models have many of them for baked ik setups) at load and vertex shader skeletal frame interpolation.


Title: Re: GLSL
Post by: fromhell on January 12, 2015, 09:03:57 am
Experimenting with shading


I took most of the stuff from water_ glsl and actually took the tess normals as a color calc instead to get normal data to the shader system (lazy way to do it but works) leading to somewhat neat per-pixel shading

Not as smooth as Dolphin's though... but this is still a nice step closer to a generic perpixel lightingDiffuse shader idea I wanted a year ago without the regressive sacrifices that renderergl2 does.  I'll probably keep adjusting until it looks more like TF2's shader


what the shader system REALLY needs though, are FBOs - so we could have refracting effects done right and other effects


Title: Re: GLSL
Post by: fromhell on January 13, 2015, 05:59:07 am
Made even more progress. Specular and diffuse light reflect properly from the directedlight vector, and there's specular mask/hardness support, and I added a touch of 'rim lighting'


I really like how this looks too, and the normals don't look so bad either! (contrary to every time I tried renderergl2 in the past)


I'm going to make this a cvar too - r_modelshader, which when set to 1, applies this particular shader on all lightingDiffuse stages if they don't have a glsl shader already


Title: Re: GLSL
Post by: Suicizer on January 13, 2015, 12:32:50 pm
Made even more progress. Specular and diffuse light reflect properly from the directedlight vector, and there's specular mask/hardness support, and I added a touch of 'rim lighting'


I really like how this looks too, and the normals don't look so bad either! (contrary to every time I tried renderergl2 in the past)


I'm going to make this a cvar too - r_modelshader, which when set to 1, applies this particular shader on all lightingDiffuse stages if they don't have a glsl shader already

Looks nice and wet; awesome.
So, when will OA3 actually be released?


Title: Re: GLSL
Post by: Hitchhiker on January 13, 2015, 06:38:49 pm
Hi,

I've deleted the old fork and created a new one from the engine master. Added my changes (though they are not final-final - need checking what works correctly and what not.. i.e. tangents, environment texture calculation, ...). https://github.com/oahitchhiker/engine/
but might give you some ideas and show where my fork is going.
The 'generic' glsl program is changed in my version. here attached is glsl folder that I'm using at the moment (should go inside the pk3 file).

There is a working postprocessing multipart in this fork. the post effects that should be included should be called 'fxname'_post.glsl and loaded with r_postprocess_multi fx1+fx2+fx3... you can try loading one which is called 'ls' with '/r_postprocess_multi ls'

all this is work in progress mainly because the glsl programs are not implemented completely. there are probably a thing or two still in the engine source itself that will need changing (and few checks added so i.e. one could not load 20 fx parts in the multipart postprocess pipe and crash the game).

there are new glsl attributes available (normals, tangents and binormals).. few other things as well but first I'll need to clean the source and the glsl programs before moving forward to explaining each little detail.

posting here just in case anyone wants to try how it looks.

few screenshot as well:



Title: Re: GLSL
Post by: fromhell on January 13, 2015, 09:51:40 pm
What about deluxemaps being compiled into BSPS? Q3Map2 is capable of that and is used to optimize realtime lighting rendering in Darkplaces.

and FBOs? so refracting shaders and the like etc. could work?


Title: Re: GLSL
Post by: Hitchhiker on January 14, 2015, 12:46:08 pm
I think VBO would be a good addition to the renderer as well as glsl based calculations or vertex positions / colors (the later being done on the CPU at the moment) as they would increase the rendering speed - at the moment glsl path is always going to be slower I fear.
FBO.. yes, why not. But I'm sorry to say I'm not up to it at the moment (lack knowledge). Speaking of this.. I did look in the past at the deluxe maps.. never did figure out what they are :(



Title: Re: GLSL
Post by: grey matter on January 14, 2015, 12:51:57 pm
I think VBO would be a good addition to the renderer [..]
FBO.. yes, why not. But I'm sorry to say I'm not up to it at the moment (lack knowledge).
disclaimer: I know nothing about OpenGL; but the "fbo", "vbo" keywords are present in ioq3's "renderergl2". Might be worth taking a look so you don't have to re-implement everything for "renderer_oa".


Title: Re: GLSL
Post by: fromhell on January 14, 2015, 05:42:33 pm
There is some point in the rewriting in renderer_oa though - compatibility.  I'd rather have the shader stuff switchable in the same module without maintaining separate code directories. Maybe the GL2 stuff can be all stuck in #ifdef's to make a more stripped renderer_oa as an option.

Also some of the VBO stuff rgl2 has already isn't very useful for where OA3 is heading (MDR models are skeletally animated and are not vertex cached)



and i'm generally paranoid about potential license issues of renderergl2's vertex/fragment shader code given all those cited sources from other pages on the internet


Title: Re: GLSL
Post by: Hitchhiker on January 15, 2015, 04:12:09 pm
Thanks for helping, grey matter. I have seen those as well but if I recall correctly the VBO implementation there is not compatible with all the available mods/model animations (as fromhell says). FBO part might be possible to copy/adapt and keep the compatibility as, as far I can estimate, FBO would only affect the process of drawing of the pixels on the screen (as opposed to VBO(s) which are involved in preparing and dealing with the 3d objects' data - vertexes and polygons ; in renderergl2 VBOs seems do not fully support all of the Q3/OA vertex transformations).
One part of the renderergl2 that could be useful and easier to adapt (or to be used for guidelines how to do it in OA renderer) is the shadows part (at least to have those for one light source i.e. the Sun). But as light of the sun (and shadowed parts) is already calculated/included in the lightmaps - adding a second shadow would darken parts that are in the shade a little too much. But possibly the shadows generated this way could be soft ones (sort of just a hint of shading) so this darkening effect would not be that obvious..
But my first thing at the moment is to bring the glsl to a usable level. Once this is done we'll see how much interest there will be for adding new features to the renderer.
As for the glsl programs, I don't think the license will be an issue but will take care not to copy paste things that are not clearly marked as public domain, MIT or BSD - everything else I might include there will be written from scratch (not copied).




Title: Re: GLSL
Post by: fromhell on January 15, 2015, 05:45:33 pm
I wouldn't mind shadowmapping, though the shadowmap would need to be in a shader along with the lightmap somehow.  Even shadowmaps that are literally the same as the stencil shadow system (projecting shadows from lightdirection) as it is now are welcome, though maybe with a depth fix so there isn't a super stretched shadow.

FUN FACT: I contacted xTibor to free up his dither shader on Shadertoy before I could use it for my leifx shader.  His very handy ordered dither shader is now in public domain.





Title: Re: GLSL
Post by: Hitchhiker on January 19, 2015, 02:28:04 pm
Cool! Thanks to xTibor! :)

for shadowmaps.. yes, they would be added to the existing calculations - would be good as they would provide self shadowing I think and generally increase visual appeal.

at the moment I am trying to get the models (Dark) shaded using fromhell's normal maps. here two screenshots (one with strong moonlight and one with less).

also, p.s., my Github fork actually crashes if r_ext_vertex_shaders is set to 0. Should be a simple fix.. but if someone is trying to start it, make sure you have that cvar set to 1. So this is why there is no non-glsl version of Dark here for comparison :).



Title: Re: GLSL
Post by: fromhell on January 19, 2015, 04:45:41 pm
Doesn't crash for me since I stick ext_vertex_shader checks in my glsl-related functions.

btw what's up with her face and her left breast?


BTW here's my GLSL shaders so far.  There's no real normal mapping calcs in it yet and it does run slightly slower than the normal calcdiffusecolor because of the color processing on the diffuse texture to become non-working heightmaps and specmasks.  It also doesn't yet support multitexturing yet so it breaks a lot of shader'd models :(


Title: Re: GLSL
Post by: Hitchhiker on January 20, 2015, 12:05:26 pm
I'm not sure about the artifacts - possibly my tangent/normal calculations are a lil' off - will check it. I did have to invert the normal map (add - sign to its value) to have it light correctly so possibly there is something there as well. Also normal come in few flavors as well it seem (tangent space, world space, etc... at least in Blender it is possible to choose a different normal space when baking high poly to low) so possibly something there as well? I'll double check on my end and let you know what I find.

I'll also check your shaders - maybe I can help with them.


Title: Re: GLSL
Post by: fromhell on January 27, 2016, 12:18:08 pm
I have to mention all of this postprocess fun stuff doesn't work properly with super high resolutions (i.e. 2560x1440, 3200x1800, etc). Just blackscreens or crashes.

It probably needs to be a proper framebuffer object for all that to work


Title: Re: GLSL
Post by: Hitchhiker on January 28, 2016, 04:00:05 pm
how do you test with those resolutions? I'll try on my end.. I guess windowed mode?


Title: Re: GLSL
Post by: fromhell on January 28, 2016, 04:36:17 pm
virtual super resolution in crimson driver :)


Title: Re: GLSL
Post by: Hitchhiker on January 29, 2016, 12:40:56 pm
uh-oh.. virtual what? :)
ok, pls let me check ...


Title: Re: GLSL
Post by: Hitchhiker on January 31, 2016, 03:42:59 pm
Hi!
seems this is an AMD feature so I cannot test. As for crashes, I could reproduce this in windowed mode so will try to find which line of the code does that. As for blackscreens I don't see why this would happen on high res screens (possibly the texture required for the effect to work is never initialized) - another check to add to the code if is not there already. Either way it will require some debugging.
Do these errors appear with the 0.88 version or just the latest one?



Title: Re: GLSL
Post by: fromhell on January 31, 2016, 06:20:04 pm
This one (https://github.com/OpenArena/engine).