myconid

Can you put up a few more screenshots/info showing your problem? It's really hard to diagnose an issue without any info at all. Another thing you can try is to make sure you're definitely within colour bounds when drawing out the normals, using something like this: gl_FragColor.rgb = abs(normalize(v_normal)); You may also want to try passing another "varying" from the vertex to the fragment shader with the uninstanced a_normal vector, just in case something is overflowing during the matrix multiplication.

Right. So, every ship has a low-resolution texture attached to it (meaning a quad). The texture sits exactly on top of the water surface. The texture moves with the ship and contains the waves being generated by that ship, without perspective (it may be prerendered or whatever). More detail may be concentrated around the centre of the texture. This texture is not rendered to the screen. Instead, it's rendered, in perspective, to a separate screen-sized buffer. The way that waves interact is handled while rendering to the buffer (it's probably enough to use addition or multiplication of the waves). Then, while rendering the water, the normal and refraction amount of each pixel is changed by the corresponding value in the buffer. This should give an effect similar to Red Alert 3.

You mean something like a decal on the water surface? Yeah, that's definitely the simplest answer.

We could use a small, stretched texture... don't know how good it'd look, though. Considering that the terrain heightmap is like 256x256 for a pretty big map, I think a 1024x1024 texture would look pretty decent, especially considering any stretching artifacts would be hidden under the moving watermaps... However, I should add that we will need to calculate the waves on the GPU, to avoid massive memory transfers.

Added AO: https://github.com/myconid/0ad/commit/3adb94e7c3967a7bd5ba77d4800e75085c672827 quantumstate, I think we could definitely do that effect on a per-pixel basis! That is, we could perturb the fragment normals so the specularity gives the illusion of waves, without actually moving any geometry.

Compiled. I can confirm the bug and the fix. Looks good! Modelmapping branch: ERROR: Failed to compile fragment program 'shaders/arb/model_common.fp' (line 94): line 94: unexpected token This works: TEMP prod; MUL prod, v_bitangent, -sign; TEMP tbn0; TEMP tbn1; TEMP tbn2; MOV tbn0.x, tangent.x; MOV tbn0.y, prod.x; MOV tbn0.z, normal.x; MOV tbn1.x, tangent.y; MOV tbn1.y, prod.y; MOV tbn1.z, normal.y; MOV tbn2.x, tangent.z; MOV tbn2.y, prod.z; MOV tbn2.z, normal.z; // vec3 ntex = texture2D(normTex, coord).rgb * 2.0 - 1.0; TEMP ntex; TEX ntex, v_tex, texture[4], 2D; MAD ntex, ntex, 2.0, -1.0; // normal = normalize(ntex * tbn); DP3 normal.x, ntex, tbn0; DP3 normal.y, ntex, tbn1; DP3 normal.z, ntex, tbn2; // Normalization.

8x for low quality, 16x for high quality. Variables can become constants to avoid conditionals.

If preferGLSL is false and you're using the Shader path, you're definitely using ARB shaders. Mess up the GLSL shaders, run the game, if you don't get an error...

The terrain shaders/renderer aren't finalised yet, so maybe you want to hold off on the terrain shader conversion (I'm hoping to get it done over the weekend). Okay, let me know if you need any help. Sounds like a regression bug in Alpha 7. Maybe we could see what changed... This reminds me, some people are still having issues with the blinking shadowmap. I'd advise against that, as that's an Nvidia-only extension! Imho, loop unrolling is the safest way to do it, and maybe we can add preprocessor macros to scale the parallax quality... wraitii, you still have a problem with GLSL, don't you? We should really figure out what's causing it.

Seems like a definite improvement, well done! I'll test it when I get home. wraitii, technically that's a feature request, not a bugfix. None of the shadowmapping-related stuff is passed into the water shader right now. If you want to try that, you first need to change the terrain renderer code to pass in the shadowmap and shadow transform, and then you need to add code to the shader to actually calculate the shadows. You can have a shot at it, or I might try it later. Yes.

