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

[myconid]

If you look at the public/shaders/effects folder, you'll see how the multipass shader architecture works. It should be pretty easy to hack it so each pass has two optional parameters that define a range where that pass is active.

[myconid]

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.

I've already added something like that. The user-defined materialmgr.quality setting in the config determines which materials/shaders are loaded. For example, the player_trans_ao_parallax_spec.xml material has this line:

<alternative material="player_trans_ao_spec.xml" quality="8"/>

that tells it to load an alternative material without parallax if the user/engine set the quality factor to less than 8. Unfortunately, this is determined statically at load time, so we can't use it for LOD during rendering.

Come to think of it, this could still be combined with the new stuff quite elegantly.

Edited July 10, 2012 by myconid

[wraitii]

Yeah, I've given a look at that... I'm thinking it would be possible to push it slightly further... Of course, we don't need a completely modular system.

[myconid]

it would be possible to push it slightly further

We might as well. The better our framework, the easier it will be to maintain and expand later.

[myconid]

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.

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

Uh, I should remind people that the modelmapping stuff is limited to instanced objects, like buildings and ships but not people or animals!

No doubt I'll get around to adding support for that too in a later patch, but for now I've sort of put it on the backburner because it won't make that huge of an impact visually, but would require hacking of SSE assembly on the CPU side to transform the tangents.

On that note, perhaps it would be worth revising the GPU skinning code to transform animated objects on the GPU and it would remove the need for big changes to the engine...

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?

It would be possible, but I'm doubtful if it would be desirable. SSAO can add haloing artifacts that are most visible on dynamic objects. If we use SSAO, it would be better applied to terrains, but not models. It's really slow, too.

All the same, I'm planning to make a SSAO filter available once I properly add the "Postproc Manager", and we'll see what tricks we can use from there.

I'm thinking whether the best use of SSAO would be for dynamically "baking" a top-down approximation of the terrain's AO at load time/when modified...

[wraitii]

I figure that would be the easiest way to use the SSAO... It could also be used on buildings (modifying their xml to add the baked texture). This would help with modding support, too, as they would not be required to bake the AO themselves.

[zoot]

Okay, so now it ought to be allright.

This is what I am seeing in Atlas:

The temple model looks kind of dark? I haven't messed with the lightning settings.

Grass and parallax works fine.

[wraitii]

It does this only with the temple? Tried deactivating stuffs in the material? (I'm thinking AO/self-light).

Edited July 10, 2012 by wraitii

[zoot]

It does this only with the temple? Tried deactivating stuffs in the material? (I'm thinking AO/self-light).

No, it happens on all models.

[wraitii]

Doesn't happen with me... If you do change the lighting, does anything happen? If you rotate/elevate the sun, does something happen?

[zoot]

The lightning changes on the terrain, but not on the models (as far as I can tell). This is with max sun elevation and overbrightness:

[wraitii]

Could be normals not working, but the parallax works...

I'll look int it, but it works for me.

[myconid]

Wijitmaker, tried your Celt normalmap. It may be a bit too subtle (or, I chose the wrong building to test it on).

Edited July 10, 2012 by myconid

[Wijitmaker]

Uh, I should remind people that the modelmapping stuff is limited to instanced objects, like buildings and ships but not people or animals!

Could it be applied to an unanimated actor just to see what the affect might look like on the unit?

Wijitmaker, tried your Celt normalmap. It may be a bit too subtle (or, I chose the wrong building to test it on).

I'm attaching the black and white elevation map, maybe I didn't convert it correctly - or maybe the brightness and contrast needs to be greater.

Sorry for pestering you so, I'd try it myself but ... well you know that story.

[myconid]

Could it be applied to an unanimated actor just to see what the affect might look like on the unit?

Maybe. I'll have to look into it.

I'm attaching the black and white elevation map, maybe I didn't convert it correctly - or maybe the brightness and contrast needs to be greater.

Ah, ok. Created a new map using a 3x3 Sobel filter, as opposed to the 2x2 filter you used. Using GIMP's normalmap plugin. Still pretty subtle.

http://imgur.com/a/Siwn4

Sorry for pestering you so, I'd try it myself but ... well you know that story.

Don't worry, I don't mind at all. After all, I want to test this as well!

In fact, do you have any other elevation maps I can play with?

[plumo]

@myconid

http://imgur.com/a/Siwn4 too modest, my friend! It is clearly an improvement

I

[myconid]

Wijit, I removed the bones from the Hero model and attached your textures. Here's what I get: http://imgur.com/a/ZsvjU

[zoot]

Yep. Once the artists get their hands on it and can experiment with the normal maps, I think it will look great.

[wraitii]

Myconid, do you believe it would be possible to (at runtime) export an heightmap of the map? I think I could use it in the water shader to start doing some fancy stuff (simulating ray-casting for depth)

Edit: scrap it, it may already be in the game…

Edited July 10, 2012 by wraitii

[zoot]

Myconid, do you believe it would be possible to (at runtime) export an heightmap of the map? I think I could use it in the water shader to start doing some fancy stuff (simulating ray-casting for depth)

Dare I ask what you would use this (water) depth info for?

[myconid]

It's possible, yes. You can access a raw 2D array of vertex heights by using

g_Game->GetWorld()->GetTerrain()->GetHeightMap();

with lineskip being

m_VertsPerSide = g_Game->GetWorld()->GetTerrain()->GetVerticesPerSide();

Values are unsigned 16-bit ints.

What on earth do you need raycasting for??

[wraitii]

I could use it for improving murkiness (calculating actual distance of light underwater), some sort of advanced refraction, and probably would be nice to have overall. It could also fix a rare, but possible bug with water being incorrectly transparent (if you look at the far side of a steep enough island).

Edited July 10, 2012 by wraitii

[zoot]

I could use it for improving murkiness (calculating actual distance of light underwater), some sort of advanced refraction, and probably would be nice to have overall. It could also fix a rare, but possible bug with water being incorrectly transparent (if you look at the far side of a steep enough island).

Cool! I happened upon this page yesterday. They use water depth in a seemingly simple way to do foam (don't know how well it looks, though). Another interesting point they make is about the phenomenon of 'color extinction', which may be related to what you are doing with murkiness.

[myconid]

You don't need real raycasting to calculate that. Here's a clever little algorithm I've come across:

1. First render the terrain.
   
2. Get the depth buffer which tells us the distance between the camera and the ground at each fragment.
   
3. Pass the depth buffer as a texture into the water shader.
   
4. Transform the water plane and calculate the depth value of each vertex, then interpolate with varying.
   
5. We now have the depth of each point on the plane and the depth of each point on the terrain exactly behind it.
   
6. A - B = the distance light travels through water.
   

And what's more, when I implement the Postprocessing manager, the depth buffer will always be available as a texture.

[wraitii]

Very good then... I'll just wait

(and no, I indeed didn't need real raycasting, just some info about the heightmap, or the depthbuffer, though I hadn't thought of that).

Would this (particularly points 4/5) require rendering the water twice?

Edited July 10, 2012 by wraitii