aeonios

I like this. It should also be possible to make custom horizons that are independent from the skybox, but that would require basically a 4 sided alpha-blended "collar" that would be drawn over an existing skybox horizon to add in mountains or whatever. You can't just replace the side panels because then they wouldn't properly match the existing sky.

Could this be a javascript issue? I would assume that the js engines for windows and linux would probably be different, which could explain the discrepancy. I have no idea how that works though. OOM issues with scripting languages aren't that uncommon though, sometimes happening even when there is technically free RAM available.

There's no particular rush. Some things got fixed but refraction still works badly. The fact that different wave types have different normals makes scaling the distortions difficult.

wrt color, I think part of the issue is that colors in the real world are generally less saturated than the colors in game art. That was also the reason why I cut the intensity of sky reflections in half. I think another issue is that there's no map level control over shadow color. The shadows in that photo are very dark, but the ones in game are much brighter. That only occurs if the nearby object is blocking the view of the sky. Reflection distortions just tend to make the objects look wavier rather than breaking up the reflections like what water tends to do more, but I don't see a way of fixing that reasonably. log is one of those useful slowly increasing functions. Getting refractions to look good everywhere is still a challenge I'm working on though.

That's not so much a problem at low waviness as it is with low water depth. I've been trying to improve that but without much success as of yet.

Not at all. At first I thought there was some problem with excessive murkiness, but I found out later that it was just the map settings. In the end I left it the same, and murkiness isn't affected by the changes in refraction.

I think I've got it cleaned up well enough now, and finally got SVN set up to make a diff. Ticket here: http://trac.wildfiregames.com/ticket/3781

This was my source regarding FBOs: http://www.songho.ca/opengl/gl_fbo.html Updating to 4.0 would alienate more than half of all players, and if it's optional then it shouldn't interfere with the rest of the code anyway. Eventually I'll look through his code and see what he's actually trying to do and how that could best fit in. I'm not really to the point where it's relevant yet anyway though. That's what deferred shading does basically. First all objects are rendered onto a scene texture without lighting, and then all of the lighting calculations are done on the scene texture rather than per-object. Basically the entire scene becomes one object when fragment shading, which reduces the number of fragments that need to be produced. The "if" I was talking about was actually the branch for the red-water issue, which is an "if" as opposed to an "#if". That's actually only supported by GL3.1 or newer, which I didn't notice before, but that's probably the only thing in the entire shader which isn't 2.0 compatible. TBH I'm not even sure why that compiles when the shader version is set to 110 and dynamic conditionals require version 140.

Well, I figured out why that is. It's because 'water depth' is an approximation and not an accurate method for creating refractions. If the difference between the depth of the fish and the depth of the terrain behind them is large you end up with fish-shaped distortions. That's one of those 'only ray tracing can do that properly' effects, but I think I've got it to the point where it's pretty good nonetheless.

