[http://sourceforge.net/p/ufoai/bugs/2484 Item 2484] imported from sourceforge.net tracker on 2013-01-28 19:35:59

This is how current trunk & all versions before, since the last shader upgrade look like on my ATI-gfx-card. I tested it on another computer with Nvidia GTX-260, there it seems to work & models are drawn correctly...
On both machines ufoconsole.log says videomem: 0, but this is not related I suppose, just FYI.
I will attach both ufoconsole logs for comparison, both computers run XPSP3.
Also attached is a screenshot which shows how current trunk looks on the ATI 5750.
===== Comments Ported from Sourceforge =====

====== mcr2010 (2010-05-05 10:53:10) ======

ATI 5750 log
====== mcr2010 (2010-05-05 10:54:54) ======

Nvidia GTX260 log
====== mcr2010 (2010-05-05 10:56:32) ======

Screenshot ATI 5750
====== arisian (2010-05-05 13:55:45) ======

Unfortunately, I don't have an ATI card to test things on, so these issues are extremely hard for me to fix, because I can't replicate them at all. Mattn has an ATI card; I think he's trying to figure out what's going on here.
====== mcr2010 (2010-05-06 13:46:41) ======

Tried Catalyst 10.4 WHQL & 10.5 Beta Driver - same result. Tested rev. 29770.
====== tlh2000 (2010-05-06 18:16:52) ======

please reupload ufoconsole log with latest revision of trunk i've added some more hardware query and output stuff. maybe some limit we exceed without knowing. we have to build in checks for the amount of color buffers e.g.
====== mcr2010 (2010-05-06 19:03:48) ======

Thanks for helping here. Attached is the ufoconsole.log.
I cannot imagine a limit being exceeded because this is the latest generation of ATI gfx-cards of the 5xxx series & this card should fully support OpenGL 3.3 & even 4.0 afaik...
The video-ram is not read out correctly - this card has 1GB GDDR5 RAM, but on the Nvidia-card, where all models are rendered correctly (now even with correct brightness ;)) it also says 0, so this cannot be the problem here, just FYI.
The difference I could make out is that the line where all the functions are listed is very long in the ATI-log whereas it breaks the lines in the Nvidia-log & the information is presented in several lines there...
====== mcr2010 (2010-05-06 19:05:31) ======

Latest Trunk UFO AI Log ATI HD 5750.
====== mcr2010 (2010-05-08 11:04:01) ======

Any ideas anyone ?
====== arisian (2010-05-09 00:36:49) ======

Try r29793 and let me know if anything changes
====== mcr2010 (2010-05-09 01:16:35) ======

Fixed. Thanks a lot.
====== tlh2000 (2010-05-09 17:47:49) ======

the bug wasn't fixed, the shaders just did not compile in that revision
====== tlh2000 (2010-05-09 17:49:13) ======

see https://sourceforge.net/tracker/?func=detail&aid=2998950&group_id=157793&atid=805242
====== mcr2010 (2010-05-09 18:21:10) ======

I do not know how to re-open tickets ?!
====== edirr (2010-05-09 21:27:51) ======

Win XP Pro SP3 and Radeon HD4870 with the latest drivers and if shaders are on, all models in battlescape are black. Just tested it.
====== mcr2010 (2010-05-10 15:29:30) ======

Maybe the attached info helps (GLEW1.5.4 Info)
====== mcr2010 (2010-05-10 15:31:16) ======

GL Extensions Info
====== mcr2010 (2010-05-10 15:32:27) ======

GL Extensions Visual Info ATI HD 5750
====== edirr (2010-05-13 15:37:47) ======

The problem is still present in revision 29887, no change. As long as shaders are on (whether with postprocessing or not), all models are black. Turn shaders off and everything is okay.
====== edirr (2010-05-13 20:35:38) ======

When testing arisian's recommendation for the geoscape issue with shader postprocessing, I noticed that despite models being black in battlescape, not quite everything is.

Loading the map "Little bungalo in forest", the soldier, alien, tree and vehicle models are totally black. Or, to be precise, ALMOST totally black, but there are some components that look like they are supposed to despite the shader problem with ATI cards.

