myconid

Thanks, that was quite helpful! I think the reflections rendering was interfering with the blending mode (so the LOS, meaning the on-screen rendering of what the units see, wasn't the problem in the end). The solution is to set the blending in Renderer.cpp. Right before the line: RenderModels(context); add this: glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); Hope this fixes it!

Argh, it's that same mistake again! In water_high.fs change: gl_FragData[1] = losMod; to: gl_FragData[1].rgb = vec3(losMod); I doubt the other problem is related... so if this doesn't fix it, I'll need more info to figure out what's wrong. Edit: There seems to be an issue with the LOS near transparent object edges. Is that what you are describing?

I hope you won't be disappointed when I stop adding new features and start cleaning up! Don't worry, I know what I'm doing. I package things up as one monolithic patch so people can test it out easier, not to commit. There are three different patches being worked on simultaneously: one for the model/terrain mapping (normal/parallax/specular/emissive), another for screen-space effects (ssao/hdr/bloom/fog) and one for the smooth LOS. I might end up merging the last two for various reasons. There'll need to be some serious changes to my code before I'm satisfied with it, so I'm not rushing to commit anything (and it's not like I have a deadline hanging over my head).

To make things like dynamic snow possible, I want to focus on adding extra UV channel(s) to the models and then set up a system for more advanced texturing/lightmapping. I haven't worked out the details yet, though I suppose if there's some sort of interface to the scripting engine it might be possible to do seasons, weather effects and so on without hardcoding everything in the engine. Anyway, first I want to wrap up the stuff I'm working on right now before I pick up something different. I know I got the basic functionality down, but the code is nowhere near ready to be committed into the engine yet.

The shader errors are easy to deal with (see attached). As for the framebuffer warnings, according to the spec... FRAMEBUFFER_UNSUPPORTED_EXT 0x8CDD Of course this is misleading because your card does support FBOs. The thing is, the spec gives one of the error's conditions as: I think I have a hunch about where the issue is, though I'm not sure yet. Can you go into renderer/PostprocManager.cpp and change this line: glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE16, width, height, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, 0); to: glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0); I'm thinking that the FBO might not like having two colour attachments of different formats. shader4.zip

