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

[Ykkrosh]

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.

[myconid]

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.

[Wijitmaker]

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.

[Enrique]

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 . Maybe someone with phyton skills could make a script....

Edited May 16, 2012 by Enrique

[Ykkrosh]

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

[myconid]

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.

[Wijitmaker]

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?

[myconid]

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.

[myconid]

As promised, some more work on the shaders!

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.

[wraitii]

Steep parallax mapping looks great on those windows. I'm assuming the "flags" on the sides aren't affected?

[quantumstate]

Nice work. Having these shader effects in the game will make it nice and pretty .

Doing some reading I found this paper had an interesting method for variable step size steep parallax mapping. http://www.lonesock....StepMapping.pdf

Edit: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch18.html looks better

[myconid]

I'm assuming the "flags" on the sides aren't affected?

They are, but very subtly for some reason. The heightmaps were automatically generated in the GIMP, so they're less than ideal.

[myconid]

Nice work. Having these shader effects in the game will make it nice and pretty .

Doing some reading I found this paper had an interesting method for variable step size steep parallax mapping. http://www.lonesock....StepMapping.pdf

Edit: http://http.develope...gems3_ch18.html looks better

Thanks, I might have a read later.

[Enrique]

As promised, some more work on the shaders!

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!

[myconid]

Probably not going to put more work in tonight, but here's something a little different just for fun

http://i.imgur.com/NnSDI.jpg

(From TESV, obviously.)

[Mythos_Ruler]

Probably not going to put more work in tonight, but here's something a little different just for fun

http://i.imgur.com/NnSDI.jpg

(From TESV, obviously.)

What is TESV?

The shot reminds me of this little April Fools prank we did some years ago:

http://wildfiregames...page.php?p=7825

[Zeta1127]

These post-processing effects look promising.

Ah, Skyrim, I probably should get that for Xbox 360 at some point.

[feneur]

What is TESV?

The Elder Scrolls V (more commonly known as Skyrim ).

[myconid]

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?

[Ykkrosh]

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.

[myconid]

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 glad I don't have to mess with premake configs directly -- that would have been such a huge PITA!

[myconid]

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!

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 May 25, 2012 by myconid

[Mythos_Ruler]

Awesome progress man. I love the LOD.

[historic_bruno]

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.

[Wijitmaker]

Looks great, I hope my old video card handle it If not, maybe a good excuse to get an upgrade