Jump to content

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


Recommended Posts

  • 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

I get the following message when trying to checkout:

$ git checkout wraitii/merged 
error: The following untracked working tree files would be overwritten by checkout:
build/premake/.gccver.tmp
build/premake/premake4/bin/release/premake4
build/premake/premake4/build/gmake.unix/obj/Release/lapi.d
build/premake/premake4/build/gmake.unix/obj/Release/lapi.o
build/premake/premake4/build/gmake.unix/obj/Release/lauxlib.d
build/premake/premake4/build/gmake.unix/obj/Release/lauxlib.o
build/premake/premake4/build/gmake.unix/obj/Release/lbaselib.d
build/premake/premake4/build/gmake.unix/obj/Release/lbaselib.o
build/premake/premake4/build/gmake.unix/obj/Release/lcode.d
build/premake/premake4/build/gmake.unix/obj/Release/lcode.o
build/premake/premake4/build/gmake.unix/obj/Release/ldblib.d
build/premake/premake4/build/gmake.unix/obj/Release/ldblib.o
build/premake/premake4/build/gmake.unix/obj/Release/ldebug.d
build/premake/premake4/build/gmake.unix/obj/Release/ldebug.o
build/premake/premake4/build/gmake.unix/obj/Release/ldo.d
build/premake/premake4/build/gmake.unix/obj/Release/ldo.o
build/premake/premake4/build/gmake.unix/obj/Release/ldump.d
build/premake/premake4/build/gmake.unix/obj/Release/ldump.o
build/premake/premake4/build/gmake.unix/obj/Release/lfunc.d
build/premake/premake4/build/gmake.unix/obj/Release/lfunc.o
build/premake/premake4/build/gmake.unix/obj/Release/lgc.d
build/premake/premake4/build/gmake.unix/obj/Release/lgc.o
build/premake/premake4/build/gmake.unix/obj/Release/linit.d
build/premake/premake4/build/gmake.unix/obj/Release/linit.o
build/premake/premake4/build/gmake.unix/obj/Release/liolib.d
build/premake/premake4/build/gmake.unix/obj/Release/liolib.o
build/premake/premake4/build/gmake.unix/obj/Release/llex.d
build/premake/premake4/build/gmake.unix/obj/Release/llex.o
build/premake/premake4/build/gmake.unix/obj/Release/lmathlib.d
build/premake/premake4/build/gmake.unix/obj/Release/lmathlib.o
build/premake/premake4/build/gmake.unix/obj/Release/lmem.d
build/premake/premake4/build/gmake.unix/obj/Release/lmem.o
build/premake/premake4/build/gmake.unix/obj/Release/loadlib.d
build/premake/premake4/build/gmake.unix/obj/Release/loadlib.o
build/premake/premake4/build/gmake.unix/obj/Release/lobject.d
build/premake/premake4/build/gmake.unix/obj/Release/lobject.o
build/premake/premake4/build/gmake.unix/obj/Release/lopcodes.d
build/premake/premake4/build/gmake.unix/obj/Release/lopcodes.o
build/premake/premake4/build/gmake.unix/obj/Release/loslib.d
build/premake/premake4/build/gmake.unix/obj/Release/loslib.o
build/premake/premake4/build/gmake.unix/obj/Release/lparser.d
build/premake/premake4/build/gmake.unix/obj/Release/lparser.o
build/premake/premake4/build/gmake.unix/obj/Release/lstate.d
build/premake/premake4/build/gmake.unix/obj/Release/lstate.o
build/premake/premake4/build/gmake.unix/obj/Release/lstring.d
build/premake/premake4/build/gmake.unix/obj/Release/lstring.o
build/premake/premake4/build/gmake.unix/obj/Release/lstrlib.d
build/premake/premake4/build/gmake.unix/obj/Release/lstrlib.o
build/premake/premake4/build/gmake.unix/obj/Release/ltable.d
build/premake/premake4/build/gmake.unix/obj/Release/ltable.o
build/premake/premake4/build/gmake.unix/obj/Release/ltablib.d
build/premake/premake4/build/gmake.unix/obj/Release/ltablib.o
build/premake/premake4/build/gmake.unix/obj/Release/ltm.d
build/premake/premake4/build/gmake.unix/obj/Release/ltm.o
build/premake/premake4/build/gmake.unix/obj/Release/lundump.d
build/premake/premake4/build/gmake.unix/obj/Release/lundump.o
build/premake/premake4/build/gmake.unix/obj/Release/lvm.d
build/premake/premake4/build/gmake.unix/obj/Release/lvm.o
build/premake/premake4/build/gmake.unix/obj/Release/lzio.d
build/premake/premake4/build/gmake.unix/obj/Release/lzio.o
build/premake/premake4/build/gmake.unix/obj/Release/os_chdir.d
build/premake/premake4/build/gmake.unix/obj/Release/os_chdir.o
build/premake/premake4/build/gmake.unix/obj/Release/os_copyfile.d
build/premake/premake4/build/gmake.unix/obj/Release/os_copyfile.o
build/premake/premake4/build/gmake.unix/obj/Release/os_getcwd.d
build/premake/premake4/build/gmake.unix/ob
Aborting