I haven't looked at the exact code, but I suspect it's too much work for far too little visual improvement... I say this because anything that uses splines is too much work for far too little visual improvement. I can't say I understand why the culling even exists. If it's to speed the game up, the benefit is negated as soon as the map is fully explored... which usually happens at the start of the game! You can turn it off by going into source/simulation2/CCmpVisualActor.cpp and changing this line: m_Visibility = cmpRangeManager->GetLosVisibility(GetEntityId(), GetSimContext().GetCurrentDisplayedPlayer()); to: if (cmpVision->GetRetainInFog()) m_Visibility = ICmpRangeManager::VIS_VISIBLE; else m_Visibility = cmpRangeManager->GetLosVisibility(GetEntityId(), GetSimContext().GetCurrentDisplayedPlayer()); Looks much better without it (and no, the shadowmap doesn't implode). Edit: I need sleep. That code made no sense.

New patch: http://trac.wildfire...429/bumpy4.diff Includes the FBO/MTR optimisations I mentioned in my previous post + distance fog + smooth LOS + everything else. The LOS interpolation is done on the GPU. As a side-effect of this filter, the LOS texture starts by fading the world in from black. Easy to remove, though I quite like it! Let me know what you think. Super-compressed video: http://youtu.be/NJhbmIQ2K1w

Man, these are amazing. It reminds me of the art in Sierra's Caesar games that I used to play ages ago. If Bryce can export these to .obj format, you could import them in Blender and convert to any format you like. Also, have you ever considered baking textures from your models?

I'm considering using ping-pong FBOs to render the screen-space effects more efficiently, as opposed to copying the renderbuffers to textures every frame. I also want to try setting up two render targets in the main model and terrain shaders so I can render the LOS to a separate texture, to be recombined after all the rendering is done. This way I'll be able to apply the fog and then add smooth LOS texture fading without silly amounts of code duplication in the shader files. The only reason I can see against this is that GLES 2.0 doesn't support multiple render targets... which is hardly an issue, as all the advanced rendering stuff can be optional. Though I'm wondering... Does anyone have any good reasons about why I shouldn't be doing this?

Nope, it's real 3d rain. You can improve the effect by editing the config in 0ad/binaries/data/mods/public/art/particles/rain.xml and setting the "emissionrate" to something like 3000. The problem with it is that the droplets are unaffected by perspective, which is why they look weird to you. That's definitely an option that will need to be added (if it's not already supported).

I love the idea of clouds because they shouldn't be too hard to do. In my view they could be placed tastefully on mountain peaks and such, not in the player's face. Flightgear has some code, though writing our own won't be an issue. Isn't rain supported? I think one of the Punjabi maps has an example. Cloud shadows: absolutely, great idea.

Thanks, I know about those compile warnings, they aren't harmful and should be eliminated once I clean the code up. Sucks about the driver, though LTS of my OS ends in mid-2013 so I may be able to stick with the same version. I doubt the hardware of my laptop will even survive until then... I'll definitely give the Mesa driver a try, if it's a viable alternative.

I see. I think the default depth buffer settings of your card don't give high enough precision to handle the SSAO. There are three options: either we can force the engine to select a 24 or 32 bit buffer when it starts up (which could be inefficient if the hardware doesn't have good support), we can set a smaller distance between the near and far frustum planes (ie. limit the view distance so the depth buffer isn't so crowded), or we can just disable SSAO on systems that don't have the precision for it. I understand that today's older cards probably won't matter by the time 0ad is officially released. However, I think the first option could hinder efforts to port to portable devices (or not, I don't really know enough about their limitations). The third option is surely the safest. The fourth option (3.5?) is to disable the SSAO but push forward with precomputed AO to replace it, like Ykkrosh suggested earlier in the thread. I'm a fan of the fourth option.

Well, I plan to expose settings for the fog colour, fade distance and max thickness, which you'll be able to set for each map. As for having more fog in particular places, you'll need to use other techniques in addition to this. "Volumetric" ground fog is one such technique to get misty valleys or fog over the water. For real, awesome-looking fog, you need to use particles (which are supported by the engine, but I don't know to what extent). That's in the domain of cloud rendering, where there are algorithms like this.

Distance fog: http://i.imgur.com/K5DZJ.jpg

Looks like bad texture filtering (it's an older card). The brightness you can lower by choosing darker sun and ambient colours. There may be some dark areas around polygon edges on the roof. Number 3 is unexpected and may be a bug in one of the effects. Any chance we could get a closeup?

You're the first Nvidia user to test this, and it sounds like it works!

That's about equivalent to fabio's X1600, isn't it? I'm not optimistic, but there's no harm in trying!

Stricter compiler? Try changing this line in model_common_norm.vs: v_bitangent = cross(v_normal, v_tangent); to v_bitangent = cross(v_normal, v_tangent.xyz);

Whoops, fixed. As for a map, you can have the one I was testing with in the screenshot if you want. It's a really really ugly map. Oh, specular: yes. I should also mention that some maps look a bit too bright. You might want to try lowering the sun/ambient parameters in Atlas to an acceptable level (usually all need to go down about 10-15). derp.zip

Alright peeps, new patch. http://trac.wildfire...429/bumpy3.diff This contains all the effects shown in the previous screenshot. Textures are provided for "Roman Civic Centre" and "Snow/snow grass 2" for you to try. (Hopefully useful) Instructions: I'm assuming you know how to download the code and compile it on your system. There are detailed build instructions on the wiki for that. Here I'll concentrate on how you can apply a code patch under Windows. Get the latest version of the code from the Subversion repo, or update an existing copy. Download the .diff file from the link above. Find the project's root directory, "\0ad" (it contains the "binaries" and "source" directories). Right-click on "0ad". If TortoiseSVN is installed correctly on your system, you should see an "Apply patch" option. Click it. Select the .diff file. This should bring up a colourful dialog. Look where it shows a listing of the different files being patched (possibly somewhere on the left). Right click on the list and choose "Patch all". The code is now patched! Continue to compile normally. To actually see the effects correctly, you'll need some additional texture files, which you can find in the archive I attach below. Extract, then copy the contents of "structural" into 0ad/binaries/data/mods/public/art/textures/skins/structural/ and the contents of "terrain" into 0ad/binaries/data/mods/public/art/textures/terrain/types/snow/. Edit: Let me note once again that this is still a work in progress. bumpy3.zip

No, and we don't need to crank the effects up to 1500% like they did.

Hmm... I think it's about even. Distance fog? (3 lines of code) A desaturation filter, maybe? (Also, 3 lines of code)

Thanks. I'll release a new patch soon(-ish) & instructions to compile. The dark roof is because of parallax, though it's not a bug. The texture is mirrored, and it already contains shadows. So, when you look at it from the side you see just a part of the bumps that is either light or dark.

http://imgur.com/eo9Z1 All together now! Model parallax + model normal-mapping + terrain normal-mapping + terrain specular + HDR + SSAO + bloom. TGIF!