wraitii

I forgot a ";" on the line before.

Dithering is sort of what the game uses right now, though not completely. The thing is that using 64x64 texture for that, like it does now, is a bit too small for proper blending of some textures (such as sand->grass, wet->dry). The game actually uses a full square to blend a texture, using on of 16 (I think) textures.

Nah, I actually called "sundir", and I had forgot to initialize this variable, so the sun direction never changed and was completely buggy. It's fixed. I've committed an update to the waterShader branch: the size of waves is now scaling with the waviness parameter, so with low waviness you'll get an even better feeling of "little wind".

Got it, I was normalizing the EyeDir vector too soon (in the vertex program) and it resulted in the slanting. I commited the changes. I've also changed the shader slightly to use only 7 texCoord and not 8 (changes nothing for most people, I guess).

That's fairly weird... Looks like some problem with the eyedir or the move parameters. I'll see if I can reproduce. BTW, I'd recommend using this texture for the normal: it has no black pixels (the alpha channel is [1-255], as having alpha = 0 means a black pixel), so the lighting is less weird and the parallax too on the rooftiles (see Myconid screenshot for weird lighting). Edit: yeah, I'm getting the slanting too... Even when I use the loops and stuffs, so it must be somewhere in the calculations.

Could you try first loading test.pmp and then adding the temple? I get the same crash, and I'm not sure what's causing it (I also get it in GLSL, so it should come from something else).

Isn't it 7? Looking here, it appears to be, so it shouldn't crash.

Mh. Then that shader shouldn't crash. What do you have for "MAX_TEXTURE_IMAGE_UNITS_ARB"? To debug, you might try changing that line to a lower number, such as "5". It will perhaps crash, but it should crash somewhere else.

Yeah, hadn't thought of that. Let's roll differently. Go to HWDetect.cpp, and change this #define INTEGER(id) do { \ GLint i = -1; \ glGetIntegerv(GL_##id, &i); \ if (ogl_SquelchError(GL_INVALID_ENUM)) \ scriptInterface.SetProperty(settings.get(), "GL_" #id, errstr); \ else \ scriptInterface.SetProperty(settings.get(), "GL_" #id, i); \ } while (false) to this #define INTEGER(id) do { \ GLint i = -1; \ glGetIntegerv(GL_##id, &i); \ if (ogl_SquelchError(GL_INVALID_ENUM)) \ scriptInterface.SetProperty(settings.get(), "GL_" #id, errstr); \ else \ scriptInterface.SetProperty(settings.get(), "GL_" #id, i); \ std::cout << #id << ":" << i << std::endl; \ } while (false) Then when you start the game you'll have (in the console) MAX_TEXTURE_COORDS_ARB: ... (along with a lot of other info). I might be able to cram info to reduce the number of texture coords I use, but I'm afraid I won't be able to change that much.

That won't help much actually... I need to know the value of "GL_MAX_TEXTURE_COORDS" for you graphic card (on mine, its height, which is fairly standard, but if you have an Intel Card, it may be way lower.) If you can compile 0 A.D., you can add an std::cout << glGet(GL_MAX_TEXTURE_COORDS) << std::endl; I can also access it from some headers in my openGL framework, so you might be able to do a search for 'GL_MAX_TEXTURE_COORDS' and get the info.

What's your graphic card? There might be a limitation on the number of texture coordinate that it can pass... Otherwise I dunno what could cause this.

Well, then, I don't understand why it would be wrong (mathematically, I mean) to multiply the normals using: vec3 normal = ((instancingTransform) * vec4(a_normal,0.0)).rgb; instead of vec3 normal = mat3(instancingTransform) * a_normal; (which is what you, with success, used) And while the second one doesn't work on my computer, the first does, for some reason, so I'd rather both be correct. (Same with the tangents using that: vec4 tangent = vec4(((instancingTransform) * vec4(a_tangent.xyz,0.0)).rgb, a_tangent.w); ). I've pushed the ARB parallax shader (here), in a version that doesn't require the extension (commented that code). Could anybody report if it works?

