zoot

I guess the surf is distributed somewhat 'randomly' along the shore with spaces of plain water in between.

I'm quite sure what Shield Bearer is reporting is an artifact of the shader not taking into account water depth and terrain slope. That's my best guess, anyway

The basic idea looks right, but it is quite slow on my (already slow) computer too. I went from 10 to 4 FPS when enabling fancy water on Mediterranean Coves. Do we have any hope of having the actual water plane sweep up on the shore and then recede?

I'll give it a spin The problem I see with using distance to the coast as a reference is that, unless you also take the angle of the coast into account, you might get waves that look a bit off. For instance, against a steep cliff you will want waves that surge 'violently' just before they hit the cliff face, not the cozy type of waves that roll slowly onto a beach. I only have a very general idea about how shaders work, but could you perhaps use a combination of the water depth at a given point and the gradient of the terrain immediately below it? On great depths, we obviously don't want breakers on the surface. On low depths we do. On steep gradients we want more 'violent' or intense breakers. On gentler gradients, not so much.

Wouldn't it be better to use a water depth parameter in those cases? I mean, physically, the water doesn't "know" the distance to the shore...

Are you aware of the <depth func="..."/> tag that can be specified per <pass>? It maps to glDepthFunc. Doesn't that effectively allow one to specify the distances at which a given shader should apply? Maybe "defines" would be used, then? But then the configuration system should be able to get a list of possible defines from somewhere...

The effects XML has something called "contexts" aka "modes". I suspect this would be used for binary effect on/effect off stuff.

I get this on the myconid/biwater branch: ERROR: Failed to compile shader 'shaders/glsl/water_high.fs': 0:83(33): error: Could not implicitly convert operands to arithmetic operator 0:0(0): error: no matching function for call to `mod(, float)' 0:0(0): error: candidates are: float mod(float, float) 0:0(0): error: vec2 mod(vec2, float) 0:0(0): error: vec3 mod(vec3, float) 0:0(0): error: vec4 mod(vec4, float) 0:0(0): error: vec2 mod(vec2, vec2) 0:0(0): error: vec3 mod(vec3, vec3) 0:0(0): error: vec4 mod(vec4, vec4) 0:83(45): error: Operands to arithmetic operators must be numeric 0:0(0): error: no matching function for call to `mix(vec3, vec3, )' 0:0(0): error: candidates are: float mix(float, float, float) 0:0(0): error: vec2 mix(vec2, vec2, vec2) 0:0(0): error: vec3 mix(vec3, vec3, vec3) 0:0(0): error: vec4 mix(vec4, vec4, vec4) 0:0(0): error: vec2 mix(vec2, vec2, float) 0:0(0): error: ...

Is it in your repo? If my computer can handle it, maybe I can find a way to videofy it.

What is needed before the modelmapping branch can go into SVN?

Perhaps a helpful metaphor is 'the water table'. Basically, the water table can be thought of as a terrain that is conceptually orthogonal to land terrain, with its own heightmap, tiles with materials, textures and blendings etc. That should also make it easier to do rivers and waterfalls: a waterfall, for instance, is just a drop in the water table, so this is where the engine should throw in special animations, particles, sounds etc.

If we use Blender's AO code, it should be just as good, and it would be done by the autobuilder, so most users wouldn't have to wait for it.

Cool! I happened upon this page yesterday. They use water depth in a seemingly simple way to do foam (don't know how well it looks, though). Another interesting point they make is about the phenomenon of 'color extinction', which may be related to what you are doing with murkiness.

Dare I ask what you would use this (water) depth info for?

Yep. Once the artists get their hands on it and can experiment with the normal maps, I think it will look great.

I see.

PITA as in boring and trivial to implement or PITA as in bad programming?

The lightning changes on the terrain, but not on the models (as far as I can tell). This is with max sun elevation and overbrightness:

Perhaps we can refactor it so instead a set of blend textures are specified per terrain XML and then the engine bakes the final blend map at runtime? That would make it less of a PITA for artists to add new blendings and would minimize the memory footprint of the blend map.

No, it happens on all models.

This is what I am seeing in Atlas: The temple model looks kind of dark? I haven't messed with the lightning settings. Grass and parallax works fine.

The premake file is missing: make[1]: Premake4.make: No such file or directory

I think that makes a lot of sense, given that "murkiness" in real life™ is due to particles in the water which would receive shadows if they were modelled individually.