Post-processing effects test (SSAO/HDR/Bloom)

[zoot]

Actually, since it's two inputs, but one output, it should work.

I see.

The thing is that it seems to consider that "1.0" is not a scalar, for some reason... On my computer, there's no issue, which further baffles me.

Yeah, I'm using an Intel card so all bets are off Could it be that it has a problem with literals and you'd need to MOV the values into variables first?

[wraitii]

Could be. Try adding

TEMP temporary;

MOV temporary, 0.8;

just before the POW line( using POW fresnel, fresnel.x, 0.8; ).

[zoot]

I did this:

TEMP temporary;
MOV temporary, 0.8;
POW fresnel, fresnel.x, temporary.x;

Which seemed to work, because now the error has moved to another line:

ERROR: Failed to compile fragment program 'shaders/arb/water_high.fp' (line 93): line 90, char 45: error: expected scalar suffix
ERROR: CRenderer::EndFrame: GL errors occurred

If you can fix all errors of this type and push to Github, I'll pull and try again.

Edited July 5, 2012 by zoot

[myconid]

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.

Edited July 5, 2012 by myconid

[Sonarpulse]

In regards to the line ending issue, it maybe wise to keep a .gitattributes in the repository. Not only does mean each user no longer needs to individually setup git, but I've found it works more reliably too.

simply

* text=auto eol=crlf

might be enough to get the job done.

Also, myconid mentioned compiling GLSL to ARB. As the number of sharers increases going forward, shouldn't that be the most robust solution?

Edited July 5, 2012 by Sonarpulse

[wraitii]

I'm not too sure about the CG compiler... And I'm not sure it would work given the architecture of the shaders themselves. It would be efficient, but for robustness, redoing them is probably the best way.

I've committed the fix for the waterShader branch, it should work but there might be a place I forgot. The modelMapping branch will have to wait as I've started coding the Parallax stuff.

[zoot]

I've committed the fix for the waterShader branch, it should work but there might be a place I forgot.

It's working (save for a minor fix)! Water has never looked so pretty on this crummy netbook.

Well done.

[quantumstate]

For a slight diversion I thought it would be interesting to look at some fancier waves. I found this webpage provided an efficient approximation. Perhaps we could use it to create a wake around boats? I don't think it would work very well for ocean waves since it needs artificial damping or reflections off the coast will make it go wild.

http://freespace.virgin.net/hugo.elias/graphics/x_water.htm

I turned it into a javascript+canvas demo so you can see what it looks like.

http://dl.dropbox.com/u/1055062/erosion/waves.html

[wraitii]

I don't think the game has enough vertices to support that on a per-vertex basis. I could be done with fairly big waves, but then we would not require that kind or precision (I actually gave that a small shot 3 days ago, you can achieve a nice effect for a bargain cost right now). No idea how it would work on a fragment program, but I think it would require a (way too big) texture, unless I'm mistaken (how do shadows work?).

For boats and waves, the easiest system right now (with water as a flat plane) is probably to use a stencil over the water and to use bump mapping/parallax on that to achieve the effect of waves. Then again, I say "easiest", but it's also quite some work.

@zoot: pulled your fix, thanks! And I'm glad to know it's working.

Edited July 5, 2012 by wraitii

[zoot]

For a slight diversion I thought it would be interesting to look at some fancier waves. I found this webpage provided an efficient approximation. Perhaps we could use it to create a wake around boats? I don't think it would work very well for ocean waves since it needs artificial damping or reflections off the coast will make it go wild.

http://freespace.vir...ics/x_water.htm

I turned it into a javascript+canvas demo so you can see what it looks like.

http://dl.dropbox.co...sion/waves.html

I doubt this would scale to a full lake or river, because we can't tile it like the current water shader. You would need to run a full simulation of the entire body of water at all times or you would get weird artifacts where the ripples would cut off when you move the camera.

Cool demo, though.

Edited July 5, 2012 by zoot

[myconid]

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.

[wraitii]

Wouldn't that require a huge texture, though? The normals are basically a repetition of a small one, but using this efficiently would change that, or am I mistaken here?

[myconid]

Wouldn't that require a huge texture, though? The normals are basically a repetition of a small one, but using this efficiently would change that, or am I mistaken here?

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.

Edited July 5, 2012 by myconid

[wraitii]

I dunno, boat waves are fairly small things that would require precision. Perhaps we could trick it by using a 1024x1024 texture to say "where" we want the waves to be, and then have some smaller textures to actually represent the waves.

[quantumstate]

