Of water and waves

[Mythos_Ruler]

I also have some wave textures in the game you can try.

[wraitii]

Thing is, I don't think proper waves texture will do given the way this works. The necessity to do it 360° means that even when upscaling (what I've got on my working copy) there will be some (pretty serious) artifacts. The other solution would be to put waves only in some places, but that wouldn't work so well I think. The best is probably to use a 1 dimensional gradient and then apply a texture (like my foam texture) to re-create the illusion.

I'm not surprised that even Red Alert 3 doesn't have waves on the shores.

I'm still pondering simply having this done texturally to have the shape of the coast correctly.

Edited July 17, 2012 by wraitii

[Mythos_Ruler]

I think some of the best looking shore waves come from Age of Empires 3:

[wraitii]

I'll give a look at their shaders, could always learn something.

I've got a system that should be all-right, but won't look that good…

Edited July 17, 2012 by wraitii

[Shield Bearer]

AOE3 has a nice looking water texture too

[wraitii]

I do realize that .

Okay, so I'm not happy with how the waves look. I could pull out a sort of workable system that would be bugged in some situations but would work in others, but I don't think it's really that good-looking (and given how the rest of the water now looks, I feel it's a step back).

Therefore, I'll now try to clean up my patch for the water (without the waves) so it can be put, whatever happens, in alpha 11, and then I'll work on another solution for the waves: cutting the water mesh in two: a "coastal" part and a "high sea" part, that will allow me to have both shaders more efficient at what they do (the main bulk of the code would be the same, but some stuffs about foam or reflections could slightly change). With that system, I'll get rid of annoying mesh and z-fighting issues, and I think I could pull of some niceties a-la AOE3. Perhaps. Not as good. Perhaps.

If that's okay with you.

Edited July 18, 2012 by wraitii

[wraitii]

Allright, I've finished the "clean" version. It fixes most remaining problems: water texture/foam texture looping issues, small depth buffer things that could prove distracting, and MEM_ACCESS crashes (I don't think there remains any, but it's always possible that there's a well hidden rare case). The only thing lacking is waves, but in the concern of putting this in the game, and since I believe there will be a lot of trial and error with waves, and I'm not there this week-end+, I think it's better.

So it's all committed here. I'm not sure what the procedure on committing to SVN is, I don't think I can do it, or at least am unsure. Since there are probably other modifications than strictly the water stuff in this branch (which I believe I forked from myconid's merged branch some time ago, and anyway it's not up-to-date with SVN), would it be better if I took a clean SVN, merged with the water patch myself (by hand?), and then committed those files/gave those files to someone who can commit?

Is the GIT mirror for SVN up-to-date? In this case I could fork that and patch, and then it'd probably be easier to put into SVN.

Edited July 18, 2012 by wraitii

[myconid]

