Look at these two screenshots:
http://puu.sh/txuXZ/ed4e17e79c.png
You see that by multiplying the blue color, it becomes purple.
In earlier engine versions it stays blue and just gets a lot of bloom.
can vouch that this works in 4.11 (it stays blue instead of purple)
Hey John,
Thank you for submitting this post. I have reproduced this issue and logged a report for it here: Unreal Engine Issues and Bug Tracker (UE-41065)
You can track the report’s status as the issue is reviewed by our development staff. Please be aware that this issue may not be prioritized or fixed soon.
Cheers,
Can confirm the same issue here.
Iiiii was about to ask the same thing…
Hey Ed,
Issue is now marked “By Design”. Can you explain how can this be like this by design? For example, how multiplying 0 by any value can be anything but 0? I don’t really get the math here.
I’m following up with a couple of the developers to see if this was, in fact, a deliberate change. If it wasn’t we’ll re-open the ticket for investigation, if it is I’ll provide some context to the ticket that has been marked as “by design.”
, everyone!
Someone on Discord suggested it’s a consequences of transition to Academy Color Encoding System (ACES) HDR color rendering.
I’ve updated the ticket with information about this.
This is a deliberate change where we now use r.TonemapperFilm 1 instead of 0 by default. You can get the old behavior by switching back to 0.
Look for more information about this change in our Release Notes for 4.15.
No wonder many people frustrated:
the “new” tonemapper setting is actually ignoring all the tonemapper settings in the PP volume
Roses are purple, violets are red. And the blue don’t exist anymore.
Check out the public notes on the JIRA ticket. They describe in a bit more detail why this change is intentional and tell you what Cvar to change to get the old behavior.
I suspect my problem with an emissive material in 4.15 Pre is linked to this:
There is not the same “blooming glow” as in 4.14, even after I enter the recommended console command r.TonemapperFilm 0 to get the old behaviour.
Scenario: Blank Project in 4.14 and 4.15, a single cube with the following simple material:
This is what it looks like in 4.14:
And this is 4.15 after console command r.TonemapperFilm 0:
Any hints, please?
This isn’t a bug. The default bloom settings have been modified in 4.15 to give a more physically accurate result. You can still change the settings to suit your needs.
I wonder if I am the only one who appreciates these color/bloom/emissive/tonemapper changes.
I feel for you Ed, having to explain it over and over.
Thank you very much for your quick reply, and sorry if this was obvious, but the only info I got from the ticket and various threads was to set r.TonemapperFilm to 0 to achieve the old behaviour, I wasn’t aware that other settings have to be tweaked as well.
I assume all these changes and settings will be laid out in more detail in the major release notes and will wait for them.
You’re not the only one 
Yup. I have access to our internal documentation so it isn’t a problem. You will find all of this info in the 4.15 release notes once it goes public. 
I don’t mind pointing things like this out. Actually, it is better that our community is so vigilant about finding changes that could possibly be bugs in the engine.
We have already logged dozens of issues with the previews because of our users. Keep up the great work guys!
How do I get my emissive blue and red back?? If this is intentional I feel like maybe they are colorblind :). Blue becomes purple and red goes orange. Its very weird because logically for me at least the old way made way more since.