Graphics Improvements

[aeonios]

It's been a while since I've done any work on this but I've actually had quite a few improvements that I've made locally that I never made patches for. I had to update to the latest development snapshot but now I'm starting to push my backed up changes to trac.

Some of the things I've got coming up:

Shadow Filtering

I replaced the old box filter with an 8 sample poisson disk filter. This should yield significantly smoother shadows with soft edges.

Depth of Field

The existing dof shader is unusable. The blur it uses is not correctly implemented and it tries (and fails miserably) to approximate a camera's focal distance, which isn't terribly appropriate for an RTS. I made a much simpler dof shader that just interpolates with a blurred/downscaled version of the screen image based on depth to approximate the focal behavior of the human eye. It basically softens far away objects slightly. It's subtle but noticeable, works properly, and is also a lot cheaper to apply than the current filter.

Water

As a minor tweak to my previous work on the water shader I increased the contrast of water reflections to accentuate shadows a bit more. Currently objects reflected in water tend to have a "washed out" look due to the lack of contrast. This will simply color balance them a little better.

[vladislavbelov]

43 minutes ago, aeonios said:

I replaced the old box filter with an 8 sample poisson disk filter. This should yield significantly smoother shadows with soft edges.

If make the shadow more expensive, we can use moment shadow maps.

44 minutes ago, aeonios said:

The existing dof shader is unusable. The blur it uses is not correctly implemented and it tries (and fails miserably) to approximate a camera's focal distance, which isn't terribly appropriate for an RTS. I made a much simpler dof shader that just interpolates with a blurred/downscaled version of the screen image based on depth to approximate the focal behavior of the human eye. It basically softens far away objects slightly. It's subtle but noticeable, works properly, and is also a lot cheaper to apply than the current filter.

That's good, but our blur is pretty simple (just a linear), it'd be good to replace it by the Gauss one.

46 minutes ago, aeonios said:

As a minor tweak to my previous work on the water shader I increased the contrast of water reflections to accentuate shadows a bit more. Currently objects reflected in water tend to have a "washed out" look due to the lack of contrast. This will simply color balance them a little better.

It's pretty hard to make the water realistic and beautiful at the same time, especially without real references (i.e. the contrast). Also did you use my patch for the water vertex shader fix? Because the current one is broken, so the specular light is calculated wrong for heights != 15.

It'd be good to have screenshots to compare before/after states.

[aeonios]

9 minutes ago, vladislavbelov said:

If make the shadow more expensive, we can use moment shadow maps.

Filterable shadow maps are a lot more expensive than pcf filtering. I did a lot of testing using the intel shadow explorer and that was my basic conclusion. Filterable shadow maps also create nasty light bleeding artifacts that are unavoidable if you actually use any filtering. I had considered even implementing PCSS for real soft shadows since I know how to make that exceptionally cheap, but doing that in openGL is a lot harder than in direct3D and I honestly have no idea how to make it work. At the very least it'd require upgrading the shaders to GL3.x.

It's not much more expensive than the existing filter at any rate.

13 minutes ago, vladislavbelov said:

That's good, but our blur is pretty simple (just a linear), it'd be good to replace it by the Gauss one.

I did replace the box filter with a simple 1px gaussian blur as well. I'm also considering merging the HDR and DOF shaders into one and having them be always active as long as postproc is enabled. Not only is it easy to do but since the two shaders read the same textures at the same positions the memory locality would be high so the cost of applying both effects rather than just one or the other is minimal. Also I don't think map makers should be able to tell people what postproc effects to use. If you check the 'postproc' box under graphics you don't generally expect to get nothing for it, and mapmakers already have all the hdr sliders that they can use to adjust bloom and such (to nothing at all, if desired).

17 minutes ago, vladislavbelov said:

It's pretty hard to make the water realistic and beautiful at the same time, especially without real references (i.e. the contrast). Also did you use my patch for the water vertex shader fix? Because the current one is broken, so the specular light is calculated wrong for heights != 15.

No but my patch doesn't touch the vertex shader. I don't know anything about that.

19 minutes ago, vladislavbelov said:

It'd be good to have screenshots to compare before/after states.

The map editor is broken in the current git snapshot, which makes it difficult to get good screenshots. I can't seem to manage to adjust the camera angle in game to take low angle shots from replays.  I'm working on it anyway. I'll probably do that once I've finished testing and pushing the dof/hdr changes to trac.

[vladislavbelov]

4 minutes ago, aeonios said:

At the very least it'd require upgrading the shaders to GL3.x.

It's not possible yet, because we don't drop GL2 yet. But it'd be good to have a switchable renderer in the future.

5 minutes ago, aeonios said:

The map editor is broken in the current git snapshot, which makes it difficult to get good screenshots. I can't seem to manage to adjust the camera angle in game to take low angle shots from replays.  I'm working on it anyway. I'll probably do that once I've finished testing and pushing the dof/hdr changes to trac.

What's broken? It doesn't run? You can make screenshots from the game.

6 minutes ago, aeonios said:

No but my patch doesn't touch the vertex shader. I don't know anything about that.

https://code.wildfiregames.com/D1402

7 minutes ago, aeonios said:

I did replace the box filter with a simple 1px gaussian blur as well. I'm also considering merging the HDR and DOF shaders into one and having them be always active as long as postproc is enabled. Not only is it easy to do but since the two shaders read the same textures at the same positions the memory locality would be high so the cost of applying both effects rather than just one or the other is minimal. Also I don't think map makers should be able to tell people what postproc effects to use. If you check the 'postproc' box under graphics you don't generally expect to get nothing for it, and mapmakers already have all the hdr sliders that they can use to adjust bloom and such (to nothing at all, if desired).

The current postprocess isn't completed. I.e. we can't select multiple effects. Also HDR isn't actually HDR, it's usual LDR, but with color corrections. We need to use R10G10B10F or RGB32F for true HDR.

8 minutes ago, aeonios said:

Filterable shadow maps are a lot more expensive than pcf filtering. I did a lot of testing using the intel shadow explorer and that was my basic conclusion.

Any filtering is noticeable under a low hardware. It'd be good to know you hardware and some charts to compare results. I'd like to see MSM.

[Stan`]

One could have a look at: This that's a hzcky ogl4 implementation for 0ad

Also Maybe we could use glew to get rid of those versions considerations Here

[asterix]

Hi,

thank you for your hard work you may also upload your work here https://code.wildfiregames.com for review. Maybe you can be interested https://trac.wildfiregames.com/ticket/4734 because almost no one knows how to solve it and we have constant reports about similar issues (actually some shader might be corrupted). 

[aeonios]

35 minutes ago, vladislavbelov said:

It's not possible yet, because we don't drop GL2 yet. But it'd be good to have a switchable renderer in the future.

Not really an issue, but I don't think the shader cares what version of GL is being used by the game anyway.

36 minutes ago, vladislavbelov said:

What's broken? It doesn't run? You can make screenshots from the game.

Yes it doesn't run. That's a pain because it prevents me from making good test maps to demonstrate the difference. I still need to figure out how to adjust the camera in game to get low angle shots. I don't know the specific error though. I'd have to dig around to figure out where that's recorded.

37 minutes ago, vladislavbelov said:

https://code.wildfiregames.com/D1402

This does seem to be an improvement. I need to reduce the reflection wobble to account for that though, because it ends up being ridiculous. I wonder if this fixes the black water issue that occurs with high waviness ocean waves at certain wind angles.

1 hour ago, vladislavbelov said:

The current postprocess isn't completed. I.e. we can't select multiple effects. Also HDR isn't actually HDR, it's usual LDR, but with color corrections. We need to use R10G10B10F or RGB32F for true HDR.

True HDR can be done with RGB16F as well, which is my preferred format. HDR doesn't make sense for 0ad though because there aren't any stacking projectile lights or anything that would cause the brightness to exceed 1.0. IMO you shouldn't need to select effects anyway. I'm not really aware of any other postproc effects that would be good for 0ad, and the ones we've got are probably best combined. I've been testing that but it's difficult without the ability to adjust map settings to compensate for the changes or to eliminate interfering factors like fog.

1 hour ago, vladislavbelov said:

Any filtering is noticeable under a low hardware. It'd be good to know you hardware and some charts to compare results. I'd like to see MSM.

I'm running an old core i3 2120 with 4GB of DDR3 RAM and an nvidia 240GT with 1GB of DDR3 RAM. It's literally the cheapest gfx card you can buy. The in-game fps meter shows 30-50fps pretty consistent even with all the bells and whistles I've been working on turned on, and the general responsiveness is good.

 

1 hour ago, stanislas69 said:

One could have a look at: This that's a hzcky ogl4 implementation for 0ad

Also Maybe we could use glew to get rid of those versions considerations Here

I'm not a big fan of GL4. There are some interesting things you can do with GL4.x but none of those things really apply to 0ad. Occlusion culling is pretty useless in 0ad since basically nothing is ever occluded to get culled, and fancy stuff like motion blur is kind of pointless. I don't really know how to mix shadow sampling modes in GLSL without copying the shadow map anyway, if it's even possible.

[Stan`]

18 minutes ago, aeonios said:

Yes it doesn't run. That's a pain because it prevents me from making good test maps to demonstrate the difference. I still need to figure out how to adjust the camera in game to get low angle shots. I don't know the specific error though. I'd have to dig around to figure out where that's recorded.