Very nice! Tested it and it works great. It is a bit too slow in Atlas - maybe the superfancywater stuff could be turned off when not in the game proper? (after all, the water isn't even animated in Atlas)

As for your git questions you have a number of options.

• You can make a temporary copy of your water branch in git, squash the commits you created, write the squashed commit to a file to create a patch, checkout the svn code and patch it with the "patch" command. Make sure everything is merged properly and then "diff" a new patch for submission. Remember not to include any of my model/terrainmapping code when squashing, though!
  
• It may be easier if you add the official 0ad git repo to your local git (which I believe is up to date enough,since the terrainrenderer isn't changing much), make a copy of its master branch and cherrypick/apply the commits you want from your water branch. You could then squash and create a patch to test with the svn code, though I'm fairly sure you won't need any further changes.
  
• Another option would be for me to update my master repo from upstream and you pull the updates through me, though I can't be bothered to regenerate the actor/terrain xml files, so I'd prefer we avoid this for now.
  

Btw, that trick I suggested for getting the accurate water depth looks even better than I expected! We should use it to do volumetric fog as well! Just think "fog planes" that apply that sort of effect to their surfaces... Come to think of it, the depth texture should be accessible to any material that requests it. On that note, if you're interested in future changes that may help speed up your code, look in my "postproc" branch and you'll find the (still unfinished) PostprocManager that has the depth buffer already available for binding as a texture, which can save you the overhead of copying the depth all the time. If you want to try it, remember to turn depth writes off if they're used in the water renderer (can't read and write to the same buffer in the same shader).

Anyway, nice work, wraitii!

Edited July 18, 2012 by myconid

[wraitii]

We'll change things when we get that in. But yes, it does look very nice thanks to the depth buffer (particularly around edges, where the normal fancy way gives really wrong results in some cases).

I think I'll pick the second option, it sounds like it's the most obvious and the easiest one to implement.

Atlas is slow because it recreates the texture every frame, in case the water height has changed. It ought to only when the water height changes, or it could be deactivated in Atlas... Is there a way to know in-code if it's Atlas or not? That should be a very easy fix.

Edited July 18, 2012 by wraitii

[Pureon]

Great stuff guys, it sounds very promising!

[myconid]

Atlas is slow because it recreates the texture every frame, in case the water height has changed. It ought to only when the water height changes, or it could be deactivated in Atlas... Is there a way to know in-code if it's Atlas or not? That should be a very easy fix.

Yeah, I figured that was the case. I believe you can check if you are in Atlas by testing this:

if (g_AtlasGameLoop) {}

Not sure how reliable this is.

[quantumstate]

Btw, that trick I suggested for getting the accurate water depth looks even better than I expected! We should use it to do volumetric fog as well! Just think "fog planes" that apply that sort of effect to their surfaces...

Now you just need to make my 0 A.D. look like this http://shadowness.com/fuzzypiggy/north-of-arundel-2 . You and wraitii are doing a great job, keep it up .

[myconid]

Now you just need to make my 0 A.D. look like this http://shadowness.co...th-of-arundel-2 . You and wraitii are doing a great job, keep it up .

We might!

Seriously though, just look at Skyrim! That sort of effect can be done with particles, which can be generated procedurally in Atlas. A while ago, I linked to a paper that explains how they did awesome-looking clouds in MS Flight Simulator '04. It's on the list!

[wraitii]

Okay, so I've forked from the latest update in 0ad-git, and I've applied the necessary changes for my water patch, and only those. It's two patches because I forgot some stuffs on the first commit.

I've tried (and succeeded) to compile and make it run from this clean patched branch, so I assume there is no problem (unless in the last two days someone changed everything but I don't think that happened.

I've linked them as attached files... Would that be enough for committing in SVN?

(I've changed the Atlas stuff so it doesn't use the super fancy water, and since I haven't yet ported to ARB It'll always use GLSL).

0002-Clean-commit-of-my-water-Shader-in-theory.patch

0003-Fix-messup-ready-to-SVN.patch

Edited July 19, 2012 by wraitii

[Sonarpulse]

As for your git questions you have a number of options.

• You can make a temporary copy of your water branch in git, squash the commits you created, write the squashed commit to a file to create a patch, checkout the svn code and patch it with the "patch" command. Make sure everything is merged properly and then "diff" a new patch for submission. Remember not to include any of my model/terrainmapping code when squashing, though!
  
• It may be easier if you add the official 0ad git repo to your local git (which I believe is up to date enough,since the terrainrenderer isn't changing much), make a copy of its master branch and cherrypick/apply the commits you want from your water branch. You could then squash and create a patch to test with the svn code, though I'm fairly sure you won't need any further changes.
  
• Another option would be for me to update my master repo from upstream and you pull the updates through me, though I can't be bothered to regenerate the actor/terrain xml files, so I'd prefer we avoid this for now.
  

I believe you don't need to squash your history to make a patch. I just searched and it seems their are a number of ways to convert a git patch to a svn patch.

[wraitii]

Okay I'm back from holidays and will try again with the waves stuff.

[wraitii]

Allright. I'm really having troubles with the waves, and i can't figure how to do it in any kind of a beautiful way. I have right now a system that has waves following the curve of the ground nicely, but it's ugly.

I'm really unsure how to improve on that...

[Pureon]

Could you record a few clips of your waves? If they aren't too bad, I'd say we commit them and then anyone can help tweak textures/functions to improve on what you've already done.

Can the waves opacity be reduced easily?

[wraitii]

I certainly can, and it certainly can be deactivated until someones finds a better looking way.

The only problem here is committing to SVN efficiently.

[myconid]

Allright. I'm really having troubles with the waves, and i can't figure how to do it in any kind of a beautiful way. I have right now a system that has waves following the curve of the ground nicely, but it's ugly.

I'm assuming you're drawing new geometry that superimposes a wave texture on the water?

Here's what I'd do: instead of drawing the waves directly to the screen, I'd draw them to a separate buffer (size of the screen) to create an extra normalmap that is then added to the animated water normalmap in the water shader.

This will also let us do other more complex water effects, like ship trails and so forth.

[wraitii]

Tried that but it was unsatisfactory in some cases. Right now I'm using the "distance to shore" parameter to have the shader add a texture, but it's really not that good-looking.

Your idea could work, I'll have to see how hard/easy to do it would be. I assume you'd require some sort of knowledge of perspective, and a way to keep track of waves/update.

Edited July 26, 2012 by wraitii

[myconid]

Your idea could work, I'll have to see how hard/easy to do it would be. I assume you'd require some sort of knowledge of perspective, and a way to keep track of waves/update.

Both the waves and the water plane are already in perspective (think about it), so you don't need to worry about it at all.

What if you create animations of waves and then have a script to place them in Atlas where needed (basically remove them and reinsert them on terrain/water update). There's already a way to make objects float on water...

[wraitii]

Very hard to have a nice result given that it must rotate 360° and it has to scale (and textures too) properly.

[myconid]

You don't need to do any of that. Both the water plane and the waves are in screen coordinates when they are combined.

1. You draw the waves in perspective, just as you would draw them on screen, except you store them separately in a texture.
   
2. When you are drawing the water plane, after the perspective transformations, the gl_Fragcoord of a fragment on the water surface will match that position in the waves texture.
   

It's exactly the same thing you did with the depth texture, isn't it?

[wraitii]

It would, but the hard part here is actually number 1. Drawing the waves on screen properly is harder than I expected, at least to me. I may be missing something, though.