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

[Wijitmaker]

What about using some of the cloud/fog code in Flightgear? AFAIR they're pretty good at semi-realistic clouds. Not sure if it can be easily used in Pyrogenesis though.

I'm not so sure about how much ground clouds for fog would be used, and it might be a neat affect - but another visual that would be nice would be to have would be ground shadows that are cast onto the world. I think this could be done with a simple scrolling black and white texture map (similar idea to the animated textures suggestion - which would be another great addition for waterfall objects, wheels, and tracks).

If you are going to start looking at the particle engine, please take a look at the feasibility of rendering environment particles to simulate things like falling snow and rain.

Awesome work so far - please keep it up!

[myconid]

This computer is anything but stable, so it wouldn't surprise me if it was just a glitch of my hardware

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.

[myconid]

OK, I tested latest patch. There are some compile warnings:

(snip)

Here is what I get on my Radeon X1600:

Note: Radeon X1600 is OpenGL 2.1/GLSL 1.20.

Also:

Note that on next Linux distributions round you'll have to use the mesa driver as well, since fglrx will drop support for 2xxx->4xxx cards on newer kernel/xorg.

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.

[myconid]

I'm not so sure about how much ground clouds for fog would be used, and it might be a neat affect - but another visual that would be nice would be to have would be ground shadows that are cast onto the world. I think this could be done with a simple scrolling black and white texture map (similar idea to the animated textures suggestion - which would be another great addition for waterfall objects, wheels, and tracks).

If you are going to start looking at the particle engine, please take a look at the feasibility of rendering environment particles to simulate things like falling snow and rain.

Awesome work so far - please keep it up!

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.

Edited June 4, 2012 by myconid

[zoot]

I believe the rain on the Punjabi map is rather crude. It's more like raindrops hitting a windscreen than actual, three-dimensional, environmental rain.

[myconid]

I believe the rain on the Punjabi map is rather crude. It's more like raindrops hitting a windscreen than actual, three-dimensional, environmental rain.

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

[myconid]

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?

[myconid]

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

Edited June 7, 2012 by myconid

[k776]

Very nice :-) Keep up the great work!

While you're there, how easy is it to also make territory border changes animate into their new positions?

[Mythos_Ruler]

Dig the smooth LoS.

[zoot]

Looks very good. I guess the thingy that culls stuff in the SoD needs to be tweaked so objects don't pop into existence at the edge of the LoS.

[myconid]

While you're there, how easy is it to also make territory border changes animate into their new positions?

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.

Looks very good. I guess the thingy that culls stuff in the SoD needs to be tweaked so objects don't pop into existence at the edge of the LoS.

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.

Edited June 7, 2012 by myconid

[halcyonXIII]

I'm getting the following error messages on the main menu screen, with your new patch:

