Screenshots!

This is what the current dof shader looks like:

This is what the current bloom shader looks like:

Here is the new dof in action:

And here's a demonstration of bloom. As you can see it looks much more like what you would expect bloom to look like, properly selecting bright areas and softly expanding them without drowning everything else. DOF is of course also visible and you can see that the effects do not clash at all.

And here you can see the smooth transition to blur with the new dof on a more contiguous map.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/397/display/redirect

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/399/display/redirect

In D1454#59519, @vladislavbelov wrote:

I like this at all, but I have important notes:

• Screenshots should be before/after, not just after. Also they all have the pretty same angle, that's not good for any comparison.

I did post some before screenshots, but getting exact before/after shots just isn't practical here because the two versions aren't compatible and the new version has a lot of changes in the cpp code. The 'old' 0ad version I have is kept clean and used only for making patches, and thus also doesn't have any of the same replay files or map edits that I use in my active development build.

• Blur has a noticeable artefacts (because a simple kernel, I suppose), that didn't present for old blur. So it should be fixed, because we try to not make a regression.

What do you mean? The old blur was so ridiculously extreme that you couldn't see anything at all, and that had plenty of artifacts. Virtually all of the artifacts I've seen have either been aliasing or bad art being exacerbated and made more obvious (none of which are caused by my shaders). If you're seeing issues that I'm not due to some gfx card difference then I'll need at least a screen shot to try to diagnose it.

• It'd be good to have a performance comparison tests for it.

Again, difficult to do any direct tests due to the inherent incompatibility in the versions. I could probably do that later but atm it's a pain because I don't want to revert my svn copy right now while I'm working on this and there's a lot of files to copy which is work I don't want to have to do over again :P

• Merge HDR & DOF isn't a good idea, because modders/artists may want to enable them one by one, not together.

Allowing them to be enabled independently isn't really a problem. That could be done just by adding some #ifs and separate user options. I would have done that already but user options aren't exactly my area of expertise. Also again, I don't think artists should be able to tell me whether I can use dof or not, especially since it has negligible effect on art, and they still have full control of bloom through the bloom slider in atlas. Theoretically we could even detect if map bloom is set to zero and disable all the bloom-related components automatically.

Also it'd be good to rename the HDR to a more correct name.

That's a fair point but I'm not entirely sure of what all needs to be updated to make that not break stuff, which is the main reason that I didn't. I'll look into it.

• Why it's called big bloom? And why a param is called bigBlur?

Bloom is split up into two stages, downscaling and blur. "BLOOM_BIG" affects both the downscaling process and the blur, but that particular part of the postproc manager is only concerned with blur. The other function's boolean is called 'filter' because it's only concerned with downscaling and filtering the image. They're basically different things that use the same setting in the shader, and the arg name is descriptive of what those booleans actually do.

• Fix CC.

Do what?

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/402/display/redirect

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/403/display/redirect

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/404/display/redirect

See D1370 for an exemple of Atlas options.

How Postprocessing should work? An artist/modder has the Atlas or a text editor. He/she adds a list of different PP-effects (i.e. bloom, BW, cartoon) to a map and it works together. Effects are like components. So you don't have to do all things in the one file. And it'd be very good to choose an order of effects.

But if you don't know how to do it or don't want to do yourself, you can wait me. I plan to make changes to the Atlas to allow multiple effects with a different order.

In D1454#59593, @vladislavbelov wrote:

You don't need to be compatible. You just need the same position and the same angle of the camera. You can hardcode it, or just use a simple cinemapath.

That'd be a lot of work. Way more than is justified for taking screenshots.

You posted screenshots with blur, hdr and bloom together. So it's harder to review and find issues them all separately.

Taking no-effect/dof-only/bloom-only/both screenshots isn't a big problem. I'll do that today.

Yes, but it can be an artist/modder choice, so you need to give it to then, what's a power of the blur they want.

If artists are going to have any control over dof then it'd be the transition start distance (ie the distance-power factor) and the distance scaling.

I don't suggest to you to make options. I only suggest to separated DOF and HDR shaders.

Combining the shaders into one saves memory write bandwidth and reduces shader/texture setup costs. Given that those things are all expensive I strongly recommend against splitting them up. Applying the effects separately on top of one another would also be a lot more expensive since the blurs would have to be applied redundantly, but would not look significantly different.

So the big word doesn't even present in your description (only as the macro name). So I suggest to call it more meaningful, i.e. downscaledBlur or actualSizeBlur.

The shader setting is now called BIG_BLUR so they're consistent. I removed filtering entirely so that part no longer applies.

The postproc name isn't good for the shader. Because i.e. a BW shader, a film grain are postproc shaders too.

Fair enough. I guess I'll call it dofhdr or something. Also FTR you can get BW just by setting saturation to zero, so that doesn't need to be a separate effect. Also the postproc manager doesn't actually support custom effects. Because everything is hardcoded and afaik there's no JS interface for openGL, there's no way to support custom postproc shaders without changing the engine code.

In D1454#59599, @vladislavbelov wrote:

How Postprocessing should work? An artist/modder has the Atlas or a text editor. He/she adds a list of different PP-effects (i.e. bloom, BW, cartoon) to a map and it works together. Effects are like components. So you don't have to do all things in the one file. And it'd be very good to choose an order of effects.

But if you don't know how to do it or don't want to do yourself, you can wait me. I plan to make changes to the Atlas to allow multiple effects with a different order.

I did that for performance reasons. Also the order of applying dof and hdr has to remain as it is because they use the same blur preprocessing steps so if you apply them as hdr first then dof will cancel out the bloom. The fact that they share preprocessing steps was another motivation for combining them.

Right now custom postproc effects are not actually supported by postproc manager, but that's beyond the scope of this revision.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/409/display/redirect