Inside the Firebird, there are components that look correct, as well as one part of the electromagnetic rifle.

Since I'm unable to attach files here for some reason, I created a forum thread with details and a screenshot. You can view it here:

http://ufoai.ninex.info/forum/index.php?topic=4801.0

====== mcr2010 (2010-05-13 21:29:36) ======

Yes, glowmaps are working.
====== dodon (2010-05-14 07:31:58) ======

I reported this to an other thread ( http://sourceforge.net/tracker/?func=detail&aid=2998950&group_id=157793&atid=805242 was closesd as duplicate). To make shure it is not lost:

I have a Radeon HD 3450

For me the problems started with r29691. (r29690 was OK)
(Sec fault with a old driver and black models with a new one)

If i turned GLSL shaders off i got color.
As a test i reverted the change of r29691 in r29776 on my system and since
then the black models are gone.

by the way each of the files in r29691 trigges this behaviour

====== tlh2000 (2010-05-14 12:49:57) ======

they seems to have an animated glowmap on my ATI Radeon HD 3400 Series
====== tlh2000 (2010-05-14 12:50:39) ======

attached a new screenshot for another ati card test, and here is the relevant part of the logs:
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: ATI Radeon HD 3400 Series
GL_VERSION: 2.1.9016
GL_EXTENSIONS: GL_AMD_draw_buffers_blend GL_AMD_performance_monitor GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_snorm GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_meminfo GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_buffer GL_EXT_copy_texture GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_transform_feedback GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_explicit_multisample GL_NV_primitive_restart GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_WIN_swap_hint WGL_EXT_swap_control
using GL_ARB_texture_non_power_of_two
using GL_ARB_shading_language_100
GLSL Version: 1.40
using GL_ARB_framebuffer_object
max draw buffers: 8
max render buffer size: 8192
max color attachments: 8
using GL_ARB_draw_buffers
max supported lights: 8
max texture units: 8
max texture coords: 16
max vertex attributes: 16
max texture size: detected 8192
...but using 2048 as requested
Using low resolution globe textures as requested.
R_LoadProgram: 'world' loaded.
R_LoadProgram: 'warp' loaded.
R_LoadProgram: 'geoscape' loaded.
R_LoadProgram: 'combine2' loaded.
R_LoadProgram: 'convolve3' loaded.
R_LoadProgram: 'atmosphere' loaded.
R_LoadProgram: 'simple_glow' loaded.
SDL_image version 1.2.7
SDL_ttf version 2.0.9 - we need at least 2.0.7

====== mcr2010 (2010-05-16 22:02:24) ======

GREAT !
I think bayo fixed this with one of his recent changes. Top work !
This one was nerving me a lot. Setting this to pending.
====== tlh2000 (2010-05-17 06:43:40) ======

please please check whether shaders are compiling at all before closing a shader related bug.

R_LoadShader: world_vs.glsl: 0(82) : error C0000: syntax error, unexpected $undefined at token "#"
0(82) : error C0501: type name expected at token "#"
0(91) : error C1033: cast not allowed
0(91) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(91) : error C0501: type name expected at token ";"
0(93) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(93) : error C0501: type name expected at token ";"
0(97) : error C1066: invalid type in type constructor
0(97) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(97) : error C0501: type name expected at token ";"
0(98) : error C1066: invalid type in type constructor
0(98) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(98) : error C0501: type name expected at token ";"
0(99) : error C1066: invalid type in type constructor
0(99) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(99) : error C0501: type name expected at token ";"
0(101) :
R_LoadShader: world_fs.glsl: 0(34) : error C0000: syntax error, unexpected $undefined at token "#"
0(34) : error C0501: type name expected at token "#"
0(39) : error C7537: OpenGL does not allow 'varying' after a type specifier
0(40) : error C7537: OpenGL does not allow 'varying' after a type specifier
0(44) : error C0000: syntax error, unexpected identifier, expecting '(' at token "lightSource"
0(44) : error C0501: type name expected at token "lightSource"
0(44) : error C7537: OpenGL does not allow 'inout' after a type specifier
0(44) : error C7537: OpenGL does not allow 'inout' after a type specifier
0(46) : error C1033: cast not allowed
0(46) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(46) : error C0501: type name expected at token ";"
0(48) : error C0000: syntax error, unexpected '{', expecting ',' or ')' at token "{"
0(48) : error C0501: type name expected at token "{"
0(50) : error C0000: syntax error, unexpected ';', expecting ',' or ')' at token ";"
0(50) : error C0501: type name expected at

====== mcr2010 (2010-05-17 07:36:37) ======

I did not close it. I set it to pending ?! & set the resolution to 'works for me', because suddenly I had models rendered on the battlescape & glowmaps working with all gfx effects turned on.
But you are right. I have errors in ufoconsole.log too, seems I used the old link to the 2.3 version of ufoconsole.log, because I did not notice errors when I looked before setting this to pending.
Here are my errors, maybe this helps:
2010/05/17 09:29:19 Using high resolution globe textures as requested.
2010/05/17 09:29:19 R_LoadShader: world_vs.glsl: Vertex shader failed to compile with the following errors:
ERROR: 0:82: error(#91) Syntax error # isn't in the begin of a new line preprocessor command must not be preceded by any other statement in that line
ERROR: 0:82: error(#131) Syntax error: pre-mature EOF parse error
ERROR: error(#273) 2 compilation errors. No code generated


2010/05/17 09:29:19 R_LoadShader: world_fs.glsl: Fragment shader failed to compile with the following errors:
ERROR: 0:34: error(#91) Syntax error # isn't in the begin of a new line preprocessor command must not be preceded by any other statement in that line
ERROR: 0:34: error(#131) Syntax error: pre-mature EOF parse error
ERROR: error(#273) 2 compilation errors. No code generated

Sorry again for the mistake.
====== edirr (2010-05-21 19:27:39) ======

I'm still having problems with the black models on battlescape when shaders are on.
====== tlh2000 (2010-05-26 05:31:36) ======

should be fixed in r30155 (trunk) and r30156 (2.3-dev)

http://sourceforge.net/apps/trac/ufoai/changeset/30155
====== tlh2000 (2010-05-27 20:39:18) ======

looks like it's not yet fixed - see http://ufoai.ninex.info/forum/index.php?topic=4885.0
====== edirr (2010-05-28 06:31:55) ======

UFOAI revision 30181.

Windows XP Pro SP3 Radeon HD4870 (Catalyst Control Center 10.4)

1) With GLSL shaders (and postprocessing) enabled AND realtime lighting enabled, black models on battlescape.

2) When GLSL shaders OR realtime lighting is turned off, models become normally visible

3) When realtime lighting is turned off, geoscape is transparent

4) Thus, it is possible to use realtime lighting as the workaround, because turning it off and on does not require a restart but GLSL shaders do or geoscape gets screwed up.

Will add console log excerpt later.


====== tlh2000 (2010-06-19 06:42:04) ======

i think this was fixed, no?
====== arisian (2010-06-19 13:19:50) ======

I think so; let's set it to pending and see if anyone complains
====== edirr (2010-06-19 16:40:33) ======

Was this supposed to be fixed in the 2.4 trunk yet? Because running the latest 2.4 debug dev build, the models on battlescape are as black as ever. The same symptoms still:

Realtime lighting and GLSL shaders on at the same time, black models, turn one or the other off and everything works. Max number of dynamic lights is one, IIRC.

System is Win XP Pro SP3 with ATI Radeon HD4870 and latest drivers.
====== mcr2010 (2010-06-19 17:00:45) ======

Confirming edirrs observations.
The exactly same stuff is going on here & this bug is NOT Windows, but ATI-specific (black models on Linux Mint also).

The 2.3 release version is fortunately working, but trunk version still renders those black models. :(

I can confirm also that it must have something to do with the realtime lights as turning those off makes the models on the battlescape being rendered correctly (thanks for the tip, edirr, I did obviously not try all of the combinations, so I missed that one ;))...

Again, do not worry about 2.3, just trunk version is buggy.
====== arisian (2010-06-19 17:33:21) ======

This issue is fixed in the 2.3 release, but remains in Trunk. It will be fixed in trunk eventually, but probably not that soon, since the fix used in the 2.3 release involved disabling much of the new lighting code. I'm currently in the process of re-writing most of the lighting code to (hopefully) avoid the nVidia vs ATI issues as much as possible. At the same time, I'm adding the capability to render shadows in real-time (rather than using the static "lightmaps" that currently get built oh-so-slowly by ufo2map). If you want to check my progress, take a look at the "renderer_work" branch, which is where I'm making these changes, to prevent breaking trunk in massive ways with my intermediate versions.

In the mean time, you can always just turn off GLSL, and then all the ATI issues should go away.
====== mcr2010 (2010-08-06 11:00:40) ======

Arisian, please do something...

It is really hard for me to create art & textures without lighting, normalmapping & other features working correctly...

Please integrate @ least a minor fix to trunk, reverting the changes you made to the real time lighting rendering after 2010-04-27, ATI lighting was broken that day or in the next few days following.

Here is the link to the IRC-log, so you can maybe make out what happened:
http://colabti.org/irclogger/irclogger_log/ufoai?date=2010-04-27

I cannot tell you exactly when it broke, but I backed up the last working version & it was r29610, so even normalmapping for our models was already working on ATI hardware...

My modest & express request & strenuous appeal once again would be to please fix this nasty long-time bug for us ATI users, because it is really annoying to have a v2.4 dev version with MUCH WORSE rendering than v2.1 version from 2007 already had :((((

====== andrewusu (2010-08-26 13:10:36) ======

I find the consensus that ATI had not followed the GLSL specification highly unlikely (but possible). This looks like a GLSL version incompatibility to me. If you update to the most current revision and look at your logs: you should now see a line like this "GLSL Version: 1.30 NVIDIA via Cg compiler" that denotes the GLSL version used. This line should be just below all the GL_Extensions.

Here is a list of GLSL versions I could find: 1.1, 1.2, 1.3, 1.4, 1.5, 3.3, 4.0, 4.1
http://www.opengl.org/registry/

What works in one version doesn't necessarily work in another version. Individual cards/compilers may support more versions than the specification requires them to; but no programmer should rely on that possibility. Content gets depreciated and removed.

I can see ftransform() in one of our shaders, and thats been removed since 1.4.

See: http://www.opengl.org/wiki/Shading_languages:_GLSL#Version
Our shaders should all have this preprocessor directive; meaning we should have a set of shaders for a set of versions. Ideally this set of shaders will cover all possible versions (a set for every other specification). UFO:AI should try the higher version first, and chain down till one compiles.

I'll work on this when I get a chance. But yes, these shaders should be tested on both ATI and NVIDIA cards:
http://jegx.ozone3d.net/index.php?entry=entry070529-094845
====== andrewusu (2010-08-26 13:24:12) ======

Nevermind about compiling shaders till a version is found that works; that would be inefficient. This call will help:
glGetString( GL_SHADING_LANGUAGE_VERSION )
====== andrewusu (2010-08-28 00:23:32) ======

Also, the presence of the GL_ARB_compatibility GL_Extension indicates that removed GLSL functionality is supported with the compatibility profile. No backwards compatibility exists when using the core profile. Look at the ATI log; the compatibility profile is used, but all the removed GLSL functionality isn't available because the GL_ARB_compatibility wasn't defined by the particular implementation (ATI5750). The Nvidia log contains the GL_ARB_compatibility GL_Extension, and thus is backwards compatible with removed GLSL functionality from the version supported by the card (e.g. ftransform()). I'm not sure why "core" or "compatibility" were not printed in the Nvidia log.

Again, the solution to this is to make a set of shaders for a set of GLSL versions, each file will have a version number at the top. In UFO:AI we'll query OpenGL for the supported GLSL version(s), and use the set of shaders that are supported.

I'll work on creating a patch for trunk to get things working as fast as possible. I don't want to touch all the work going on in the renderer_work branch; there are a lot more shader files there. I'll let arisian do that as he is more intimate with that work in progress.

See:
http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts
http://developer.nvidia.com/object/opengl_driver.html#faq
====== tlh2000 (2010-08-28 06:28:58) ======

we can use the preprocessor to handle this in the shaders - see R_InitializeShader in r_program.c
====== andrewusu (2010-08-28 10:43:31) ======

>we can use the preprocessor to handle this in the shaders
I disagree. I don't see how the preprocessor can get around a version being unsupported.

Currently UFO:AI inserts the line "#version 110" at the top of every shader loaded. See line 326 of:
http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/trunk/src/client/renderer/r_program.c?revision=32014&view=markup

By locking ourselves to GLSL 1.10, we aren't utilizing new features in the language, and we are causing the shaders to not work for people in an environment that doesn't support older GLSL code. Here is a table to figure out what OpenGL version corresponds to what GLSL version(s).
This table should be read as "OpenGL X.X implementations are guaranteed to support version Y.YY of the OpenGL Shading Language.":
OpenGL | GLSL
----------------------
2.0 | 1.10
2.1 | 1.10
3.0 | 1.30 1.20 1.10
3.1 | 1.30
3.2 | 1.50 1.40
3.3 | 3.30
4.0 | 4.00
4.1 | 4.10

Here is my patch off of revision 32013:
http://pastebin.com/1tx96wxQ

And here is my commit message:
http://pastebin.com/uNUnbkwY

I have not yet gone through all the shader code to ensure it matches the corresponding version. I hope the GLSL compiler will let me compile code my environment doesn't support (my OpenGL version is 3.0, and thus supports GLSL 1.10, 1.20, and 1.30); I hope it will compile 1.40 and up even though it won't run it.
====== andrewusu (2010-08-28 11:03:18) ======

Here is the table formatted better:
http://pastebin.com/QjmRus4S

If you look at the NVidia and the ATI log, you'll see both use OpenGL 3.2. And following the table, they are both guaranteed to support versions 1.50 & 1.40 of GLSL. The reason the NVIDIA hardware works is it has the GL_ARB_compatibility extension and thus support all older versions of GLSL; while the ATI hardware doesn't.
====== andrewusu (2010-08-28 13:04:49) ======

Applying my patch will likely cause OpenGL users 3.2+ (GLSL 1.4+) compile errors with the shaders, regardless of the presence of the GL_ARB_compatibility extension. The compile errors will be very useful to me.

Hmmm. The ability to manually change the shader version would be beneficial in the menu until all versions are working. I may work on that next.
====== andrewusu (2010-08-29 04:37:46) ======

All right, I've done a bunch more. The user can select the desired GLSL version in the options. The guaranteed GLSL version is automatically selected when the cvar is initialized for the first time; but the only shader code that will compile is the v1.10 shaders!
http://i558.photobucket.com/albums/ss30/andrewusu/ufoai/32016-ShaderComboBox.jpg

I can't compile/test GLSL code above v1.30. I'll work on getting the v1.30 shaders to work next. Here is the patch off of rev32025 if you want to try it out:
http://pastebin.com/n4jeqcr9
====== mcr2010 (2010-09-11 16:34:37) ======

Thanx, andrewusu, for looking into that stuff. I will assign this bug to tlh2000=mattn, because @ the moment I cannot apply your patches to trunk, because it seems that I have no write rights for the git development version or maybe just my git stuff is not set up correctly :(((

Please continue your work, it is highly appreciated !!!

Thanx again for the effort & time you are investing here to help with this.

====== tlh2000 (2010-09-12 07:45:08) ======

@mcr: this patch is not ready for pushing into the repo yet.

i've talked to him already, afaik he works on using the preprocessor and not new shaders for every glsl version.
====== tlh2000 (2010-09-12 08:21:03) ======


====== andrewusu (2010-12-15 04:10:02) ======

Sorry for disappearing for a while.

Here is the patch:
http://pastebin.com/NFnjuamP

Currently compiling only to the GLSL v1.10 specification works solidly (provided your OpenGL implementation supports that specification). I think the shaders will compile to the GLSL v1.30 specification without errors but with a lot of warnings about stuff being deprecated. But I couldn't figure out how to Compute the MVP (Model View Projection matrix)... I'd need someone more familiar with OpenGL and computer graphics to help with that! Jump in a skirmish using that specification to see what I mean. Its a problem I'm stuck on.

This patch doesn't fix the OP's problems, but makes a framework for updating all the shader code to work for all possible GLSL versions. Once the shader code will compile for any version ( http://pastebin.com/QjmRus4S ), the OP's problem (and many more problems) should be fixed. Its a lot of work using the preprocessors {The OpenGL GLSL implementation preprocessor and UFO:AI's glsl preprocessor} to manipulate the shader code to different GLSL specifications, constants/givens/functions/keywords get deprecated/changed from version to version. And there is the occasional flake by NVidia or ATI that has to be accounted for by the developer...

I started writing some javadoc style comments in the shaders to enhance their understanding. Doxygen should now parse the base/shaders/*.glsl files.
====== tlh2000 (2010-12-15 05:41:06) ======


====== tlh2000 (2010-12-15 06:01:50) ======

thanks a lot for the patch, i hope i may propose some changes:

#ifndef glsl110

#define varying in

#endif

this should go into the preprocessor function imo.

------------

it would be cool if you could separate the comment and format changes from the code changes with a different patch. and please keep in mind that we are writing "if (something) {" and not "if (something)
{"

-------------------

the copyright header in the shaders is not needed imo



i will try to apply some of your changes to master already - but leave the real code changed out until they work properly. but i would like to separate the real fixes/changes from the noise around it - to see the important stuff when you look at the diffs

====== andrewusu (2010-12-15 08:23:02) ======

What did you mean by "this should go into the preprocessor function"? It will need to be different between fragment shader and vertex shader files if I remember right. I didn't include that chunk of code in a file if it wasn't applicable to it.

In the future I plan on using the in/out notation instead of the varying/attribute notation as the in/out notation is more intuitive. Following that change the conditional preprocessor structure you referenced will be changed to:
#ifdef glsl110
#define in varying
#endif
----
Ok. What do you mean by 'format changes'?
I was curious about that if (something) {} thing. I wasn't sure what the convention for this project was. I'll stick to that convention then.
----
Why shouldn't the copyright header be in the shaders? I read somewhere that there should be a license for every file.

I'll see what you commit then I'll go from there. I could instead make separate patches from this big patch if you want; I admit a lot of stuff is changed.
====== tlh2000 (2010-12-15 19:57:34) ======

i also noticed that the glsl preprocessor has __VERSION__ set - maybe we should use that one?

to be honest i would like to remove the copyright headers from every source file, too - it's noise. the whole code is gpl - so why spread that info over all source files. it's not needed for the shaders (and i'll think about the *.c/*.cpp files)

the preprossor stuff for the fragment and vertex shader must of course be different, but we know which shader type we are loading, so we can add a switch to our preprocessing function and either include the in or out)

varying and attribute is still needed - it can't be replaced completely, no? i mean, mark variables as attributes has also a performance gain over marking it as varying in the situation where the variable changes a lot. i don't see how we can remove them, as something varying is needed, because we share the variable (or has something changed here in latest glsl version?)
====== tlh2000 (2010-12-15 19:59:46) ======

oh, yes - missed the answer for small patches:

yes, it would be cool if you could make small patches with speaking commit comments - also please attach them here directly instead of pastbining them (pastebin might screw the whitespaces)

also please make sure that you've activated our pre commit hook script from contrib/git
====== andrewusu (2010-12-17 09:45:04) ======

I don't think I have the privileges to attach files here; I don't see any way to.

Here is a patch that causes doxygen to document the shaders: http://pastebin.com/download.php?i=Au0YnTk3

From my understanding the web viewer of pastbin modifies things (tabs become spaces), but if you download it directly nothing is modified.

All right that pre-commit script from contrib/git is activated in my client.

No, using __VERSION__ in a comparison is slower than using the current methodology. i.e. if(__VERSION__ > 110) is slower than #ifndef glsl110 The decision making moved from run time to compile time is a good thing; these shaders run gazillions of times on the GPU.

I still stand with the current methodology of having the special preprocessor conditional structures handling the glsl110 notation of attribute/varying inside the files, rather than inserting the preprocessor conditional structures procedurally.

The GLSL 1.10 spec uses attribute/varying modifiers to denote what is going in and out of the shader. The GLSL specs beyond that use in/out modifiers. It was a change in the language; there shouldn't be any change in performance. The in/out notation is VERY intuitive as you are stating what is going in and/or out of the shader. The attribute/varying notation is more complicated as their meanings depend on the type of shader you are using {vertex, fragment}. That is why I will change the files to use the in/out notation and use the preprocessor to handle the special case (the GLSL 1.10 spec); the code will be easier to read.
====== tlh2000 (2010-12-17 15:11:27) ======

of course not runtime checks - but #ifeq __VERSION 110

the preprocessor should be able to handle this.
====== tlh2000 (2010-12-17 21:24:12) ======

your small patch about doxygen is applied now.
====== andrewusu (2010-12-18 08:35:58) ======

Here are 2 patches in one .patch file that add a cvar called r_glsl_version & an associated listbox in the video options:
http://pastebin.com/download.php?i=FDM6f8r7

Sorry about that 2nd patch, it was the easiest way to get rid of that false comment.

Next I'll make a patch that changes the remaining non-shader code, then a patch that changes the shader code.

#ifeq isn't defined in the GLSL 1.10 spec; even if it is defined in the other GLSL specs or in our own shader preprocessor it wouldn't match our requirements.
====== andrewusu (2010-12-18 09:54:29) ======

Here is the patch that modifies our preprocessor:
http://pastebin.com/download.php?i=RwBiQi9B
====== andrewusu (2010-12-18 10:37:43) ======

Here is the patch that adds a file javadoc comment block to every shader and fixes existing comments:
http://pastebin.com/download.php?i=VXE3SUuW

There are still a few patches to go to catch up to that big patch you wanted me to split up.
====== tlh2000 (2010-12-18 13:36:07) ======

thanks a lot - they are applied now
====== tlh2000 (2010-12-18 13:50:51) ======

the black model bug should be fixed now in master

see http://ufoai.git.sourceforge.net/git/gitweb.cgi?p=ufoai/ufoai;a=commit;h=1459134a996f25149b6bc50dc9fd0798c7c734cb

maybe we should close this ticket and open a new one?
====== tlh2000 (2010-12-18 13:51:39) ======

noticed a problem with your patch(es) - max supported glsl version 3.30 but the cvar was set to 4,0 (initially)
====== tlh2000 (2010-12-18 13:54:41) ======

remaining ati only issues:

the dynamic lighting only works on meshes, not on brushes
the glowmaps are not working when dynamic lighting is activated
====== tlh2000 (2010-12-18 18:36:06) ======

should we maybe set the default to 1.10 until everything is fixed? because otherwise the shaders won't work for anyone right now, no?
====== andrewusu (2010-12-18 22:07:22) ======

Correct :-) I didn't think of that. I'll write something to set the default to 1.10 now.

Hmmm, I wonder where 4,0 came from if 3.30 was in the glGetString(GL_SHADING_LANGUAGE_VERSION) string? I guess I used sscanf formatting improperly somewhere. On a different but related note I may need to pad the minor version to 2 digits in certain places, as 4.00 would be desired over 4.0
====== andrewusu (2010-12-18 22:22:28) ======

All right, here it is:
http://pastebin.com/download.php?i=0ZxEA7tS
====== tlh2000 (2010-12-19 07:10:51) ======

applied - thanks
====== andrewusu (2010-12-19 19:57:35) ======

Heres a patch that gets rid of all the warnings/errors associated with storage qualifiers when compiling the shaders beyond GLSL 1.10:
http://pastebin.com/download.php?i=Rp47chw2
====== tlh2000 (2010-12-19 20:04:24) ======

applied to master - thanks
====== mcr2010 (2010-12-30 18:56:14) ======

The main problem here was that r_dynamic_lights were turned off.
I set this bug report to pending because we do not have models rendered black on ATI cards anymore...

====== sf-robot (2011-01-13 19:20:04) ======

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).