I see what you mean about normal maps now. That would indeed be a limitation of normal maps since the water surface technically remains flat, but the reason I removed the comment is simply because I've never seen any visually disturbing artifacts as a result of that. It might occur on huge maps, but I've never actually seen any of those, either (not that I've seen every map for that matter). The linear fresnel thing did indeed include reasoning, but I always found it to be visually disturbing. On the other hand I do see what you mean, since the water surface becomes invisible without any reflections at all (and irl the effective view angle would be distorted by lens effects). A more 'correct' solution would be to utilize a bias term in the fresnel approximation, which is what I ended up doing. The fresnel function I'm using currently looks like this: fresnel = clamp(((pow(1.1 - ndotv, 3.0)) * 1.5), 0.2, 1.0); where 3 is the power, 1.5 is the scale and 0.2 is applied as a bias through clamp. It ends up looking like this: Actually I do have a relevant question. For some reason fish display 'ghost refractions' that aren't fully opaque even though the fish are. You can see it especially in the bottom right of this screenshot: I think that's probably the culprit of 'off-colored-fish' issues that people have reported, but I'm not sure why it only happens for fish and not terrain. EDIT: Nevermind, the discoloration is a problem with depth, and I'm not sure how to fix that properly. Basically it uses the depth of the fish but the texture of something else due to the displacement.

The fact that pixels outside of the water plane are cleared to red is helpful in figuring that out. I'll have to tinker with that now that I know the cause. I was probably mistaken about it recalculating the shore line every frame. Shore waves are kind of expensive but probably for other reasons. Also, why does the normal map become blurry? I didn't see any particular evidence of lod being used, although it might be, but the water plane should be taking the surface normals directly from the normal map (and normalized vectors are distance and angle independent). Also note that if the angle between the view vector and the surface normal is small (ie looking at the side of a wave) what you -should- get is more refraction and less reflection anyway. The old fresnel function was also kind of bad, being nearly linear when reflections should be more confined to grazing angles. Another issue I found was that the addition of small waves on top of the large ones creates high frequency artifacts in the refractions (particularly with ocean waves). Removing them did not noticeably reduce wave details, but did remove the high freq noise. The small-wave-noise also made it look like the water was rushing along in a current rather than just being waves in a static body of water, and is a lot more noticeable with a high-res refraction map.

@fabio: Ah that's a good point. I went through and cleaned out all the old commented code just now, there wasn't a lot left but there was some that I missed. @Itms Is that an alternative to making a diff file or just extra?

The patch is here. The refraction texture is higher resolution in the new shader (requires a C++ recompile) and reflections are toned down quite a bit. Specular reflections might be tunable further, but I'd need to find some good reference photos to see what I need to aim for. EDIT: I dunno about black and red fish. I've seen fish get discolored in weird ways, but usually by the water's colors.

Can do. Old shader (same water/sky/sun settings, almost same angle): More screenshots soonish.

Hmm.. that'd be doable but I'm not sure how practical it'd be. You'd have to render the scene once per reflective surface, although not necessarily at a large resolution. It's also not historically accurate since there were not very good mirrors back then (personal mirrors were copper and not all that specular). Yves's project seems to be focused on minimizing the number of draw calls, which is certainly a major CPU-side overhead currently. I should note that GLMultiDrawArrays is listed as GL 1.4 and supported by 99% of all players. I don't see why any of that should require GL4.0 to be used. It's also complimentary to deferred shading. Another thing I noticed is that the renderer currently uses 9001 different FBOs, basically one per texture. Switching between FBOs is actually quite expensive, whereas swapping the textures attached to an FBO is cheap. Ideally the renderer would use exactly one FBO and just swap the attached textures as needed (and an FBO can have at least half a dozen different color textures attached at once).

I don't think the red water issue is related to any special overlays since it appears even when they're disabled. I think the red/black water issues should be moved to bugs, which I'll do shortly. I got everything cleaned up fairly well and made a PR. I also got specular reflections cleaned up and working. (I don't know if they were but they are now!) Also notice the foam caps in the screen shot. Code for drawing them has been around for a while but it was set to only show them from certain narrow camera angles. Now foam caps are visible from all directions (as they should be).

Another thing I found out was that the refraction map is super low res, which apparently was an aesthetic decision. Can also confirm the red water artifacts. There was a horrible hack in the shader to try to prevent it but that didn't work. It mostly seems to occur around map edges when facing the center of the map, but I have no idea where it's getting the red from. Ultimately it's an issue with how the refraction map is rendered, with the relevant part being in renderer.cpp. I'm not really sure where the black waves issue is coming from since I haven't tracked down exactly where the normal map is applied (which is the likely culprit). The fact that it depends on wind direction is the biggest clue in any case, and I'm pretty sure it's not shader side (although I need to recheck that). EDIT: Ok it's definitely in the shader. It seems to be related to some issue with CosSin, which might explain why it fails over half of angles, but I don't understand why it only happens with ocean waves.

