Tonemapper Issues in 4.15

Hey guys

First of, you’re already aware of that issue Unreal Engine Issues and Bug Tracker (UE-41065)

So I’ve compared Tonemapper settings between 4.14 and 4.15 and noticed that r.TonemapperFilm is forced in 4.15 and enabled by default which is breaking compatibility for all previous projects and requires changing a lot of stuff. Okay. But what about removing other Tonemapper options? Why we can’t have them? Here is a list of commands removed from 4.15:

  • r.Tonemapper2084
  • r.Tonemapper709
  • r.TonemapperACESInversion

So far this update forces new standard upon users and removes alternatives. Can we at least have these options back?

Thanks.

You should be able to do “r.Tonemapper Film 0” and then you are back to the old one. Not sure about those commands though, if they are removed and you needed them, that’s sad.

I support this, cause this is just impossible to make even blue

https://dl.dropboxusercontent.com/u/28070491/GIFGOLD.gif

@Zeorb

These settings have been lumped into other categories such as r.HDR* contains a lot of these now, not that they can be specifically set like they were in with the r.Tonemapper commands, though.

Largely, these cvars were considered experimental and likely to change, even if this wasn’t explicitly said before.


@Hevedy

This is a completely separate issue involving selection highlight with skeletal meshes in Blueprints. This can be seen in 4.14 as well. If you deselect the arrow the color is correct. If you add a Skeletal Mesh the color is the same as the arrow except without selection outline.

Can you please post this as a new Bug Report and we’ll follow up there.

Thank you!

Tim

Well not sure what you mean with the skeletal meshes but you’re correct at select other entitie no the arrow it back to the normal color thanks sir.
Anyway the color you select and the display one even with or without sRGB is not equal.

It never ceases to amaze me how stupid some of the decisions made on these builds are.
People spend months delicately adjusting lighting, PP, and materials to work harmoniously together.
Then some person at epic decides “I want it my way” and Boom months of work down the drain.

How many people know to add r.TonemapperFilm=0 to the DefaultEngine.ini ?
Not many and those that do know also know how to change the tonemapper; but wait that’s too easy so epic change the console commands too.

Ok so after a bit of digging you find out the new commands and now you just need to fix the bloom…. But the guy at epic who wanted it his way, doesn’t care about the thousands of people working on their projects, so there is no backwards compatibility on the bloom, it’s changed and that’s it, go fix your hundreds of MATs, INST PP, Lights etc. It’s not really a big deal is it? Its just the whole look of your projects and thousands of hours.

My Advice is don’t touch your mats, this will be put back in 4.16 when they either realise the damage they done, or the project their working on has passed.

Well, let’s hope you are right!

Unfortunetly it dosent work as console comand you need to restart for that

Did this ever get addressed? I’m having issues with blue…

Regards,

Chris

EDIT: (4.16)

@Ketojon - I totally agree, it was a silly thing to change. It had the result of making our world look super high contrast to the point it was actually hard to play. Obviously disabling the ‘r.TonemapperFilm’ isn’t hard, but if you didn’t know about that feature you’d probably just assume your post process settings had gone haywire, and you could easily burn several hours or days trying to fix them. Bad stuff, Epic.

I am now on 4.17 and this dark/hi-constrast issue with tonemapper is still present. Im having trouble with packaging on 4.14 version, and cant fix that, so Im trying to go around and open a project in version 4.15, 4.16 or 4.17 and everything looks soooo dark. Spend two whole days traying to set lighting but still cant get the previous results.

Same problem. Persists in 4.18.3.