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

[k776]

The distance fog is look pretty nice. Can we get this implemented as the default for maps please and apply it to all current maps.

Leave HDR/Bloom to the artists to tweak per maps, but fog seems a pretty generic thing all maps could have applied now.

[Mythos_Ruler]

The distance fog is look pretty nice. Can we get this implemented as the default for maps please and apply it to all current maps.

Leave HDR/Bloom to the artists to tweak per maps, but fog seems a pretty generic thing all maps could have applied now.

We can come up with some "standard" stats for the distance fog that can be applied to all maps, then we can tweak the ones we want to tweak. Can go further, and make "standard" distance fog stats for different biomes (snowy maps vs. desert maps vs. temperate maps, etc.), then tweak to suit.

[Jeru]

Ooh la la.

[ribez]

We can come up with some "standard" stats for the distance fog that can be applied to all maps, then we can tweak the ones we want to tweak. Can go further, and make "standard" distance fog stats for different biomes (snowy maps vs. desert maps vs. temperate maps, etc.), then tweak to suit.

i think that desert maps shoudn't have fog at all

[feneur]

Call it haze/blowing sand/etc if you like, but I still think it can be realistic (just did a google image search and in a very unscientific estimation I'd say there are about as many desert images with fog as say forests or mountains, not a big point either way, just that it can happen), so it's probably better to have some distance fog on all maps as a unifying element if nothing else

[fabio]

Postproc effects are not working properly o my Radeon X1600 with mesa drivers, see screnshots below. If I also enable preferglsl I get similar screen but also with these:

r300: ERROR: FS input WPOS unassigned, not enough hardware slots. (it's not a bug, do not report it)

r300: ERROR: FS input WPOS unassigned, not enough hardware slots. (it's not a bug, do not report it)

r300: ERROR: FS input WPOS unassigned, not enough hardware slots. (it's not a bug, do not report it)

r300: ERROR: FS input generic 20 unassigned, not enough hardware slots (it's not a bug, do not report it).

r300: ERROR: FS input WPOS unassigned, not enough hardware slots. (it's not a bug, do not report it)

r300: ERROR: FS input generic 20 unassigned, not enough hardware slots (it's not a bug, do not report it).

...

[ribez]

Call it haze/blowing sand/etc if you like, but I still think it can be realistic (just did a google image search and in a very unscientific estimation I'd say there are about as many desert images with fog as say forests or mountains, not a big point either way, just that it can happen), so it's probably better to have some distance fog on all maps as a unifying element if nothing else

well, honestly i see many differences between desert images

https://www.google.i...iw=1360&bih=629

and the Po valley (Italy) ones

https://www.google.i...iw=1360&bih=629

but, yes, it could be blowing sand

i only hope that map makers don't abuse of these effects, that are great when used properly

Just a question: it's possible to set the fog locally? i'm asking if is possible adding fog only around a river or a lake, or to the heights of a mountain

Edited October 17, 2012 by ribez

[FeXoR]

A bit of topic: Well looking dunes will soon be available for random maps with the erosion lib I'm working on. It already works but is not yet well documented and organized. I think it will be ready to use in a few weeks.

It would be cool if some global weather variables could be set and used by different parts of the game. One example would be the wind speed, direction and how squally it is. This could then be used for tree movement, terrain erosion and dust/smoke/steam particle movement. This will be hard to do ATM because e.g. RMGEN has no access to the engine and there's no way to set such things in the engine determined by the random map AFAIK yet.

Edited October 17, 2012 by FeXoR

[Spahbod]

Can we use these in random maps?

[myconid]

The distance fog is look pretty nice. Can we get this implemented as the default for maps please and apply it to all current maps.

That would be very easy to do, but I'm not sure it's the best solution here. Instead, what if we had a "presets" systems? I think the AoE3 editor had something like that.

Postproc effects are not working properly o my Radeon X1600 with mesa drivers, see screnshots below. If I also enable preferglsl I get similar screen but also with these:

Looks like the X1600 doesn't support OpenGL 2.1.

[myconid]

Just a question: it's possible to set the fog locally? i'm asking if is possible adding fog only around a river or a lake, or to the heights of a mountain

No, the postproc manager only does global effects.

Can we use these in random maps?

No, but a script interface is a must-have.

[Enrique]

I'm having lots of fun with the post processing manager!!

I made night settings version of Belgian bogs and played against the AI. It turned out quite fun

[myconid]

Whoa Enrique, I wanna play that!

I wonder if we could use "black fog" to limit visibility in nighttime maps.

[Enrique]

Whoa Enrique, I wanna play that!

I wonder if we could use "black fog" to limit visibility in nighttime maps.

That's what I did it makes a nice effect

EDIT: Commited if you want to try it

[fabio]

Looks like the X1600 doesn't support OpenGL 2.1.

On Mesa R500 has complete OpenGL 2.1 (the hardware doesn't support NPOT textures, but they are implemented in software, the only problem is a slowdown when they are used). It's likely a driver bug however.

[myconid]

On Mesa R500 has complete OpenGL 2.1 (the hardware doesn't support NPOT textures, but they are implemented in software, the only problem is a slowdown when they are used). It's likely a driver bug however.

IIRC, the 2.1 standard requires at least 32 register slots, and according to those errors your hardware doesn't have enough. The driver may provide 2.1 functionality, and maybe some of the higher-end models in same GPU series have the hardware support for it. I guess that's what they mean with the "it's not a bug, do not report it" thing.

Anyhow, if your driver doesn't report the number of slots, you can find it by sticking this somewhere in the engine's graphics code:

GLint v;
glGetIntegerv(GL_MAX_VARYING_FLOATS, &v);
std::cout << "SLOTS: " << v << std::endl;

[fabio]

Hmm, I'll try tomorrow with my current driver (from mesa 9.1) but according to the 0 A.D. OpenGL capability report for GL_MAX_VARYING_FLOATS_ARB (although it's not updated since long) all ATI cards have at least 32 slots (or also 40 on some version of RV530, my codename).

EDIT: also that error message only appears with glsl mode, while the corruption happens also on standard mode.

Edited October 17, 2012 by fabio

[fabio]

The WPOS error:

r300: ERROR: FS input WPOS unassigned, not enough hardware slots. (it's not a bug, do not report it)

is triggered by this code: http://cgit.freedesk..._derived.c#n552

while

r300: ERROR: FS input generic 20 unassigned, not enough hardware slots (it's not a bug, do not report it).

with: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_state_derived.c#n488

Edited October 17, 2012 by fabio

[myconid]

I see. The bit we care about is the "tex_count < 8" test. Without looking too deep into that code, I assume it's a hardcoded limit on the number of texcoord vectors (ie. hardware-interpolated 4-float registers). That's probably 4*8=32 floats. Probably. It could well be the case that with all the effects enabled the shaders compile to >32 varyings (worth trying lower values for materialmgr.quality in your config, to see if that helps).

Also, you mention that these errors are caused by preferglsl=true, not the postproc, however note that the postproc shaders always use GLSL (and we shouldn't discount that there may be something broken with the GLSL implementation you use). Let's see if other people experience similar issues...

Anyway, I'm afraid I can't for the life of me guess what might be going wrong from your screenshot. Maybe it could help a bit if you described how things change as you change the postproc settings.

[Mythos_Ruler]

Question: Would it be possible to make particles (smoke, etc., but not fire) cast shadows and be affected by sun/ambient color? I know this is a relatively new thing and I'm not sure if possible with OpenGL (I remember seeing screenshots of it for the latest version of DirectX).

[myconid]

Question: Would it be possible to make particles (smoke, etc., but not fire) cast shadows and be affected by sun/ambient color? I know this is a relatively new thing and I'm not sure if possible with OpenGL (I remember seeing screenshots of it for the latest version of DirectX).

Affected by lighting: yes. Cast shadows: no yes, maybe (the shadowmapping technique we use can't handle transparent objects - you're right that DirectX 11/OpenGL 4.3 have some tricks for that, though - actually, newer APIs aren't a requirement, and there are techniques that we could try!).

[Mythos_Ruler]

Affected by lighting: yes. Cast shadows: no yes, maybe (the shadowmapping technique we use can't handle transparent objects - you're right that DirectX 11/OpenGL 4.3 have some tricks for that, though - actually, newer APIs aren't a requirement, and there are techniques that we could try!).

Great news. It's not an important thing, of course, but it's one of those things that stand out from time to time (smoke not casting shadows, etc.).

[fabio]

(Sorry for the delay)

I see. The bit we care about is the "tex_count < 8" test. Without looking too deep into that code, I assume it's a hardcoded limit on the number of texcoord vectors (ie. hardware-interpolated 4-float registers). That's probably 4*8=32 floats. Probably. It could well be the case that with all the effects enabled the shaders compile to >32 varyings (worth trying lower values for materialmgr.quality in your config, to see if that helps).

The error just appears with preferglsl=true (and no other settings), even if I add materialmgr.quality=0.0

Also, you mention that these errors are caused by preferglsl=true, not the postproc, however note that the postproc shaders always use GLSL (and we shouldn't discount that there may be something broken with the GLSL implementation you use). Let's see if other people experience similar issues...

Anyway, I'm afraid I can't for the life of me guess what might be going wrong from your screenshot. Maybe it could help a bit if you described how things change as you change the postproc settings.

Without preferglsl=true:

Removing <PostEffect>hdr</PostEffect> from Zagros Mountains 01 removes the corruption. However I cannot notice any other effect (fog included). No errors are printed (also with hdr restored).

With preferglsl=true:

Removing <PostEffect>hdr</PostEffect> from Zagros Mountains 01 removes the corruption and I can notice some effect (at least fog). Errors are printed.

[kosmo]

Though I don't know how the particle system works atm, I thought this might be interesting:

http://www.cs.cornell.edu/~tedkim/WTURB/