Jump to content

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


Recommended Posts

On my system (Linux/ATI), the LOS texture gets painted where the shadowmap should be.

Which drivers? The shadow map texture is set up with GL_INTENSITY so it should have the same value in all .rgba components, so if .b works and .a doesn't then that sounds like a driver bug.

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

Which drivers? The shadow map texture is set up with GL_INTENSITY so it should have the same value in all .rgba components, so if .b works and .a doesn't then that sounds like a driver bug.

AMD's proprietary driver. Driver bug was my first thought as well, though thankfully the fix is simple enough.

Link to post
Share on other sites

This literally took 5 minutes using Blender:

http://imgur.com/a/MSmGU

The final image is from the vanilla game without any shaders, though obviously the diffuse textures had to be baked quite large for this to work.

That looks great! So are you guys are thinking that if you had a seperate set of UVs, you could leave the diffuse the way it is today and the second UVs would be used when rendering the SSAO pass?

If there was only a way (maybe a script?) to automatically generate these SSAO models/textures in batches out of blender or maybe even Pyrogenesis.

Link to post
Share on other sites

That looks great! So are you guys are thinking that if you had a seperate set of UVs, you could leave the diffuse the way it is today and the second UVs would be used when rendering the SSAO pass?

Yes, that's right. This second UV coordinates is used to map the precomputed/baked AO texture with multiply blending causing the effect.

You can also use it (if more texture layers are supported) to add another layer of detail to the texture, especially useful to hide tiling textures with dirt, cracks, moss.... wich helps variation and details overall)

If there was only a way (maybe a script?) to automatically generate these SSAO models/textures in batches out of blender or maybe even Pyrogenesis.

I'm not sure about this, at least in blender. The first problem that pops to my head is that importing/exporting collada files into blender destroys the UV seams on the model and should be done manually.

*EDIT: just found an option in blender to generate the seams based on the limits of the UV islands on the unwrap :yes3: . Maybe someone with phyton skills could make a script.... :P

Edited by Enrique
Link to post
Share on other sites
If there was only a way (maybe a script?) to automatically generate these SSAO models/textures in batches out of blender or maybe even Pyrogenesis.

To be clear/pedantic about terminology: Ambient occlusion (as discussed by e.g. GPU Gems in ~2004) is the general concept of computing the ambient lighting at a point based on how much of the sky is visible from that point, which involves casting rays outwards from each point and seeing if they reach the sky or hit some geometry. You can store that data either per vertex (if your triangles are high-res enough) or with a texture map. In contrast, SSAO (screen-space ambient occlusion) is a more recent (~2007) approximation of AO that doesn't use the real geometry (it sort of reconstructs an approximation of the 3D geometry based on just the 2D depth buffer after you've rendered everything).

So if we're implementing AO with textures (like what Blender does), it's not SSAO, it's just plain old AO. </pedanticness> :)

To fit with our current art pipeline, any AO texture computations really ought to be done by the game engine (along with the .dae->.pmd conversion etc), not by Blender. Redesigning the art pipeline is not impossible, but wouldn't be much fun (we probably don't want to batch-convert in Blender on every SVN user's machine since that seems slow and fragile, and quite awkward for modders, but then we'd have to find some way to store and distribute and update the converted files without it getting too painful, and AO computation needs some integration with the actor/prop system, etc). That GPU Gems chapter suggests how to implement the AO algorithm and it's not particularly complex, so I don't see why the engine couldn't do it in principle.

So, it should be possible :)

Link to post
Share on other sites

To fit with our current art pipeline, any AO texture computations really ought to be done by the game engine (along with the .dae->.pmd conversion etc), not by Blender. Redesigning the art pipeline is not impossible, but wouldn't be much fun (we probably don't want to batch-convert in Blender on every SVN user's machine since that seems slow and fragile, and quite awkward for modders, but then we'd have to find some way to store and distribute and update the converted files without it getting too painful, and AO computation needs some integration with the actor/prop system, etc). That GPU Gems chapter suggests how to implement the AO algorithm and it's not particularly complex, so I don't see why the engine couldn't do it in principle.

