Jump to content

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


Recommended Posts

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.

Link to post
Share on other sites
  • Replies 1,3k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hey everyone, I've been coding some very rough GLSL post-processing tests just to see what they'd look like in 0ad, and thought I might share some results. The following images are in pairs, with the

Much appreciated. I'd like it if people tried the code and gave me some feedback, if possible. No need for anything fancy, just compile, run Oasis 10 and let me know if anything looks wrong, and how

Just wanted to say the rock mountain screenshot above looks fantastic

Posted Images

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.
Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

...

post-8891-0-33296600-1350457062_thumb.pn

Link to post
Share on other sites

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 by ribez
Link to post
Share on other sites

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 by FeXoR
  • Like 1
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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;

Link to post
Share on other sites

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 by fabio
Link to post
Share on other sites

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 by fabio
Link to post
Share on other sites

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. :unknw:

Link to post
Share on other sites

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

Link to post
Share on other sites

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.).
Link to post
Share on other sites

(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. :unknw:

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.

Link to post
Share on other sites
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...