Shader problems with ATI Radeon drivers [Solved]

[DaddyHoggy]

Although i haven't tested this, it might be as simple as changing any references to gl_TexCoord[0].st to gl_MultiTexCoord0.st in all the fragment shaders in these oxp's.
eg, change the line

Code: Select all

 
vec2 texCoord = gl_TexCoord[0].st;

to

Code: Select all

vec2 texCoord = gl_MultiTexCoord0.st;

this might work for the moment, although all these old shaders really need to be fixed up and brought to to date (they use a macro to work out the lighting calculations needed and they should be using a 'function' to do this instead, i'll have a look to see if i can sort something out by comparing these old shaders with the newer ones and transfering bits across.

Slightly off-topic,
I use neolites shaders, and they've been mentioned as those being effected, I know illumination and shinyness can be done with materials, but what about normal maps?
I only ask because if normal maps can be done with materials, I wouldn't even need shaders anymore (except for animated stuff)

I think my the very nature of what a normal map is, it has to be a shader effect doesn't it?

[JensAyton]

I know illumination and shinyness can be done with materials, but what about normal maps?

Yes.

That’s why there are two entries about normal maps in the materials documentation.

I think my the very nature of what a normal map is, it has to be a shader effect doesn't it?

Actually, no¹. But the material model is implemented using shaders. The point isn’t to avoid using shaders, the point is to avoid having to write them (although in the case of illumination and glow effects, 1.74 adds non-shader support as a bonus).

¹ Normal mapping can be implemented with the GL_ARB_texture_env_dot3 extension, but it requires significant extra work in the application and can’t be combined with standard specular lighting. This will never be supported in Oolite.

[ADCK]

Although i haven't tested this, it might be as simple as changing any references to gl_TexCoord[0].st to gl_MultiTexCoord0.st in all the fragment shaders in these oxp's.
eg, change the line

Code: Select all

 
vec2 texCoord = gl_TexCoord[0].st;

to

Code: Select all

vec2 texCoord = gl_MultiTexCoord0.st;

this might work for the moment, although all these old shaders really need to be fixed up and brought to to date (they use a macro to work out the lighting calculations needed and they should be using a 'function' to do this instead, i'll have a look to see if i can sort something out by comparing these old shaders with the newer ones and transfering bits across.

Slightly off-topic,
I use neolites shaders, and they've been mentioned as those being effected, I know illumination and shinyness can be done with materials, but what about normal maps?
I only ask because if normal maps can be done with materials, I wouldn't even need shaders anymore (except for animated stuff)

I think my the very nature of what a normal map is, it has to be a shader effect doesn't it?

Yes, but every other game that uses normal maps and can be modded, has them hard coded in one way or another, eg for oblivion/fallout3/morrowind/etc the diffuse map would be named nameofimage.png and the normal map would be nameofimage_n.png
and the game would recognise the normal map cause of _n simple as that, no coding, no fiddling around with shader files, just 2 letters.
If it was that simple in Oolite i'd be very happy, but its unlikely. So how about a dict entry for normal maps like what was done with illumination maps?

EDIT, nevermind the above, got a good answer from Ahruman

[Eric Walch]

....
I know illumination and shinyness can be done with materials, but what about normal maps?
I only ask because if normal maps can be done with materials, I wouldn't even need shaders anymore (except for animated stuff)

I think my the very nature of what a normal map is, it has to be a shader effect doesn't it?

Nope. Look in dredgers.oxp. Those ships use normal maps but don't contain any shaders.
But you need a shader capable computer to see the normal maps. When you define them in materials, Oolite does the hard work for you in using a default shader, if possible on the hardware.

[ADCK]

Normal mapping can be implemented with the GL_ARB_texture_env_dot3 extension, but it requires significant extra work in the application and can’t be combined with standard specular lighting. This will never be supported in Oolite.

Eh, guess this means I have to use shaders since I want both normal maps and specular, oh well
Or am i misunderstanding?

[JensAyton]

Normal mapping can be implemented with the GL_ARB_texture_env_dot3 extension, but it requires significant extra work in the application and can’t be combined with standard specular lighting. This will never be supported in Oolite.

Eh, guess this means I have to use shaders since I want both normal maps and specular, oh well :(

Er, no. That bit was about what Oolite doesn’t do, but is possible.

[ADCK]

Normal mapping can be implemented with the GL_ARB_texture_env_dot3 extension, but it requires significant extra work in the application and can’t be combined with standard specular lighting. This will never be supported in Oolite.

Eh, guess this means I have to use shaders since I want both normal maps and specular, oh well

Er, no. That bit was about what Oolite doesn’t do, but is possible.

So I can use normal/illumination/specular maps at the same time in materials and have them work? are there any drawbacks to doing it this way than instead of using shaders? less quality etc?

[JensAyton]

So I can use normal/illumination/specular maps at the same time in materials and have them work?

Yes.

are there any drawbacks to doing it this way than instead of using shaders? less quality etc?

No, because you are using shaders. You’re just not having to write them.

[ADCK]

So I can use normal/illumination/specular maps at the same time in materials and have them work?

Yes.

are there any drawbacks to doing it this way than instead of using shaders? less quality etc?

No, because you are using shaders. You’re just not having to write them.

Much coolness indeed.

I'll probably still end up using custom shaders anyway for things like animated billboards on my Bulk Haulers etc, but at least now I know that most of my oxps don't really need custom shaders.

[ADCK]

Anyway, back on topic.

I don't suppose anyone has an updated version of the standard neolites shaders that fixes the problem this thread addresses?

I wouldn't know what to do to fix them myself, never understood the coding of shaders hehe.

Plus it's not something I can test, as I dont use ATI, and therefore dont have this problem

[Cody]

for all the effort and suffering you put yourself through,

Oh, the slings and arrows of outrageous fortune...

I dragged myself away from the game tonight, and spent a pleasant couple of hours digitising some old vinyl.

[Kaks]

...a pleasant couple of hours digitising some old vinyl.

I just read 'digesting some old vinyl'! Sometimes I wonder what's wrong with me!

[ADCK]

...a pleasant couple of hours digitising some old vinyl.

I just read 'digesting some old vinyl'! Sometimes I wonder what's wrong with me!

Me too lol

mmm... Vinyl *nom nom nom*



That needs to be converted into a YAH ad

[Cody]

'digesting some old vinyl'

Nothing wrong with a bit of shellac in the diet!

[Palmski]

Although i haven't tested this, it might be as simple as changing any references to gl_TexCoord[0].st to gl_MultiTexCoord0.st in all the fragment shaders in these oxp's.
eg, change the line

Code: Select all

 
vec2 texCoord = gl_TexCoord[0].st;

to

Code: Select all

vec2 texCoord = gl_MultiTexCoord0.st;

this might work for the moment, although all these old shaders really need to be fixed up and brought to to date (they use a macro to work out the lighting calculations needed and they should be using a 'function' to do this instead, i'll have a look to see if i can sort something out by comparing these old shaders with the newer ones and transfering bits across.

Just tested this with the constores and a shady bar and they look infinitely better (click links for the screenies).

However I'm also getting lots of errors in the logs, for example:

Code: Select all

[shader.compile.fragment.failure]: ***** GLSL fragment shader compilation failed for yah_griff_station_hull.fragment:
>>>>> GLSL log:
Fragment shader failed to compile with the following errors:
ERROR: 1:73: error(#143) Undeclared identifier gl_MultiTexCoord0
WARNING: 1:73: warning(#153) Field selection requires structure, vector, or matrix on left hand side st
ERROR: 1:73: error(#216) Vector field selection out of range 'st'
ERROR: 1:73: error(#160) Cannot convert from 'float' to 'highp 2-component vector of float'
ERROR: error(#273) 3 compilation errors.  No code generated

Clearly something isn't quite right and I imagine I'm seeing the version without shaders as a result. I'm happy enough with the results but if you want me to continue with trying to fix this I'll happily implement and test any suggestions.

Fragment of code from the yah_griff_station_hull.fragment file, it looks to me as though I've made the suggested change correctly:

Code: Select all

   void main(void)
   {
   vec4 diffuse = vec4(0.0), specular = vec4(0.0);
   vec3 eyeVector = normalize(-v_pos);
 
// Load texture data
   vec2 texCoord = gl_MultiTexCoord0.st;
   vec4 diffuseMap = texture2D(tex0, texCoord);
   
// calculate specular effects