Jump to content
Sign in to follow this  
myconid

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.

Share this post


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.

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.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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.

Share this post


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.

Share this post


Link to post
Share on other sites

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

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

post-13528-0-51884100-1350490407_thumb.j

post-13528-0-42940100-1350490692_thumb.j

  • Like 1

Share this post


Link to post
Share on other sites

Whoa Enrique, I wanna play that! :shocking:

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

Share this post


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;

Share this post


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

Share this post


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

Share this post


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:

Share this post


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

Share this post


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

Share this post


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

Share this post


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.

Share this post


Link to post
Share on other sites

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.

Sign in to follow this  

×
×
  • Create New...