OpenArena Message Boards

OpenArena Contributions => Development => Topic started by: Hitchhiker on October 22, 2011, 10:28:58 am



Title: ZEQ2
Post by: Hitchhiker on October 22, 2011, 10:28:58 am
Hi,

seems there is a game using ioQuake3 engine with GLSL support -> http://www.youtube.com/watch?v=0W7YjdrbyqE (http://www.youtube.com/watch?v=0W7YjdrbyqE) it seems the cell shaders work well and if the entire implemetation of GLSL is not buggy, there is no reason for other glsl shaders not to work.
More info here -> http://zeq2.com/lite/forums/viewtopic.php?t=1284&highlight=glsl (http://zeq2.com/lite/forums/viewtopic.php?t=1284&highlight=glsl)

I have started doing something similar (having one stage of a shader be GLSL program) with OA but am not exactly close to a working version. :)

kind regards,
Hitchhiker


Title: Re: ZEQ2
Post by: Gig on October 22, 2011, 11:20:16 am
Remembers me about the old good DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/ModCompat/Bid_For_Power]Bid for Power (http://([b)[/i] days... ^_^


Title: Re: ZEQ2
Post by: Hitchhiker on October 22, 2011, 12:08:39 pm
Hi Gig,
u mean just copy the SDL and renderer files to OA code dir and compile?
could that work?
Hitch


Title: Re: ZEQ2
Post by: Gig on October 22, 2011, 12:35:00 pm
I was not saying anything about how to resolve GLSL problems (I don't even know what GLSL is!)... I was simply saying that this ZEQ game is not the first DragonBall Z game based upon id Tech 3.
Years ago, a Q3 mod called Bid for Power (well, there were also others, I have a map from "DBQ", but I never played the DBQ mod itself, I simply found that CellGameDBQ map somewhere), was a similar concept, before they were forced to remove all references to dragonball characters and locations cause of copyright/trademark reasons!


Title: Re: ZEQ2
Post by: fromhell on October 22, 2011, 02:04:54 pm
I think the focus of this thread is all about the GLSLage, which I wouldn't mind in OA at all as long as it doesn't deprecate/regress the current GL 1.1 rendering path.

Granted, I liked and followed BFP's development back in the day and its legal rollercoaster (2000), I still think that's the best DBZ mod overall today, because Rodney is an awesome skinner.          

The illicit forks suck though and are a product of serious legal ignorance facepalm (eBFP (Final))


OA uses some Zeq2 code already BTW. The fixed specular position code is in the renderer (r_specmode 1) and it makes the models look oh so much better. It just needs proper worldspace tcGen environment now, I swear I got one coordinate mixed... want it to match the raven implementation


Title: Re: ZEQ2
Post by: Hitchhiker on October 22, 2011, 02:48:03 pm
Hi Fromhell,
thanks for making clear what the thread was about - my bad Gig, I missed some words in original post.
I think if OpenGL Shading Language support in ZEQ2 is stable, it would be easily included in OA.
But how would that work - meaning who would be doing this? Does it need to go through the ioQuake project? Otherwise if you agree, I can try the inclusion to OA..
hitchhiker


Title: Re: ZEQ2
Post by: fromhell on October 22, 2011, 02:51:50 pm
A lot of things in OA doesn't go through the ioq3 project. There's lots of rendering changes already, ioq3 would probably hate to have them.

Glad ZEQ2 reached stability on it though, because I wouldn't take a step ANYWHERE near the oft-suggested XreaL.


Title: Re: ZEQ2
Post by: Hitchhiker on October 29, 2011, 07:32:52 am
hi,
just wanted to update the post with progress made, for what is worth. i managed to move the functionality from ZEQ2 to OA. glsl programs compile and (for little i was able to test) do work. the glsl support in ZEQ2 does not implement few things that I think ioQuake3 project would consider enough not to include this code in ioQuake3.

as for how my OA now looks... i do get texturing artifacts on almost all maps - as far as i can see, these are due to multiple textures used in a single shader/stage which are then drawn using glsl default shader. i am trying to figure out why it happens.

im trying to do this in the evenings or weekend so cant tell you how long could it take to have a working version. Im hoping less than two weeks.





Title: Re: ZEQ2
Post by: Cacatoes on October 29, 2011, 07:52:12 am
This seems great Hitch, would it be easy to make a patch from it ? If it could both apply to ioq3's SVN and our OA that'd be sweet.
Maybe some screenshots of current progress ?


Title: Re: ZEQ2
Post by: Hitchhiker on November 11, 2011, 04:26:59 pm
Hi,
I'm uploading videos now.
The glsl support is ready for some testing. I can send the modified files to someone to commit to SVN but am not sure who? Basically the renderer works exactly the same as it would without the glsl support (multiple passes for multiple stages within the shader) and only uses defined glsl program for a single stage of a shader. So your shader could have multiple stages which render normally when glsl support is switched off (glsl commands in  the shader are 'ignored' if there is no glsl support or glsl rendering pipeline is disabled by a cvar) and the same shader would have its glsl stage rendered by a glsl program if the glsl was ON. In the below video the floor shader looks like this:
//=========== 117 =========
textures/base_floor/clangdark
{
  surfaceparm metalsteps
 {
    map textures/stonewall2/diffuse_stonewall.jpg
    map2 textures/stonewall2/bump2_stonewall.jpg
    map3 textures/stonewall2/normal2_stonewall.jpg
    program paralax
    vertexProgram /glsl/paralax_vp.glsl
    fragmentProgram /glsl/paralax_fp.glsl
  }
  {
    map $lightmap
    rgbgen identity
    blendFunc GL_DST_COLOR GL_ZERO
  }
}
So at the end, this could work in a transparent way for any game using ioQuake3. It will not speed up rendering - not the way it is setup now, but it does add functionality to the renderer.

I will put together a kind of tutorial on how everything is setup now (i.e. z-gpl-q3a2oa-textures-v5.pk3 now has a new folder called glsl that holds the vertex and fragment programs). Also which are the new shader stage commands (I only tested few) and how to add a program to a stage (can be seen above). I havent tried yet using the shader commands that modify the vertex positions or texture coordinates - to be tested to see if the vertex data and coordinates are passed correctly to the glsl program - they will work normally if no glsl is used.
Is probably a bad idea, but if someone wants Windows binaries of OA with glsl support, let me know and i can upload it somewhere. I say 'bad idea' because if something goes wrong .... so standard  'there is this file there.. dont know what it is, does or what to do with it..' disclaimer will apply.

anyway, probably better option I just send the modified source files in a zip to you guys?

The rendering, how it is setup now can be speeded up very slightly. Should I maybe look into that before sending you the code?

I've managed to upload a video to yt.. (yay!)
http://www.youtube.com/user/OAHitchhiker
but the quality suffered :( .... seeing this is my third attempt to get the video up, ill leave it at this for the moment..
also, with some lights the parallax mapping would be more obvious.
(the errors that appear at the beginning of the video - just saw them.. need to check the shader for Sorceress - it started as cel shader but i was unable to get it to work so it turned to simple 8-bits-per-color-channel-downgradeto-2-bits per channel kinda useless program) - again, toon shaders seem to need a light source as well.. havent figured out those yet :)

OK, this update is a quick off-the-top-of-my-head so missing details, but in general, glsl support is in place - needs testing.

Hope you can see the effects in the video.. here also a screenshot..

Let me know what you think?


Title: Re: ZEQ2
Post by: fromhell on November 11, 2011, 04:35:44 pm
You could attach the code here. I don't see any harm in that

Can't wait to play with glsl! :) what i'd most likely do is cubemap reflection shaders on the water and metal surfaces so I can at least catch up to 2004, and maybe phong-shaded models, or perhaps a more important shader: sRGB color control


By the way i've done an anime-style shading shader for Darkplaces before, but it relies on a modern deferred rendering and lighting approach to effectively work.


Title: Re: ZEQ2
Post by: Hitchhiker on November 12, 2011, 02:17:52 pm
The source files here attached. the 'glsl' folder would need to go to root of  z-gpl-q3a2oa-textures-v5.pk3 (or other place you feel is more appropriate).
Maybe something for another thread, but to do any lightning a good thing would be to have OA .bps files of a map be accompanied by a .light file that would contain all the 'light' objects from the respective .map file. then dynamic lights (explosions, etc) would be mixed with that and rendered.

I was trying to find what a sRGB color control would be - have found only some postprocessing articles - is this what you mean by sRGB cc?

Hope the source files compile... i've tried not to change anything but what was needed but maybe i've crashed some function trying to make it compile for me.. :\

p.s. if you wish to start making glsl programs, on ZEQ2 site forum there is a list of possible commands and variables (http://zeq2.com/lite/forums/viewtopic.php?t=1284&highlight=glsl)  - rgbGen lightingUniform, rgbGen lightingDynamic & tcgen cel will not work in this version (i was fighting to resolve some problems with rendering and have copied only the bare minimum.. now the problem resolved, i will add these and some optimization in the next week-two)


Title: Re: ZEQ2
Post by: fromhell on November 14, 2011, 03:19:36 am
Yeah I'm having trouble trying to integrate this into the source here (http://openarena.ws/board/index.php?topic=1933.0). For some reason it's throwing errors about BoxOnPlaneSide and g_color_table.


BTW OA won't come with those cel and parallax shaders.


Title: Re: ZEQ2
Post by: Hitchhiker on November 14, 2011, 02:38:36 pm
I'll have a look. BoxOnPlaneSide might have been tweeked so it would compile for me.. Is not part of glsl support so can be replaced/removed to correspond to original OA source..
the parallax and cel shader that are in glsl folder i've sent are just an example.. im not even sure the cell one works..


Title: Re: ZEQ2
Post by: Hitchhiker on November 14, 2011, 03:00:55 pm
ok.. the source you've sent the link of is not the one i was using.. I downloaded mine from the page on the wiki.. (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/DeveloperFAQ ... now i see its not the openarena.ws site at all :(
I'll move the changes from mine to the newer one asap...
sorry bout taking your time and the trouble ;(


Title: Re: ZEQ2
Post by: Cacatoes on November 14, 2011, 03:31:46 pm
Don't worry Hitch, access to OA code has never been very intuitive, hope it doesn't make you work much more than what you had to. ;)

Wikia.com is the official OpenArena wiki, but there are things which aren't very tidy.


Title: Re: ZEQ2
Post by: Gig on November 14, 2011, 04:25:07 pm
Hi Hitchhiker.
Every help to expand and fix the wiki is appreciated (a list of things that could be improved there is DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/WikiWorks]here (http://([b)).  :)


Title: Re: ZEQ2
Post by: Hitchhiker on November 14, 2011, 04:42:08 pm
Hi Cacatoes!
No worries! I think it took about the same time :D

Hi Gig!
I'll have a look.. :)

the updated files are here attached.. I pasted them to my clean source folder (one created from the link fromhell has kindly provided) and the make went on to create the excutable file.

If it does not work now i dont know what to do..  8)


Title: Re: ZEQ2
Post by: fromhell on November 14, 2011, 11:17:03 pm
For some reason, it renders nothing - only the cinematics.

r_ext_vertex_shader 0 renders nothing. Otherwise, it does.

Warnings I get:

Code:
CC code/renderer/tr_shade.c
code/renderer/tr_shade.c:1187:1: warning: return type defaults to 'int'
code/renderer/tr_shade.c:1346:1: warning: return type defaults to 'int'
code/renderer/tr_shade.c:1346:1: warning: function declaration isn't a prototype

code/renderer/tr_shade.c: In function 'RB_IterateStagesGeneric':
code/renderer/tr_shade.c:1402:17: warning: unused variable 'program'
code/renderer/tr_shade.c: In function 'GLSL_Clean':
code/renderer/tr_shade.c:1395:1: warning: control reaches end of non-void functi
on
code/renderer/tr_shade.c: In function 'GLSL_Feeder':
code/renderer/tr_shade.c:1343:1: warning: control reaches end of non-void functi
on
CC code/renderer/tr_shade_calc.c
CC code/renderer/tr_shader.c
code/renderer/tr_shader.c:72:23: warning: 'R_GLSL_GetProgramByHandle' defined bu
t not used
CC code/renderer/tr_shadows.c
CC code/renderer/tr_sky.c

I think the non-GLSL fallback isn't working.





Also some shader ideas:
- Reflective water, hydronex is a good test area for such thing
- Phong shading (Makehuman has a phong glsl program)
- An all-new bloom shader
- Censor shader (for implying more explicit gibbery)



Title: Re: ZEQ2
Post by: Hitchhiker on November 15, 2011, 02:23:03 pm
Hi,
i got the check in order. now it renders correctly. new files here attached.
I'll clean the code a bit so no warnings are displayed. I also just noticed that I cannot switch to vertex lit  rendering so this is something to look into.. also i tried original excutable of OA with the map I modified by adding a glsl program and it didnt work very nicely.. so you can try the glsl programming a bit.. it's back to the drawing board for me.
will keep you posted on progress.


Title: Re: ZEQ2
Post by: fromhell on November 15, 2011, 02:44:55 pm
I also just noticed that I cannot switch to vertex lit  rendering so this is something to look into..
This is intentional


Title: Re: ZEQ2
Post by: Hitchhiker on November 15, 2011, 04:57:34 pm
Oh.. thanks for the info fromhell
I've went on to modify the COM_Parser so it could detect a new keyword which will stop the new shader files from breaking the older builds of the game. The quickest solution I've found is to prefix each glsl related keyword with "//." characters so for older builds this will only be a comment and ignored while builds aware of this escape characters will skip the 3 char sequence and tokenize the reminder of the line.
Unless anyone can suggest a better way, now glsl related keywords should be written something like this:
//=========== 117 =========
textures/base_floor/clangdark
{
  surfaceparm metalsteps
 {
    map textures/stonewall2/diffuse_stonewall.jpg
    //.map2 textures/stonewall2/bump2_stonewall.jpg
    //.map3 textures/stonewall2/normal2_stonewall.jpg
    //.program paralax
    //.vertexProgram /glsl/paralax_vp.glsl
    //.fragmentProgram /glsl/paralax_fp.glsl
  }
  {
    map $lightmap
    rgbgen identity
    blendFunc GL_DST_COLOR GL_ZERO
  }
}

I've cleaned the warnings that were present. will take few days to double check everything before coming back with yet another zip file..

as for the shaders you mention fromhell, I will try to see which could be done but as i never did any of the glsl programming can't promise much. Let's see how that goes :)

cheers



Title: Re: ZEQ2
Post by: fromhell on November 15, 2011, 11:47:16 pm
It works! (The vertex shader 0 fallback)
thanks, could be 088'd


BTW, you could prototype the glsl shaders in polydraw (http://advsys.net/ken/download.htm)


Title: Re: ZEQ2
Post by: Hitchhiker on November 16, 2011, 03:39:04 pm
:) glad to hear it..
if all tests go ok, yes, would be nice if it could be included in the new version.
thanks for the link to Ken Silverman's projects - there is more than polydraw that i like on his page. :)
I think I can send you the cleaned zip file this weekend.
i had a quick look at reflections and refractions and they need the scene re-rendered and stored to opengl texture to work. I'll have a look at bloom effect and how it stores the scene - maybe could be reused atleast for reflections or give some pointers how to prepare the textures for water shader.
Thanks again and sorry about the incomplete source code earlier!


Title: Re: ZEQ2
Post by: Peter Silie on November 16, 2011, 04:25:02 pm
I didnīt followed the thread because my knowledge about glsl programs arenīt that great, but it leads me to a question:
is this a safe solution?

what happens to this lines:
1. example for existing shaders
//... (this is a valid comment)

2. example for development
//.vertexProgram /glsl/buggy_code.glsl

3. example for typo
//.evilProgram /glsl/dummy.glsl

4. example for 1337 h4x3r5
//.vertexProgram /glsl/do_something_evil_if_possible.glsl


Title: Re: ZEQ2
Post by: Hitchhiker on November 20, 2011, 11:12:51 am
Hi Peter,

in older builds these would be ignored. If glsl support added to OA they would be treated as a line that contains glsl program setup commands. with this in mind, anything after //. characters would, unless it is a valid glsl shader command, throw an error.
The escape sequence can be changed. Have you one in mind?

btw, I've not cleaned the code yet.. will do it this week. I have made changes to tr_bloom.c (as a test at this point - also needs to be cleaned and made to work in parallel with bloom and only if new cvars set - something like r_postprocessing "BWfilter" or r_postprocessing "none") to add sort of glsl postprocessing functionality. video here: http://www.youtube.com/watch?v=KxQbt7TCSWU

sorry about the delay...


Title: Re: ZEQ2
Post by: Peter Silie on November 20, 2011, 11:46:57 am
The ESC sequence sounds fine for me.
Dunno if neccessary, but maybe some kind of version information till the 1st space could be a good idea regarding future enhancements?
Example:
//.1 vertexProgram /glsl/code.glsl
//.345 vertexProgram /glsl/code.glsl

But i guess, thats overkill ;)


Title: Re: ZEQ2
Post by: fromhell on November 20, 2011, 11:02:35 pm
maybe a //GLSL instead of //.? It's unlikely existing shaders with //GLSL from the 00's (LIKE EVER) will conflict.


By the way, Sago is having trouble merging the renderer to the engine, do you want to do it? I also have new changes as well (look for r_monolightmaps)


Title: Re: ZEQ2
Post by: Hitchhiker on November 21, 2011, 12:15:34 am
//GLSL sounds good. for future enhancements I cant think of other way than adding another (new) sequence.
I'm not sure what needs doing to get the code into the engine(I thought  it would just need pasting of source files)? Please let me know and I will give it a go..


Title: Re: ZEQ2
Post by: fromhell on November 21, 2011, 01:13:28 am
The just-uploaded 23 engine sources here (http://openarena.ws/board/index.php?topic=1933.msg41181#msg41181)


I'll probably merge my envmode/specmode/monolight/flares/bloom changes afterward


Title: Re: ZEQ2
Post by: Hitchhiker on November 23, 2011, 12:50:46 pm
I can merge all together.. are your changes the ones in this post?http://openarena.ws/board/index.php?topic=4311.0


Title: Re: ZEQ2
Post by: fromhell on November 23, 2011, 04:16:18 pm
That's an old version

These are where my changes are:
A full tree (http://openarena.ws/board/index.php?topic=1933.msg41292#msg41292)


Note that neither are the new 23 engine, it's still 22. Also i'm using your last GLSL release for these changes.

I can't make diffs right now.


Title: Re: ZEQ2
Post by: Hitchhiker on November 23, 2011, 05:48:46 pm
Thanks fromhell!
I'll have a look. I'll use WinMerge to combine all the changes to the engine - should not be a problem.
btw, I've been adding depth buffer to postprocessing and it seems to work well on my configuration - to be tested on others. I've made a small glsl program that sort of detects edges and paints them black.. video: http://www.youtube.com/watch?v=g4lV5eNzJxs
Now is really time for me to put everything in place, create some documentation and upload the source.. :) will be back to you by the weekend..
Cheers!


Title: Re: ZEQ2
Post by: Hitchhiker on November 27, 2011, 12:27:52 pm
Hi,
here are the files (version 24) to add postprocessing. There is a clean 'glsl' folder included with two postprocessing programs as well as some documentation.
Hope this is OK?
Please let me know if you find any bugs with these additions and I will look into it..
Cheers



Title: Re: ZEQ2
Post by: fromhell on November 28, 2011, 12:28:13 am
Postprocess shaders only show up when they're pk3'd. Can't use them outside pk3 files


also played with glsl... (http://cloud.steampowered.com/ugc/612717879321548130/0A36ECDCE3C5332438E615A3567F1B0CD7432960/)


Title: Re: ZEQ2
Post by: Hitchhiker on November 28, 2011, 02:40:57 pm
I'm not sure how to access the shader unless they are in pack file - probably there is a function to call to load from the os filesystem? But this might be an issue, (I had a look at discussions regarding vertex lighting) as glsl programs that are outside the pack file could be made to include a sort of HDR filter that would make any shadow area of a map quite lightened.. not sure if I'm understanding the vertex light issue well? Anyway, I'll find a way to load from filesystem...i'm guessing should not take long. (btw, my OA specifies baseoa folder as search path but me placing glsl folder there was not found - I am on Windows and / and \ chars in file path might be the reason.. if you are on Linux, maybe worth a try?)
Regarding the screenshot.. is it one of glsl programs that I've sent that renders like this or was this a program you've made?

In meantime I started looking at glsl shadows.. trying to figure out how stencil shadows work (in theory and OA) in order to grab, at the right moment, scene's depth texture as rendered from the light's point.. If I'm understanding this well, this should be enough (with a small glsl program) to make realtime shadows..
Also, I saw your post about the light grid and deluxe bumpmapping.. maybe.. this possibly.. could already be done with glsl program but I haven't tried.. will try it and let you know ..


Title: Re: ZEQ2
Post by: sago007 on November 28, 2011, 03:55:41 pm
I'm not sure how to access the shader unless they are in pack file - probably there is a function to call to load from the os filesystem?
Use "+set sv_pure 0" while developing and pack it in pk3 before distributing.


Title: Re: ZEQ2
Post by: Hitchhiker on November 29, 2011, 01:03:14 pm
Cheers Sago007! didnt know that.. it does makes things easier.
in addition to sv_pure it would need this new tr_init.c that loads the postprocess program - the old one actually was testing to see if the requested program is inside the PAK file.. have commented that out..


Title: Re: ZEQ2
Post by: Hitchhiker on December 05, 2011, 02:36:45 pm
I got the entities to draw with light info and with bumpmaps.. http://www.youtube.com/watch?v=bF6nBGx_v28
(note: the bump map used on the model is a random normal map image so it does not correspond to the model well).. so this all works for OA entities but I am now trying to find how to enable this for world brushes but so far no progress
all these terms like entity, brush, world,... are completely new to me :( so I can't figure out where to look in the source to find why this would not work - if anyone can give a pointer as to should this be possible to do or which part of the source to look into (tr_backend, tr_world, .. ???) would be appreciated.
 


Title: Re: ZEQ2
Post by: fromhell on December 05, 2011, 05:21:31 pm
Remember that the game uses a lightgrid to specify lighting on models and such so be aware of that
before the lightgrid, Q and Q2 sampled from the bottom most brush lightmap pixel


Title: Re: ZEQ2
Post by: Hitchhiker on December 08, 2011, 01:14:56 pm
Thanks fromhell!
i will try that but after looking at the source for few days I think it might take a bit of time..but even  this way I think that large triangles will not be correctly lit as some of smaller light sources will not be seen by the glsl program.
today i've made a water glsl program. not the one that does the reflections or refractions - for these maybe the engine could be tweaked to auto-generate a portal on the water surface and then send the rendered portal image to glsl (again, it might be a while before I can put this in place :( )
i've made a video of how it looks.. http://www.youtube.com/watch?v=VkYgXeGeqwA (please dont mind the world geometry artifacts - i use them to understand what is illuminated when a dynamic light passes)

OA shader here looks like this:
textures/liquids/hydrowater
{

   surfaceparm nomarks
   surfaceparm trans
   surfaceparm water
   cull disable
   fogparms ( 0.215686 0.278431 0.333333 ) 1024
   {
      map textures/liquids/pool2.tga
      blendfunc filter
      tcMod scroll 0.05 0.05
   }
   {
      
      map textures/liquids/pool3d_4b2.tga
      blendfunc add
      rgbGen const ( 0.501961 0.501961 0.501961 )
      tcMod scroll -0.03 -0.06
      //GLSL map2 textures/stonewall2/normal.jpg
      //GLSL program water
      //GLSL vertexProgram glsl/water_vp.glsl
      //GLSL fragmentProgram glsl/water_fp.glsl
   }
   {
      map textures/liquids/pool3d_4b2.tga
      blendfunc add
      rgbGen const ( 0.501961 0.501961 0.501961 )
      tcGen environment
   }
   {
      map $lightmap
      blendfunc filter
      rgbGen identity
   }

}

eventually, to make the glsl water look better '//GLSL program skip' can be added to above non-glsl stages..
water glsl program here attached..


Title: Re: ZEQ2
Post by: fromhell on January 08, 2012, 02:23:17 am
hi

are you sitll working on a normalmapped model glsl shader? I wanna play with it for a bit early, see if I can get anywhere at normalmapping a character.



Title: Re: ZEQ2
Post by: Hitchhiker on January 08, 2012, 07:53:52 am
hi fromhell
i am actually trying to get the world entities lit.. the models can be made to use normal maps - all that is needed is the glsl program - I cannot recall sending the bump program? :-[
Let me put together one that works well (have to get the lighting levels right which Im still trying to do).. I'm not sure where you are timezone wise.. so hopefully this version finds you in good time.

to apply the program to a model, add these lines to the shader:
    //GLSL map2 textures/stonewall2/normal2_stonewall.jpg  (your own normal map texture goes here)
    //GLSL program bump
    //GLSL vertexProgram glsl/bump_vp.glsl
    //GLSL fragmentProgram glsl/bump_fp.glsl
    //GLSL rgbGen lightingDynamic

Please let me know what you think about this program - what to improve?


Title: Re: ZEQ2
Post by: fromhell on January 08, 2012, 09:01:40 am
Doesn't work very well especially with mirrored UVs.

Try this modified angelyss/dark with a normal map I baked in Blender from a quick sculpt


Title: Re: ZEQ2
Post by: Hitchhiker on January 08, 2012, 03:31:56 pm
thanks fromhell!
i will do this this week


Title: Re: ZEQ2
Post by: Hitchhiker on January 09, 2012, 03:51:58 pm
I'm experimenting... the skin looks almost OK - the effect is more visible in shadows.
the normal map is less visible on the clothes and armor due to the fact that the original texture already has this light detail incorporated. I will try to do some tests by making one texture from clothes/metal one using the hue values - see how that works. I've tried making the normal map more evident on the clothes/armor by making a second glsl program.
Here attached the two programs and the shader file if you wish to try.
 


Title: Re: ZEQ2
Post by: Hitchhiker on January 29, 2012, 11:55:01 am
hi,
just an update..
I'm changing the way the light info is sent to the glsl programs so instead of having single light direction per entire entity I'm working on having per-vertex light info. The later should give better results.
I've made some progress but nothing complete. I do see a strange behavior when I'm playing or specting someone - the lighting is not done. If I am free flying around the world the lighting info is sent to the glsl program. So have to figure out what is different between the two modes (this is not glsl related but something in the engine makes it so).
I have no estimate yet as to when per-vertex lighting will work, please be patient - should not be longer than month or so.

If you would need me to do something in the meantime, please let me know.



Title: Re: ZEQ2
Post by: Gig on February 20, 2012, 01:14:26 pm
Hi! I just created a section about GLSL here:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#GLSL_effects

It's just an overview about GLSL (please check and fix it where needed), anyway it would be better if you could create a proper "GLSL" article where explaining eveything in a deeper way, with istructions about how to create glsl programs and how to use them.


Title: Re: ZEQ2
Post by: fromhell on February 20, 2012, 06:27:43 pm
I noticed fullscreening a window with glsl on sends it erroring to menu in a unrecoverable  loop

I tried to implement SSAO to failure...


Title: Re: ZEQ2
Post by: Hitchhiker on February 22, 2012, 02:46:54 pm
:(
which glsl programs used? I've just tried with postprocessing one and could not get it to fail like that.. I was switching between windowed and fullscreen mode by pressing ALT+ENTER (Windows OS) and also using GUI.

if this was with ssao program (or other) that has an error, could you send me the program to test on my end?


as for per vertex lighting.. I've managed to get 32 glsl lights to work per-pixel.. so this should be quite easy to downgrade to per-vertex lighting.. but, after it all, my problem at the moment is the same as before - cant get the ambient light per world model to glsl program..  so will have to find a way to get that in place and will post the changes.



Title: Re: ZEQ2
Post by: Gig on February 23, 2012, 01:51:49 am
I haven't tried yet (discovered only yesterday how to enable vertex lighting back -disabling videoflags-)... what happens now if one enables vertex and GLSL?


Title: Re: ZEQ2
Post by: Hitchhiker on February 23, 2012, 12:45:59 pm
Hi Gig,

in short, nothing should happen.

The glsl support by itself does nothing to improve the quality of the renderer. And unless the glsl support is requested (by a shader or postprocessing module) it will change absolutely nothing. Setting the cvar itself to 1 will act as if glsl support is not present unless a shader or postprocessing module requests to use glsl.

My 'per vertex lighting' is somewhat misleading as it does not refer to OA's 'vertex (low)' or 'lightmap (normal)' lighting options - it refers to the way that glsl program is going to consider light influence when  drawing the polygons that were specified to be drawn using specific glsl program.

So setting lighting to 'vertex (low)' or 'lightmap (normal)' in OA's Setup menu makes no difference.

Hope this explanation makes sense?



Title: Re: ZEQ2
Post by: Gig on February 23, 2012, 01:00:36 pm
Perfectly. I simply wanted to be sure that would not cause crashes or bad effects (thinking that with vertex lighting some effects -e.g. the animations of teleports and accelerator pads in wrackdm17- do not work as usual).


Title: Re: ZEQ2
Post by: Gig on February 26, 2012, 05:26:44 pm
I noticed fullscreening a window with glsl on sends it erroring to menu in a unrecoverable  loop

I tried to implement SSAO to failure...
I haven't been able to reproduce this. My graphic card is an ATI and I'm using Windows XP. Can you give us more infos?

@Hitchhiker:
Considering that now the engine officially supports glsl (altough at experimental level), I suppose it would be useful to document how to create such effects. When you have some time, could you please create the
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/GLSL page on the wiki?

As a starting point, maybe you may "copy" and fix in the new page stuff from here (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#GLSL_effects (that is an overview) and then expand the page providing some examples about how to write glsl programs, how to be sure that the shader will work also without glsl, etc. Some external link to some glsl documentation maybe... etc...

Bye! :)


Title: Re: ZEQ2
Post by: GrosBedo on February 26, 2012, 06:08:43 pm
I'm not into graphical development, but this implementation is a great addition! If it works well it'll be amazing!

A question: which version of openGL will be supported (is OA limited to a specific version currently)?


Title: Re: ZEQ2
Post by: fromhell on February 26, 2012, 08:25:12 pm
GLSL is OpenGL 2.0 stuff

Without GLSL it's OpenGL 1.1 stuff



Title: Re: ZEQ2
Post by: GrosBedo on February 27, 2012, 08:11:08 am
Cool! OpenGL 2.0 ROCKS!!!

And what about OpenGL 3 and 4? Aren't they usable for OpenArena? Or is it simply more interesting to use OpenGL 2 for OpenArena?


Title: Re: ZEQ2
Post by: Hitchhiker on March 01, 2012, 02:20:42 pm
Hi,
actually the glsl implementation in OA is done using OpenGL ARB extensions. So from what I could find on the net, any OpenGL 1.4 compatible gfx card should be able to run glsl. Then, good to know   that  glsl programs also have versions and the final minimal configuration is yet to be seen (we first need to build some glsl shaders and see what version they would need).

As for the implementation working well.. I don't know - I am seeing some things in 088 that I never saw before and am wondering if it is due to glsl (like players flickering on ctf4ish map, black areas of world where texture should show in galmevish map - the pit). Maybe this is due to my config because in the reverse engineering the engine I've been modifying different cvars that usually would not be changed. I dont know what would be the best way to test the glsl implementation - short of removing any mention of the glsl related code and trying these two maps again (something I can do myself).

In the meantime, I'm battling to finish the lighting part I started and have no estimate as to when it might be done. Either way, I'll do my best to finish it as soon as possible.

Yesterday and today I was trying to get the ssao effect to work.. if you wish to fine tune it (or re-do it completely), it is here attached. As I never did it before I am not sure if this is what ssao is :)




Title: Re: ZEQ2
Post by: Neon_Knight on March 01, 2012, 02:30:27 pm
The pitch-black pit in galmevish was done to fix a problem with a previous shader. I couldn't compile the map without lighting problems. So I've ended up replacing the fog shader for black. Better that way.


Title: Re: ZEQ2
Post by: Hitchhiker on March 09, 2012, 12:52:03 pm
ok.
as for the problem on ctf4ish I originally thought was lag. but even locally I see the effect.. further playing locally on few different maps I get PING of zero... on ctf4ish (with 9 bots - ctf mode) i always see entities (bots, flag) disappear when I get on the jump pad and I get PING of 100 or so.. I've removed the ctf4ish map  bsp and aas file from the patch 088 pak file (so the older version was used from pak1-maps and the same problem does not appear on the 088 version of OA executable (the ping still gets high though)..
Can you try?





Title: Re: ZEQ2
Post by: fromhell on March 09, 2012, 08:17:05 pm
This SSAO shader's kind of interesting but it doesn't have a lot of volume and seems faceted and not round. Lots of cross patterns everywhere. There's also the problem of it showing over the additives (sort issue?)

Looks kind of interesting on OA3 models :)


Title: Re: ZEQ2
Post by: Hitchhiker on March 10, 2012, 01:43:04 am
:) yeah, it also make the screen look as if the player is carrying a torch..


Title: Re: ZEQ2
Post by: fromhell on April 01, 2012, 10:51:42 pm
OK
the shader crash seems to involve using a resolution larger than 1280x960


Title: Re: ZEQ2
Post by: Hitchhiker on April 03, 2012, 11:31:40 am
hi fromhell,
does AO crash with the same resolution when using just bloom? I'm thinking some sort of memory allocation fail might be causing this. Will test later on my end..
I've put my changes to sleep until James' renderer is up and running with OA.
I am not sure if it makes sense to keep this glsl implementation part of the OA at all since the one of James (including other rendering improvements) is a much advanced one and will benefit OA much more.
I think any lighting improvements I've made so far could eventually be added to James' renderer code (if at all needed).


Title: Re: ZEQ2
Post by: fromhell on April 03, 2012, 12:38:11 pm
Is Jmaes' renderer the OpenGL2 one used in Reaction?



Title: Re: ZEQ2
Post by: hairball on April 03, 2012, 06:01:48 pm
Is Jmaes' renderer the OpenGL2 one used in Reaction?
Yes.  Reaction 1.0 is using James' vbo patch v29 which was just released on the 21st.

I did a diff of ioquake3 r2232 + vbo29 against reaction 1.0 for the code/renderergl2 parts and the differences are very small.


Title: Re: ZEQ2
Post by: fromhell on April 03, 2012, 06:27:36 pm
Okay, good. But one thing about it irks me are the way the normal maps/specs are defined

like

Code:
shaaaaaader
{
        {
          map models/stuff/skin.tga
          rgbGen lightdiffuse
        }
        {
         stage normalmap
         map models/stuff/NORMALSTUFF.tga
         normal
        }
       {
        stage specularmap
        map models/stuff/SHINAY.tga
       }
}



I'd much prefer

Code:
shaaaaaader
{
        {
          map models/stuff/skin.tga
          map2 models/stuff/NORMALSTUFF.tga
          map3 models/stuff/SHINAY.tga
          rgbGen lightdiffuse
        }
        {
         map models/stuff/crazy.tga
         tcGen environment
         blendfunc add
        }
}

That way, I could probably stack shader programs like say 2 staged flowing water...


Title: Re: ZEQ2
Post by: Hitchhiker on April 04, 2012, 11:51:31 am
I have the same problem with postprocess - even with edges program. Also, I think to have found the error - when the depth buffer texture is allocated (!!) the size of memory requested is too high (some 9 times the needed space - instead of 16mb for depth buffer texture I am allocating 136 :o ). I'm not sure how that got there - my bad. I'll try to debug and make a fix.


Title: Re: ZEQ2
Post by: Hitchhiker on April 04, 2012, 12:26:41 pm
In fact, the stderr log mentions memory allocation failure. I've added a quick check for this case, brought back the allocation size to 16mb.. for me now works, but I can't really figure out what was wrong.. can you please test on your end?