lol this is a good example of why I shouldn't post things when half awake. I'm going to try building wxwidgets from source and see if that doesn't help.

I got 0ad/pyrogenesis to compile under VS (I'm pretty sure it worked anyway) but I keep getting errors trying to build Atlas. First I had an issue where the headers from wxWidgets expected to find a lib/vc_lib folder when vc_lib was called vc120_dlls or something like that. Renaming it to vc_lib fixed that. Then (now) I get unsatisfied link errors for all wx-widget related stuff when trying to compile atlas. I'm using the dev libs from wxwidgets and moved them into the libraries/win32/wxwidgets folder as instructed. When the header files were broken it wasn't even getting that far. Also using the release version of wxWidgets did not work at all, although I didn't build it from scratch and would rather not.

I was actually wrong about that. MRT has been supported since OpenGL 2.0. I doubt that I'll actually even require any 3.x features. I also found a normal "if" condition in the water shader, so apparently that's nothing new either (nor something required often, but it's nice to know that it's supported). Also, I'm working on finishing up a basic patch for water reflections/refractions atm, which will probably be finished tomorrow. I'm not really intending to try to do all of that at once, but that is the direction I'm looking at for the long term.

Well, if sky rendering is used for cutscenes it could automatically be loaded when a cutscene starts and unloaded when it ends. That's not particularly complicated to do. I still don't think it makes sense as an option though. Reading through the openGL compatibility census shows quite a few people using old hardware. I think it would be worthwhile in this case to maintain a legacy renderer, but I think it should be split fully from the newer renderer to keep things organized. On the other hand, extension wise I don't think any of the things I plan on implementing have special requirements. Deferred rendering doesn't require anything aside from FBOs, renderbuffers and MRT (which is defining for all GL3+ implementations and also mainly an optimization). Most of the current effects will still basically use the same implementations, just reshuffling the rendering process and economizing things. Soft shadow volumes doesn't require anything outside of basic GLSL support and could even be included in the legacy renderer. Also a lot of the things I'm looking at are just tuning of current implementations (depth of field for example, to make it usable). I don't really know what Yves is using from GL4.1, but to me that's the realm of things like light propagation volumes, adaptive bloom, stochastic rasterization and other really expensive (albeit shiny) stuff. There are also additional shader stages but I don't really know what they're used for.

The obnoxious black ring doesn't really help the effect either. Note that water reflections directly calculate the texture from the skybox and don't require the sky to be rendered in order to work, and there's hardly any reason to be looking at the sky anyway.

If you use 4.1 then I won't be able to run it. That might be useful for some high-quality optional shaders though. On the other hand if someone is already leapfrogging me then I suppose there are no objections to 3.x then. I think cleaning everything up and ensuring forward maintainability is more important right now though.

I found a weird bug with ocean waves. If you set the wind direction north (or move the slider to the left in atlas) at some point it starts producing weird black patches where the waves should be. Moving the wind slider to the right gets rid of the artifacts, and they don't seem to appear if you rotate the camera around the waves, only when changing wind angle.

I've been working on water rendering and mostly figured out how it works. It isn't yet screenshot worthy (and screenshots are terrible for conveying water effects) but I have made some definite progress already. Thus far: -I reduced the refraction displacement by half, which looks a lot better -I reduced the reflection distortions by more than half, which also looks a lot better (although it still needs some tuning for distance effects) --Currently I'm working on tuning the intensity of reflections and the fresnel factor used for intensity scaling. To Do: -Shore waves need more foam, and should produce foam trails when receding as well as when advancing. Also: shore waves seem to be recalculating the shoreline every frame, which may be contributing to the expensiveness. The shoreline really should only need recalculating if the terrain is modified or if you change maps entirely (ie in atlas), and should additionally be cheap to cache. It seems like someone was aware of that at one time but it just never got done.