Screenshots:

no effects:

no effects:

In D1454#59663, @aeonios wrote:

I did that for performance reasons. Combining the shaders into one saves memory write bandwidth and reduces shader/texture setup costs. Given that those things are all expensive I strongly recommend against splitting them up. Applying the effects separately on top of one another would also be a lot more expensive since the blurs would have to be applied redundantly, but would not look significantly different.

Expensive is the pretty relative meaning. The blur is expensive too. How much the combining expensive? We need to choose between usability and performance.

We use the javascript language for the game logic. It's expensive, but it allows many useful things. The blur is expensive too. But it looks good. Deferred rendering is expensive, but it allows to calculate PSM with a higher precision, virtual textures, etc. Raytracing is expensive, but it allows nice AO.

Right now custom postproc effects are not actually supported by postproc manager, but that's beyond the scope of this revision.

It's not actually true, you can customize effects by editing a map file manually.

My point is to allow to artists/modders to freely edit effects. Why? Because if you will profile the game, you will notice, that postproc or final rendering don't cost a lot, the most expensive thing is object submitting. As you noticed we don't use instanced rendering, so we draw a lot of tries/units per different calls. So until we have the completely different bottleneck, we don't need to do optimizations that break usability too early.

The shader setting is now called BIG_BLUR so they're consistent. I removed filtering entirely so that part no longer applies.

But the BIG word doesn't mean something exact. Why not call it as I mention above (actualSize, fullSize, etc)?

In D1454#59832, @vladislavbelov wrote:

Expensive is the pretty relative meaning. The blur is expensive too. How much the combining expensive? We need to choose between usability and performance.

The biggest cost, as with most postproc-type rendering, is in memory bandwidth. Both the blur process and the final combine are shared by bloom and dof. That means the blur process only needs to be performed once for both shaders (and blur can indeed be expensive, as in causes a noticeable slowdown if overused) and the combine can read the screen texture once and write it once for both shaders. Also, as I've mentioned, combining them allows the visual effect to be consistent whether applying just one of the effects or both. There's no loss of usability and you only pay for what you use. However if you use both you get a cost discount. DOF could support customization through atlas (ie distance factor, distance scale kind of like fog), but that's not immediately needed.

We use the javascript language for the game logic. It's expensive, but it allows many useful things. Deferred rendering is expensive, but it allows to calculate PSM with high precision, virtual textures, etc. Raytracing is expensive, but it allows nice AO.

True but getting the best visual effect for a given cost is always good.

Right now custom postproc effects are not actually supported by postproc manager, but that's beyond the scope of this revision.

It's not actually true, you can customize effects by editing a map file manually.

Eh? How? AFAIK you can't actually use custom shaders. You can configure effects that are already supported, but you can't set up custom textures or FBOs or manage the rendering process.

My point is to allow to artists/modders to freely edit effects. Why? Because if you will profile the game, you will notice, that postproc or final rendering don't cost a lot, the most expensive thing is object submitting. As you noticed we don't use instanced rendering, so we draw a lot of tries/units per different calls. So until we have the completely different bottleneck, we don't need to do optimizations that break usability too early.

There's nothing here that prevents map makers from customizing things just as well as they can do already. Well, at the moment they can't turn off DOF but it wouldn't be a large step to allow it and to even make it customizable. That's mostly a matter of atlas though and beyond the scope of this revision. If you give atlas the necessary capabilities I can certainly handle the backend support. This won't be live until at least a24 anyway so we've got time. The way postproc is handled with maps isn't really ideal, and only allowing one effect is rather limiting. Due to how bad DOF was before I don't think there are any maps that use DOF intentionally anyway.

But the BIG word doesn't mean something exact. Why not call it as I mention above (actualSize, fullSize, etc)?

"actualSize" and "fullSize" aren't any more meaningful either. One blur is a 3 tap gaussian blur and the other is a 9 tap gaussian blur. Both are gaussian blurs and both are "actualSize", but one is bigger than the other which is why I named it such.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/453/display/redirect

I always have problems in linux setting an anti-aliasing filtering technique (f.e. mlaa/msaa) on 0ad.

(https://en.wikipedia.org/wiki/Multisample_anti-aliasing)

(With oos drivers f.e. radeon/intel, cuz the global setting environmental variables seems having no effect or are disabled.)

Maybe we could make some option here too in 0ad code directly and give option.

(same for anisotropic filtering.)

Need to correct my statement. Anti-Aliasing support with opensource drivers (mesa) sometimes has changes or problems in its releases or/and maybe combined with some distro packages (here Ubuntu 16.04) to enable this feature. With updated mesa stack (to the newest) anti-aliasing now works via dri. Just adding this statement.

In D1454#60564, @ffffffff wrote:

Need to correct my statement. Anti-Aliasing support with opensource drivers (mesa) sometimes has changes or problems in its releases or/and maybe combined with some distro packages (here Ubuntu 16.04) to enable this feature. With updated mesa stack (to the newest) anti-aliasing now works via dri. Just adding this statement.

Anti-aliasing is a separate issue from this revision. Eventually I'll probably get around to that, too.

I think this might need some atlas touchups, and I'd rather backwards-compatibility be created by changing map settings rather than hardcoding it.

In D1454#60581, @wraitii wrote:

I think this might need some atlas touchups, and I'd rather backwards-compatibility be created by changing map settings rather than hardcoding it.

I'd prefer to have the atlas part be done with a separate revision, but that was already the plan. There are already hooks for enabling or disabling it based on an option, which could be a user option or a map setting. Right now the way map settings work doesn't allow for more than one postproc technique to be specified, so that will require a significant change to the way that works. DOF could also potentially be configurable, but basically same deal.