[feature request ]Better bloom.The actual one looks quite bad and there isn't so much control.

Actually it looks all but realistic just very dreamy.

Guess it could be replaced with a better shader with a similar cost or with an implementation that can scale up and down in quality tweaking some params even better if it could be customized to get some kind of distinctive looks.

I did some research in the code to understand why It doesn’t show so good.

Reading it I also discovered a bug that could be easely fix,but just makes it a little bit better.

It looks like the bloom is hardcoded for 16:9 screen resolutions this makes bloom deform on any other screen resolution (I immagine what on mobile with portrait orientation it looks very oval)

file is


 int width = CTexture::s_ptexHDRFinalBloom->GetWidth();
int height = CTexture::s_ptexHDRFinalBloom->GetHeight();
// Note: Just scaling the sampling offsets depending on the resolution is not very accurate but works acceptably
CRY_ASSERT(CTexture::s_ptexHDRFinalBloom->GetWidth() == CTexture::s_ptexHDRTarget->GetWidth() / 4);
float scaleW = (static_cast<float>(width) / 400.0f) / static_cast<float>(width);
float scaleH = (static_cast<float>(height) / 225.0f) / static_cast<float>(height);
int32 texFilter = (CTexture::s_ptexHDRFinalBloom->GetWidth() == 400 && CTexture::s_ptexHDRFinalBloom->GetHeight() == 225) ? nTexStatePoint : nTexStateLinear;

these 400 and 225 hardcoded numbers are probably based on 1600 / 4 and 900 / 4 indeed the only resolution that also makes the texture filtering switch to point sampling.

these 400 and 225 need to be replaces with width and height divided by 4 as the buffer is 1/4 x 1/4.

The switch to point sampling can be completely eliminated as also it just apply to that 1600x900 resolution and even there doesn’t make so much sense as blur needs bilinear filtering.

This implementation doesn’t leverage bilinear filtering in a good way samples are offsetted bi a fixed value based on how the actual resolution fits with the hardcoded one (so almost random) a proper implementation need a proper array of offsets based on the weight of any sample.


I checked more in the code and then discovered few things that made me change my mind on the direction i was taking.

  1. downsampling with hi qality 1 and 2 is just the better version i was looking for it was just in another file I wrongly assumed it used always the naive one (the one it uses at quality 0).

I’m fighted about the insertion of a threshold for the bloom have to plan where to do it and at least time of day system is not very helpfull about easely adding new parameters so I’m just repurposing some.

An additional note on mobile is that it probably needs a completely different shader that calculates coordinates in vertex shader to not make dependent texture reads that are detrimental on some mobile gpu.


In the engine some shaders have just this kind of optimization so possibly it is ongoing.

Interesting find.

today I fixed the aspect ratio issue tested with additional pass at 1/8 but it needed a rebuid ( to add the render targets to texture.h) :frowning:

Also sampling offsets seems to be better infact is quite big and smooth, also added blue stuff but it actually tends to violet.Now everything look a bit less dreamy.

Apart from bloom the post on this shots have features a quite different tonemapper possibly faster(but uses different parameters so the curve in time of day is totally off) and vibrancy(just a test).

For now I can consider the bloom done I will try to extract the changes to contribute them back when 1.8 will be released.

Made a post 5 minutes ago but it disappeared :frowning:

Made lot of changes to bloom and post processing in general added new tonemapper , vibrancy , different auto exposure blueshift(looks too violet in these shots need to fix it).

Bloom aspect ratio has been fixed fixed the sampling offsets and did the second step at 1/8 in shots is strong but not so big you can also make it softer and bigger.

It also looks less dreamy than before.

I may contribute the changes to 1.8 when I will figure out how to extract things from the other modifies i made that breaks normal time of day use.

Wow, very cool!

I have just started to read shaders,but believe they really need some attention as the code is not very clean and there are at least few lines completely redundant.

There are shaders that read back and decode the entire gbuffer just to use a single attribute, some vector4 operation just to get one scalar, nothing crazy from performance point of view as possibly the shader compiler makes proper optimizations , but breakes readability).

Hi Binky welcome back, i’m still waiting for a better way to contribute the changes I have seen that also other people asked for some kind of public repository.meanwhile I’ll try to describe the changes there.

I know this is on the list of things for the roadmap. Shader optimization. These examples help and I’ll forward to the team.

Thanks! Right now the forums are the only way to submit code (ugh). We are working on some additional options and it is a high priority for us from a community perspective. Hang tight for just a little longer.