So, it should be possible :)

The UVs in the models won't work for this. Either the saved models will need to be updated with new non-overlapping sets of UVs, or the game will need to unwrap the models at runtime.

Link to post
Share on other sites

The UVs in the models won't work for this. Either the saved models will need to be updated with new non-overlapping sets of UVs, or the game will need to unwrap the models at runtime.

I'm probably two steps behind (as usual) but... what if a duplicate .dae model was generated on first run - for the sole purpose of using it's UV data for pre-computed AO. Then the engine could draw data from both .dae files and add that 2nd UV channel into a single .pmd for it's various rendering passes. Each pass could point to a different UV channel as needed?
Link to post
Share on other sites

I'm probably two steps behind (as usual) but... what if a duplicate .dae model was generated on first run - for the sole purpose of using it's UV data for pre-computed AO. Then the engine could draw data from both .dae files and add that 2nd UV channel into a single .pmd for it's various rendering passes. Each pass could point to a different UV channel as needed?

Version 3 .pmd files only support one set of UVs per vertex, but that doesn't mean the format can't be modified to support more UV sets in the same file.

Link to post
Share on other sites

As promised, some more work on the shaders! :D

Here's tangent-space normal mapping + steep parallax mapping: http://i.imgur.com/L8bdN.jpg

Nowhere near finished yet, however. I must have messed up the parallax math somewhere, because there are some nasty artifacts all over the place. Plus, it's still stupidly slow.

Whoa, it's definitely looking better, keep it up!

Link to post
Share on other sites

Right, so far I've been calculating tangent space per-fragment on the GPU (using dFdx/dFdy). That's good enough for a prototype, but it's actually really expensive, so now I'm setting things up so the tangents are precomputed once on the CPU and passed into the vertex shader.

I want to do that the "standard-compliant" way by using mikktspace.h/mikktspace.c like Blender does... but I can't get my head around the premake system.

Can someone please briefly explain how I can compile/link to these from ModelRenderer?

Link to post
Share on other sites

Easiest way is to rename the .c file to .cpp; put both .cpp and .h into source/graphics/; re-run update-workspaces (which will add the new source file into the project); add "#include "precompiled.h"" into the top of the .cpp file before any other non-comment code; then use it by doing "#include "graphics/mikktspace.h"" wherever you want it.

Link to post
Share on other sites

Easiest way is to rename the .c file to .cpp; put both .cpp and .h into source/graphics/; re-run update-workspaces (which will add the new source file into the project); add "#include "precompiled.h"" into the top of the .cpp file before any other non-comment code; then use it by doing "#include "graphics/mikktspace.h"" wherever you want it.

Thank you. :i-m_so_happy: I'm glad I don't have to mess with premake configs directly -- that would have been such a huge PITA!

Link to post
Share on other sites

A small update, just to let you know that the glitches are hopefully all ironed out, and the tangent stuff is now all computed on the CPU (with exactly the same method as Blender so even baked maps should work correctly).

Here's a little test pic: http://imgur.com/HPJ76

The roof on the left is parallaxed/normal mapped, the roof on the right isn't. I think it looks a little better! :D

Since the parallax effect is most noticeable up close, it only gets applied when objects are closer than 65m away, and is gradually scaled up in quality as the object comes closer (The cutoff is done with an if statement, with some possible caveats depending on what the GLSL compiler does under the hood... though it should save clock cycles in almost all cases). Normal mapping is always on, though a similar trick could be used for that.

I'll probably release some source code over the weekend if any people want to play with it, though be warned that it's still very much a work-in-progress.

Edited by myconid
  • Like 1
Link to post
Share on other sites

I'll probably release some source code over the weekend if any people want to play with it, though be warned that it's still very much a work-in-progress.

Please do, it's better to have some work in progress, than for someone to disappear and all we have left is pretty screenshots (it happens) :) Also, I made a Trac ticket for advanced texture maps: http://trac.wildfiregames.com/ticket/1429 which seem to cover some or all of what you're working on. Feel free to take ownership of the ticket and post WIP patches there. Or you can create a new ticket in case that one is not a good fit.

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