To be honest, I have no idea what that means, but I found this.

Link to post
Share on other sites

k776, there have been a few bugfixes, so I'll generate new patches.

I can still faintly see the terrain after un-revealing the map, it seems it's not restored to fully black. You may need to adjust your monitor and zoom in to see it:

post-10080-0-82812300-1341876189_thumb.j

Already fixed but not committed. Done.

Confirmed (y)

Grass is not implemented in the ARB shaders. The grass texture is actually identical to the default texture, but also contains an alpha channel -- the alpha should be ignored, sounds like it isn't.

Right, on both GLSL and ARB I see the alpha channel as black, which could be partially responsible for the ugliness. It may be specific to my GPU/drivers:

post-10080-0-66303800-1341876418_thumb.j

But yeah I figured it was experimental, that's why I mentioned it last ;)

Link to post
Share on other sites

I'm aware of this. Not sure if there's anything that can be done about it. The terrain adds new geometry that is higher than the terrain itself, and there's no way of telling the overlay renderers about that.

Hopefully there is something that can be done, because it also obscures selection rings and territory boundaries. Not that it's any worse in theory than other grass we use, but it could cover large areas of the map, so it makes the little problem into a monster problem :( Maybe we need a way to draw overlays on top/in front of certain types of rendered things. Obviously you wouldn't want them on top of structures or units, but they should be on top of e.g. grass including alpha textured grass models.

@zoot: I believe tickets are not used for "art" stuffs... I'll post in the forum, that'll be best.

Actually from now on, you're fine creating a ticket for art tasks. But creating a topic in the Art Development forum is good for discussion too :) This topic pretty much explains what's going on with the art department: http://www.wildfiregames.com/forum/index.php?showtopic=16198

I tested your "merged" branch, please forgive me if I report something you already know, this topic has become difficult to follow in its entirety.

Seems to be a bug with decals, a few of them are black either when zooming in or at all times:

post-10080-0-83552400-1341881581_thumb.j

AO or something breaks the UI, because I can only reproduce this after viewing the new Temple of Mars:

post-10080-0-81753400-1341882184_thumb.j

Other than some bugs, everything you've done seems to work with ARB on my system, great job on that (y)

Link to post
Share on other sites

If someone could... would you please test these two normal files?

The celt_struct_1_normal should work with any (over a dozen) celt structure actors that still uses celt_struct_1 for it's base texture.

binaries\data\mods\public\art\actors\structures\celts

The other is a test on a unit, it should work for actor:

binaries\data\mods\public\art\actors\units\celts\brennus.xml

Thanks

PS - as someone mentioned here...

Why not use SSAO (perhaps as a supplement)?

SSAO would add ambient occlusion to the ground and dynamic objects (animated stuff like infantry and wagons) as well, not just static models. (If this method is used on a dynamic model, the lighting would not be correct in many circumstances)

Would it be reasonable to make a distinction between dynamic an static objects. Apply SSAO to the dynamic ones and prerendered AO to the static ones?

post-3-0-46620600-1341887557_thumb.png