Woah, careful. Why is your diff looking like this? Did you mangle the line endings?

Assuming you want to remove the messy bits, first go to github and find my repo, fork it and pull the modelmapping branch, copy over the files you are sure you want to change from whatever you are currently using, stage them, commit, push them to github and then initiate a pull request. This will let me merge them with my modelmapping branch. You may want to keep the water-related and model-related code changes separate, so see if you can create a new branch (from the master branch) for the water.

Nice work. A low-quality parallax could be done with manual loop unrolling (basically by duplicating the code for each loop). If you push your work to github I'll test it, if you want.

That looks wrong. The normals should always face in the direction of the surface, so that should probably be all green. There used to be an optimisation somewhere in there, though it got taken out and you're left with bits and pieces. Because of this, you can remove the transpose, if you change the following matrix multiplication to have the matrix on the left. ie: mat3 tbn = mat3(v_tangent.xyz, v_bitangent * -sign, v_normal); ... normal = normalize(tbn * ntex);

Well, if you are going to hardcode it like that, you might as well use this: void CShaderProgramARB::VertexAttribPointer(const char* id, GLint size, GLenum type, GLboolean normalized, GLsizei stride, void* pointer) { TexCoordPointer(GL_TEXTURE1, size, type, stride, pointer); } because you can't trust the colour interpolation to always be very accurate.

It's the address of the first tangent of the first vertex in memory and it's passed in from the renderer. You don't need to change that in any way, it's the same as with glVertexAttribPointerARB. Looking at the code now, you probably want to call this function CShaderProgram::TexCoordPointer(GLenum texture, GLint size, GLenum type, GLsizei stride, void* pointer) from CShaderProgramARB::VertexAttribPointer. The size, type, stride and pointer are passed unchanged. You'll need to figure out how to get a value for the "texture" parameter, though.

Yeah, the heightmap in the screenshot was for a MUCH larger terrain. I'll need to resize the map to the heightmap size, that's the best solution.

You've probably figured this out by now, but you might want to try passing the data as texcoords instead. I.e. you could override this function void CShaderProgram::VertexAttribPointer(const char* UNUSED(id), GLint UNUSED(size), GLenum UNUSED(type), GLboolean UNUSED(normalized), GLsizei UNUSED(stride), void* UNUSED(pointer)) in CShaderProgramARB and try to hack it so it passes its arguments with glTexCoordPointer.

Sure! If you want a way to try it in-game, you'll need to apply the old "bumpy4" patch, as screen-space effects still aren't in the new git.

Thanks for the kind words, everyone, though I still think the programming team deserve your praise more than I do! (especially considering this was done in like 50 lines of code)

Dunno, I haven't looked at the ARB code. Maybe you could try using Nvidia's CG compiler to do the conversion automatically. I haven't tested it, though in theory it should be able to convert everything except the parallax mapping. The tangents are calculated on the CPU and then passed in to the shaders. I believe both the GLSL and ARB are invoked using the same code on the CPU side, and if Nvidia's compiler really works, it should know how to find them (as long as you set up the xml config).

Ok, it's been implemented. In Atlas, File > Import heightmap, you select an image file and bam. Code: https://github.com/myconid/0ad/tree/importheightmap Still pretty basic, though. Always generates a map of the same size, for example, based on the default map, and ignores the parts of the heightmap that are outside those bounds.

I haven't looked at the ARB shaders much, but I suspect you'd need to modify shaders/arb/model_common.xml and tell it to expect an extra stream.

This is completely based on a hunch, so don't count that it'll work. Can you please try going into renderer/InstancingModelRenderer.cpp and after the line: CModelDefPtr mdldef = model->GetModelDef(); add: glDepthFunc(GL_LEQUAL); & recompile.

I'm a little relieved that this isn't my fault. By looking at your screenshot I'd have thought that whatever is malfunctioning is either in the driver or in some alpha-testing or depth-function related config in the engine. How do you know the problem is with a_normal? That isn't used for alpha blending/testing, it's used for things like lighting.