What OS are you running ?

20 minutes ago, aeonios said:

I'm not a big fan of GL4. There are some interesting things you can do with GL4.x but none of those things really apply to 0ad. Occlusion culling is pretty useless in 0ad since basically nothing is ever occluded to get culled, and fancy stuff like motion blur is kind of pointless. I don't really know how to mix shadow sampling modes in GLSL without copying the shadow map anyway, if it's even possible.

I believe the idea behind the switch was this : https://trac.wildfiregames.com/ticket/3054

Isn't there any performance gain to switch to ogl4 when possible ?

[aeonios]

4 minutes ago, stanislas69 said:

What OS are you running ?

Win7

4 minutes ago, stanislas69 said:

I believe the idea behind the switch was this : https://trac.wildfiregames.com/ticket/3054

Isn't there any performance gain to switch to ogl4 when possible ?

Not really. Most of the performance improvement comes from various rendering functions that reduce the number of draw calls, and all of those are present in GL3.x. The speedups that are possible with GL4.x don't really apply to 0ad since the situations that would allow such speedups simply don't occur. For reference my bargain gfx card supports GL3.3.

Edited April 15, 2018 by aeonios

[Stan`]

Did you try recompiling Atlas ? You'll need to download and compile wxwidgets for that.

Then making the switch to OGL3 would be nice

[aeonios]

21 minutes ago, stanislas69 said:

Did you try recompiling Atlas ? You'll need to download and compile wxwidgets for that.

Then making the switch to OGL3 would be nice

Ah wxwidgets. I totally forgot about that. GL3 would also make soft particles practical, which 0ad badly needs.

[Stan`]

Ah I know why ! Since you cloned the repo you didn't get binaries so you had to build it yourself. By default Atlas is not enabled you have to pass --atlas in the premake script (update workspaces.bat)

(You could also download the SVN dll)

As always patches are welcome

[aeonios]

Yeah I got it. I built wxwidgets the last time I cloned the repo but that was a good while ago so I forgot. I'll just copy over wxwidgets from my old repo and then rebuild.