I don't really have any idea of how big a texture could reasonably get, also with a bigger texture processing power increases which might be a limiting factor. I don't know if it would be possible to somehow attach the texture to a boat, you could damp the waves sufficiently to stop the edges being a problem but where two boats are next to each other things would get tricky. I would say this technique is probably not worth pursuing.

[wraitii]

It's probably easier to add a transparent "wave" texture like most games probably do.

[myconid]

It's probably easier to add a transparent "wave" texture like most games probably do.

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

[Mythos_Ruler]

I don't really have any idea of how big a texture could reasonably get, also with a bigger texture processing power increases which might be a limiting factor. I don't know if it would be possible to somehow attach the texture to a boat, you could damp the waves sufficiently to stop the edges being a problem but where two boats are next to each other things would get tricky. I would say this technique is probably not worth pursuing.

I think this has been implemented in other games. Check out Red Alert 3 here:

It looks pretty darn good, and convincing. My one criticism about the water in Red Alert 3 is that the "scale" looks a bit off, like it's pool water instead of ocean water, and the boats are little toy boats in your backyard pool. It's the size and speed of the waves, I think. I'm not sure if this is a limitation of the technique or an aesthetic choice by the developers. Probably the latter.I think the waves created by passing boats should be more subtle and slower (to indicate scale) and may have intentionally been made more "dramatic" by the devs.

[wraitii]

I may be wrong, but this looks like an actual vertex displacement effect and not a texture simulation.

(which would explain the "backyard water" effect too, as this would require huge computing power to simulate an ocean perfectly.)

Edited July 5, 2012 by wraitii

[myconid]

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.

Edited July 5, 2012 by myconid

[historic_bruno]

Seems like it:

$ file source/renderer/TerrainRenderer.cpp
source/renderer/TerrainRenderer.cpp: ASCII English text, with CRLF line terminators

historic_bruno seemed to have issues with this too - maybe he can chime in with a solution...

I switched Git clients from Github for Windows to TortoiseGit. Now all is well and I'm quite happy with Git

I think this has been implemented in other games. Check out Red Alert 3 here:

It looks pretty darn good, and convincing. My one criticism about the water in Red Alert 3 is that the "scale" looks a bit off, like it's pool water instead of ocean water, and the boats are little toy boats in your backyard pool. It's the size and speed of the waves, I think. I'm not sure if this is a limitation of the technique or an aesthetic choice by the developers. Probably the latter.I think the waves created by passing boats should be more subtle and slower (to indicate scale) and may have intentionally been made more "dramatic" by the devs.

That would look amazing for building or destroying docks too

[theShadow]

for ships, couldn't you also add some particle effects along the hull to simulate water spray? combine this with the effect myconid said, and everything's shiny.

[wraitii]

That's the basic idea.

Going back to the original issue: I have a problem with GLSL on my Geforce GT 120. It also happens with regular SVN. model_common bugs. I've tracked it down to: v_normal (and incidentally v_tangent/v_bitangent). Now this is sent to the fragment shader by the vertex shader. Here, the problem can't be with InstancingTransform as the position is OK, and it uses that. Since v_normal only calls a_normal, the problem resides in a_normal. Now what is a_normal? It's defined as an attribute, asking for gl_Normal. Let's investigate Shader_manager.cpp.

gl_Normal is there defined to have location "2", as documented by nvidia. Afaik, this is right.

Now, when creating the shader, Shader_manager.cpp will set this "a_normal" as an attribute in vertexAttribs["a_normal"] = 2 (I believe). Vertex attribs are then passed to the GLSL shader. This is where it starts to differ from the ARB shader (which, remember, works, so we know that the problem is not in reading the files/passing the normals). Going into Shader_program.cpp, it calls CShaderProgramGLSL. This set "m_VertexAttribs" as the vertex Attributes.

Lines of interest are now 347/348, where "pglBindAttribLocationARB" is called; lines 489-505, where "Bind" and "Unbind" are defined; lines 633-653 where VertexAttribPointer and VertexAttribIPointer are defined.

Base on previous research, I also know that InstancingModelRenderer.cpp has something to do with that. When "stream_normal" is set (and it is), it will use NormalPointer (a overriden function that calls pglVertexAttribPointerARB, in position 2 (the same as defined by Nvidia). According to "glexts_funcs.h", this is equivalent to "glVertexAttribPointer", ie that. No reason to believe this bugs, in particular because the TexCoordPointer and the VertexPointer seem to work just fine.

There are other function calls that do other things. I'm not completely sure, as everything calls everything else. But I have no idea why this doesn't work for GLSL when it works for ARB.

[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.

[wraitii]

Complete edit: got it!

Live 92 of model_common.vs, change

	v_normal = normal;

to

	 v_normal = a_normal;

.

Edited July 6, 2012 by wraitii