Inspired from rP21882? There are 90 more where that came from, including this one.

In D594#24518, @elexis wrote:

Ok to add the missing ones, even if not all of them seem needed. I'd prefer to wait after the release, so that we don't lose the translations of the existing strings for now.

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

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

Closing this. It's gotten so entangled with shadows that I'm just going to merge the two revisions.

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

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.

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

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

I reduced the big blur from 9 taps to 5 taps, which when using linear sampling uses the same number of samples as the 3-tap small blur. This allowed me to simplify the code by reusing the same code for both 3-tap and 5-tap blurs and just changing the offsets and weights. Visually you can't really tell the difference. I also reinstated using all 3 blur textures for bloom, since the smallest blur texture increases the sharpness of the bloom and makes it look a little better. Since that texture is already being sampled by the shader as long as dof is enabled it adds exactly zero overhead one way or the other.

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.

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.

no effects:

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

Naming/whitespace tweaks.

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.

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.

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.

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.

See D1370 for an exemple of Atlas options.

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

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

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

whitespace

Fixed the bit at line 690 in map reader.

Ok so I got around to dealing with compatibility issues. The way maps interact with postproc is kind of a pain but I made it work as sensibly as I could.

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 like this at all, but I have important notes:

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

Added spaces to the for blocks, converted '5' into a constant.