edit: correction, I'm going to have to update and rebuild wxwidgets because the version I'm using is outdated and atlas needs newer. :[

Edited April 15, 2018 by aeonios

[vladislavbelov]

1 hour ago, aeonios said:

Not really an issue, but I don't think the shader cares what version of GL is being used by the game anyway.

Shaders don't, but a video driver does. I.e. we still support Intel video cards, which can have a version 3.0 or lower, that doesn't have many nice features.

1 hour ago, aeonios said:

I don't really know how to mix shadow sampling modes in GLSL without copying the shadow map anyway, if it's even possible.

I wanna change the current shadow mapping way, because for low angles we have a low resolution per terrain unit. I'd like to use PSM or CSM, and I'm more near to CSM, i.e. 2 cascades.

1 hour ago, aeonios said:

True HDR can be done with RGB16F as well, which is my preferred format. HDR doesn't make sense for 0ad though because there aren't any stacking projectile lights or anything that would cause the brightness to exceed 1.0. IMO you shouldn't need to select effects anyway. I'm not really aware of any other postproc effects that would be good for 0ad, and the ones we've got are probably best combined. I've been testing that but it's difficult without the ability to adjust map settings to compensate for the changes or to eliminate interfering factors like fog.

I agree about HDR. Also we don't have deferred rendering yet. About formats RGB16F or RGB32F has enough precision, but it's expensive. So if R11G11B10F will be enough, then we have to use it. Because it's 4 times cheaper.

1 hour ago, aeonios said:

The in-game fps meter shows 30-50fps

FPS meter isn't enough, we need to use more strict tests. Because the FPS meter has a noticeable error.

 

[Stan`]

10 minutes ago, vladislavbelov said:

FPS meter isn't enough, we need to use more strict tests. Because the FPS meter has a noticeable error.

For the record it's also broken in Atlas.

About lighting I'd like to have working torches and explosions at some point doing light. Glowing windows too.

[aeonios]

28 minutes ago, vladislavbelov said:

Shaders don't, but a video driver does. I.e. we still support Intel video cards, which can have a version 3.0 or lower, that doesn't have many nice features.

Well yeah, it'd break 2.x support.

28 minutes ago, vladislavbelov said:

I wanna change the current shadow mapping way, because for low angles we have a low resolution per terrain unit. I'd like to use PSM or CSM, and I'm more near to CSM, i.e. 2 cascades.

Cascades are awful and don't even do what they're intended to. If you want something like that then lightspace perspective shadow mapping is a far better solution, but it makes shadow filtering trickier due to the non-constant scaling. Cascades just turn the shadow map code into unreadable unmanageable spaghetti, and are also expensive for little to no benefit. Unit cube clipping would also be nice for shadows, as I don't think we're doing that already. I haven't really implemented any of that myself though so I don't know how to make it work. It also requires depth prepass.

28 minutes ago, vladislavbelov said:

I agree about HDR. Also we don't have deferred rendering yet. About formats RGB16F or RGB32F has enough precision, but it's expensive. So if R11G11B10F will be enough, then we have to use it. Because it's 4 times cheaper.

R11G11B10 is kind of bad since it results in undesirable hue shifts, in particular yellowing. If there's a 10/10/10 format that'd be better, but as I said we have no real use for HDR and if we did then a 10b format would probably not have sufficient bits of precision. Trust me, I've done work with that and there were overflows that resulted in some really weird artifacts. Of course you can fix that by conditionally applying tone rescaling during lighting but I dunno if you can get away with less than 16 bits even then.

Again though, that's not anything we have real use for since we're not stacking lighting so we'll never see >1.0. Real HDR is seriously overrated even for bloom, and bloom looks better when it's applied in LDR anyway.

Deferred rendering is also only useful if you're using lots of lights, and forward+ is generally better since it lets you use MSAA and translucency. I don't see much case for having tons of lights in 0ad, although there are more than zero cases of flaming projectiles that could possibly use dynamic lights it's not exactly something common.

28 minutes ago, vladislavbelov said:

FPS meter isn't enough, we need to use more strict tests. Because the FPS meter has a noticeable error.

I also did some camera responsiveness tests for comparison and didn't notice much difference between filtering and no filtering.

Edited April 15, 2018 by aeonios

[asterix]

@aeonios maybe you can also try and review https://code.wildfiregames.com/D1401 or https://code.wildfiregames.com/D1381 if you have some time, @stanislas69 would be grateful.

[vladislavbelov]

1 hour ago, aeonios said:

Cascades are awful and don't even do what they're intended to. If you want something like that then lightspace perspective shadow mapping is a far better solution, but it makes shadow filtering trickier due to the non-constant scaling. Cascades just turn the shadow map code into unreadable unmanageable spaghetti, and are also expensive for little to no benefit. Unit cube clipping would also be nice for shadows, as I don't think we're doing that already. I haven't really implemented any of that myself though so I don't know how to make it work. It also requires depth prepass.

I agree, that the code isn't the best for CSM, but performance looks better in a comparison with the current one. Some AAA games like it (i.e. JS3). Also CSM has square/rectangle pixels, so it's more nice shape of the pixel.

I like PSM, but it has a worse shape, and sometimes there are glitches. @stanislas69 already noticed visual errors with a rotating camera for the current algorithm.

About performance, I suggest do not say much words without tests.

1 hour ago, aeonios said:

R11G11B10 is kind of bad since it results in undesirable hue shifts, in particular yellowing. If there's a 10/10/10 format that'd be better, but as I said we have no real use for HDR and if we did then a 10b format would probably not have sufficient bits of precision. Trust me, I've done work with that and there were overflows that resulted in some really weird artifacts. Of course you can fix that by conditionally applying tone rescaling during lighting but I dunno if you can get away with less than 16 bits even then.

I agree about errors. But, it's cheaper, and with clever packing it works good. I.e. JS3 mentioned above (I need to find a ref). I trust your results, but there're AAA examples. So, again, tests and tests.

1 hour ago, aeonios said:

Deferred rendering is also only useful if you're using lots of lights, and forward+ is generally better since it lets you use MSAA and translucency. I don't see much case for having tons of lights in 0ad, although there are more than zero cases of flaming projectiles that could possibly use dynamic lights it's not exactly something common.

Some modders and artists wanted to have many lights (i.e. arrows, torchs). Deffered rendering allows you to use MSAA too, but with a different cost.

 

[fabio]

For reference there was a related discussion a couple of years ago here.

[aeonios]

I just got finished tuning up the new combined postproc shader. I posted some screenshots up here: https://code.wildfiregames.com/D1454

It's pretty epic.

[Stan`]

@aeonios By the way thanks for your work so far. It's nice to have someone else doing graphics programming.

[av93]

2 hours ago, stanislas69 said:

@aeonios By the way thanks for your work so far. It's nice to have someone else doing graphics programming.

If I can ask for something, Antialiasing, please! Thx for the work already done.

[vladislavbelov]

2 minutes ago, av93 said:

If I can ask for something, Antialiasing, please! Thx for the work already done.

Currenlty FXAA doesn't work perfect for the 0 A.D., but TXAA or MSAA may solve the problem.

FXAA:

[Sundiata]

I barely understand what's going on here... But I like it! 

I love how the dof comes into its own now..

Edited April 16, 2018 by Sundiata

[Stan`]

Don't forget to allow users to disable it