post-3-0-30447500-1341887596_thumb.png

Link to post
Share on other sites

Seems to be a bug with decals, a few of them are black either when zooming in or at all times:

post-10080-0-83552400-1341881581_thumb.j

AO or something breaks the UI, because I can only reproduce this after viewing the new Temple of Mars:

post-10080-0-81753400-1341882184_thumb.j

Other than some bugs, everything you've done seems to work with ARB on my system, great job on that (y)

I'm not completely sure what causes this, but when setting "preferglsl = false", the choice of shaders for the GUI is the fixed function, not the GLSL shaders. I'm not completely sure, but myconid may have modified the fixed function, so the problem could come from that. I'll have to check.

The decals problem looks like it stems from the unfinished terrain shader. I'll try porting this over when Myconid has decided on the ≈ final version.

BTW, I'm still facing a problem with the ARB shaders... Since I can't have "IF", then the parallax is always active: this could slow computers down considerably. I'd want to try to implement something in the source code that would tell me if the nVIDIA extension is supported, and then if so, use the modified shader and not the basic one. I've actually already tried and succeeded at that, but it's a semi-important design change so I though I'd share. Particularly since in the perspective of ahving advanced graphic options to deactivate parallax specifically, you could have a tooltip for the case where the extension is not activated. Also, changing HWDetect to switch it off if the extension is not there and we want ARB shaders.

BTW, I assume the game prefers ARB shaders because of their wider compatibility?

Edited by wraitii
Link to post
Share on other sites
BTW, I'm still facing a problem with the ARB shaders... Since I can't have "IF", then the parallax is always active: this could slow computers down considerably. I'd want to try to implement something in the source code that would tell me if the nVIDIA extension is supported, and then if so, use the modified shader and not the basic one.

It would be a shame to have to drop all the non-nVidia users at this point, now that you have come so far. Can you describe what specifically you need "IF" for?

Edited by zoot
Link to post
Share on other sites

I'm not dropping the non-nvidia users. It's just that nVidia users could benefit from a faster, more efficient shader at no cost.

The GLSL parallax module uses "if" to determine if the distance is small enough to draw the parallax(for optimization). I can't do that with the ARB shader as is...

Alternatively, I might be able to have the engine calculate this, and then send it as a define. But that'd be more of a hack, and I'm not sure how usable it is. I dunno. Any opinions?

Edited by wraitii
Link to post
Share on other sites
The GLSL parallax module uses "if" to determine if the distance is small enough to draw the parallax(for optimization). I can't do that with the ARB shader as is...

Can't you use the SLT instruction in some clever way? Are you familiar with Boolean algebra:

In summary the three basic Boolean operations can be defined arithmetically as follows.

x∧y = xy

x∨y = x + y − xy

¬x = 1 − x

The basic idea is that you should be able to do AND, OR and NOT just with ordinary arithmetics.

From a quick glance at the GLSL, I think it should be possible, but do report back if that doesn't make sense to you.

Zoot, does it work now?

(reposting the link)

I'd recommend a clean-workspaces / update-workspaces.

I'm on it :)

Edited by zoot
Link to post
Share on other sites

Actually, dynamic branching is inefficient and to be avoided in all shaders, even when it's supported, and that includes GLSL shaders.

Ideally, I want to unroll the loop in the GLSL shader as well. I'd prefer we find a unified solution that executes the condition just once on the CPU, based on eye distance and a user-defined parameter, and then chooses the appropriate shaders rather than have to execute the condition on the GPU for each and every fragment with predetermined parameters.

Link to post
Share on other sites

Well using techniques and the "ShaderManager", I don't think it would be too hard to switch between two techniques. The hard part is defining the switch criterion. We could probably do it by adding a line along the lines of "<ifCriterion criterion = "distance" value="50" type="GreaterThan">" or something to the XML.

Ideally, we'd have a "base" shader, and if some criteria are met, we switch to another (more detailed) shader. This way, we could link 1/2/3/4… different shaders for different LOD, and also prevent this switching by options, so that lower configs would only use the base shader or the level 1.

Edited by wraitii
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.


×
×
  • Create New...