Well, no. I multiply the unmodified instancingMatrix with a_normal, and the normals that come out are right, and parallax works properly and everything. Didn't notice those operators, thanks.

Thing is, I'm pretty sure I can't even do this sort of small checks without the extension (IF doesn't exist in basic ARB)... In which case, I might just as well use it. But then I need a way to check that the computer has the extension, or deactivate parallax mapping (else it'd crash). By correct, you mean that the other parameters are still important or not?

Yeah, that's the most logical answer. BTW, using my loops and if implementations, I have managed to get parallax running with the ARB shader, using the same wrong mathematic as in the GLSL shader. I'm not sure how to unroll the loop, however, if I want to not use the Nvidia only extension. Edit: well I think it's the same hack anyway... Lemme get the maths straight for a second: InstancingTransform is a 4x4 matrix. The top left 3x3 matrix is the rotation matrix, right? That's what we want to use to create the normal matrix, right? If I understood this all correctly, the normal matrix is the transpose of the inverse of InstancingTransform. However, since the 3x3 matrix is a rotation, it's orthogonal, and thus inverse = transpose. Thus, the normal matrix would be the instancingTransform, right? Or are the other parameters important still?

From a clean download of your modelMapping branch, I can confirm that parallax only works when using the fix I put 3/4 posts higher. I wonder if it comes from my computer or if I for some reason get a wrong matrix.

I should probably redownload your fork and start over, to be sure. That or OS X GLSL implementation is really messed up. Anyway, I should have just commited a fix for the GLSL version of the water shader.

I must stop editing, as you can't read everything I posted ... The black lines actually come from the AO. I thin the AO textures uses another UV set, and i'm not completely sure it works... Removing that and adapting the texture, I have everything working properly. If you try it and it works too, I think it'd be the best solution.

Well, if it does, it's quite well camouflaged. It seems to me like it's working on any part of the terrain, on any rotation. It doesn't mess up buildings that use these textures. Shadows, specular, diffuse lighting and parallax are working (I'd upload a picture but my internet is messy right now). I have no idea why it works, but it works.

I dunno, it seems to work really well using this vec3 normal; normal = ((instancingTransform) * vec4(a_normal, 0.0)).rgb; //vec3 normal = nm * a_normal; #if (USE_NORMAL_MAP || USE_PARALLAX_MAP) vec4 tangent = vec4(((instancingTransform) * vec4(a_tangent.xyz, 0.0)).rgb, a_tangent.w); I do have weird black lines. Edit: lines caused by the AO, actually. The UV sets are not working as intended, I think.

Nah, it just looks wrong. Seriously wrong, but using "crashes" was more of a metaphor than literal statement. Though I do get segmentation faults by using the GLSL shaders and adding the temple to the map if I haven't priorly loaded a map, which is kind of weird. I'll try by manually multiplying the two. Interestingly, I also get the blinking effect if I set the normal to be any component of "mat3(InstancingTransform)". And it does not blink if I set my normal to be (instancingTransform * vec4(a_normal, 0.0)).rgb; Though the the effect is completely messed up. I'll try also changing the tangents/everything. Edit: looks like that one works, but for a weird stretching effect over some textures... I'll look into it.

I've read about some "scaling" stuffs... Is there no problem with that? I've also found out about "gl_NormalMatrix" but it seems kind of unreliable (makes the normals change when I rotate the camera, I have no idea wether this is normal or not.) Edit: anyway, it still crashes with InstancingTransform, which is probably not normal.

Looks like OS X doesn't support GLSL versions higher than 1.2... I'd have to inverse the matrix by hand then.

I'll try that. I have no idea what the instancing matrix is... On the ARB shader, the calculations works and the normals don't look completely wrong, but they might be. I also have the modelview matrix accessible, I'll try and compare the two.

Yeah, I realized that later, but I posted too early in excitement. So yes, I believe my problem is with the instancing matrix. Only it seems to work for the position.