WARNING: Framebuffer object incomplete (A): 0x8CDD
WARNING: Framebuffer object incomplete (: 0x8CDD
ERROR: Failed to compile shader 'shaders/glsl/fog.fs': 0(23) : error C7011: implicit cast from "vec4" to "vec3" 0(28) : error C7011: implicit cast from "vec4" to "vec3" 0(34) : error C7011: implicit cast from "int" to "float" 0(34) : error C7011: implicit cast from "int" to "float"
ERROR: Failed to compile shader 'shaders/glsl/los.fs': 0(23) : error C7011: implicit cast from "vec4" to "vec3" 0(25) : error C7011: implicit cast from "vec4" to "vec3"

And then these when I load a map:

ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/terrain_common.fs': 0(156) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/terrain_common.fs': 0(156) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/terrain_common.fs': 0(156) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: Failed to compile shader 'shaders/glsl/model_common.fs': 0(132) : error C7011: implicit cast from "float" to "vec3"
ERROR: CRenderer::EndFrame: GL errors occurred

I'm not sure about the two warnings, but the errors look similar to the one I encountered when trying your last patch.

[myconid]

WARNING: Framebuffer object incomplete (A): 0x8CDD
WARNING: Framebuffer object incomplete (: 0x8CDD

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:

The combination of internal formats of the attached images does not violate an implementation-dependent set of restrictions.

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

[fabio]

Hi, I'd like to test it but I cannot do it until next month (anyway I am sure my old Radeon will have problems...). Would be possible to also add dynamic snow? does it make sense anyway?

[myconid]

Hi, I'd like to test it but I cannot do it until next month (anyway I am sure my old Radeon will have problems...). Would be possible to also add dynamic snow? does it make sense anyway?

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.

[Wijitmaker]

I'm digg'n the smooth LOS, very nice - thanks for the videos and pictures too - its great for us windows users that don't have an .exe to play with and aren't savvy enough to compile.

To make things like dynamic snow possible, I want to focus on adding extra UV channel(s) to the models

... and perhaps something more important than aesthetics - damage texture maps which could communicate visual gameplay information to the players.

I look forward to checking this thread out each day looking for what is new

[WhiteTreePaladin]

Yes, like burned building textures to go with the flaming particles on damaged structures and cracks for damaged walls.

[zoot]

I wonder how hard it would be to add displacement maping. Seems like it would be ideally suited for that kind of thing.

[k776]

myconid: This is starting to become a mammoth patch. That'll make it hard for developers to review and commit.

Where possible, provide a patch for each individual feature. e.g. If the code for smooth LoS doesn't rely heavily on your other changes, pull it out, patch it up, and post it on http://trac.wildfiregames.com . Same for distance fog, bloom, hills with snow effect, etc.

[myconid]

I look forward to checking this thread out each day looking for what is new

I hope you won't be disappointed when I stop adding new features and start cleaning up!

myconid: This is starting to become a mammoth patch. That'll make it hard for developers to review and commit.

Where possible, provide a patch for each individual feature. e.g. If the code for smooth LoS doesn't rely heavily on your other changes, pull it out, patch it up, and post it on http://trac.wildfiregames.com . Same for distance fog, bloom, hills with snow effect, etc.

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

[Pureon]

Nice work myconid, we're all glad you know what you're doing

[halcyonXIII]

The framebuffer warnings have gone after applying your changes to PostprocManager.cpp, and the replacement files have fixed the errors. I have new one for you though:

ERROR: Failed to compile shader 'shaders/glsl/water_high.fs': 0(56) : error C7011: implicit cast from "float" to "vec4"

This is presumably what is causing the water to look undecorated, however I'm seeing another problem in addition to this, perhaps it is related. The terrain and some entities are black, but this only seems to happen when no water is being rendered. If some water is visible, then everything appears correctly. (except the water, of course.)

I'm not seeing any other error messages (except that model_common_norm.vs one), nor framebuffer warnings. Hopefully that's the last of them.

[myconid]

The framebuffer warnings have gone after applying your changes to PostprocManager.cpp, and the replacement files have fixed the errors. I have new one for you though:

ERROR: Failed to compile shader 'shaders/glsl/water_high.fs': 0(56) : error C7011: implicit cast from "float" to "vec4"

This is presumably what is causing the water to look undecorated, however I'm seeing another problem in addition to this, perhaps it is related. The terrain and some entities are black, but this only seems to happen when no water is being rendered. If some water is visible, then everything appears correctly. (except the water, of course.)

I'm not seeing any other error messages (except that model_common_norm.vs one), nor framebuffer warnings. Hopefully that's the last of them.

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?

Edited June 8, 2012 by myconid

[halcyonXIII]

Okay, the water is displaying correctly now, but the black terrain and entities issue still persists.

Edit: There seems to be an issue with the LOS near transparent object edges. Is that what you are describing?

I'm not sure, I'm not too familiar with what LoS (Line of Sight?) is. Is it what your units can see? Panning the screen to an area where water is, even if that part of the map has not been revealed yet, will still cause everything to render correctly until I pan away from the water again.

Although I did noticed that disabling the 'Enable Water Reflections' option in the menu causes the black terrain and entities to show regardless of whether the water is in view or not.