[ExtraFPS] Release Candidate defaults to Khronos for tone mapping breaking existing EEP and Content in PBR/Non PBR
tracked
S
ScarletCreativeAdmin Resident
- The new Release Candidate is defaulted to Khronos for tone mapping.
- Content created in the last 12 months using ACES tone mapping is excessively impacted as a hard break of the tone mapping changes, particularly EEP settings created for both Firestorm, and LL Viewers.
- Values are blown out on the higher end of ranges making non greyscale colours not compatible with existing content on EEPs and dampening at an excessive level when colour introduced to sun, clouds etc.
- Can we default the Release Candidate back to ACES under advanced settings, so users can gradually update their own defaults to Khronos over a period of months. This soft break to content will allow creators to adjust new content and have a soft alignment of old content into the new tone mapping.
Examples of screenshots showing the impacts can be found on thread - > https://community.secondlife.com/forums/topic/517003-khronos-tone-mapper
Log In
Atlas Linden
tracked
Atlas Linden
Hi Scarlet,
We already have this in the works to reset it back to ACES here: https://github.com/secondlife/viewer/issues/2913. And as mentioned by Crexon, the ability to change it is in Advanced Graphics Preferences.
Crexon Resident
This was already addressed. The purpose of making it default in a beta/RC build is so people will get to see the new option and provide feedback. If it wasn't, it would likely go unnoticed for months(theres a long track record of this happening)
ExtraFPS now defaults to ACES, and under Advanced Graphic Settings you can switch there from ACES or Khronos Neutral and the mix of the tonemapper. Likly this is just a place holder for the location to change as more tonemappers are looking to be added such as the AMD one from their GPUOpen project and others that might offer different stylizations. It was discussed to maybe moving the tonemapper setting to ether land settings or part of EEP, but those were only ideas now.
Also the concern of "breaking current EEP" theres already tons of user settings in the viewer that will drastically change how an EEP looks, before this different tonemapper. Example in Alchemy we have 4 different tonemappers, soon 5 once Kronos gets added and 20+ different colorgrades that all change how an EEP looks.
S
ScarletCreativeAdmin Resident
Crexon Resident ... Discussed with whom?
Also when promoted to RC it was as is so the feedback is on that basis.
+ We do need this linked into EEP, there is another request on that which makes that a more sensible outcome and more sense than advanced settings and is a more robust outcome for all concerned.
I would like to ask Atlas Linden - What is the driver and user cases along with benefits for multiple tone mappers - what does it offer users (beyond photography and videography "filters"). We are creating significant variability so I would like to understand why and purpose as many of us do not see this as value add.
Also what drove Khronos, can there be a blog post to share the thinking and strategy.
Kyle Linden
ScarletCreativeAdmin Resident please allow me to answer for Atlas on this one.
Release Candidates are just that, 'candidates' which do not commit new features and changes to Second Life until we have the information and feedback we need to feel confident for release.
In this case we experimented with Khronos neutral tone mapper as a default in the ExtraFPS RC and received feedback that it was undesired. We listened and have switched back to ACES as the default.
A blog post is warranted, especially since we cannot expect this Feedback system to be the place we share news. Please look for new blog posts about future viewer releases. Thanks!
S
ScarletCreativeAdmin Resident
Kyle Linden. - Hi Kyle, super appreciate that and the intel/info!
- Feedback on RC features/testing - can you point me to the correct location where we do that (as I used here since JIRA went so apologies!!). Also so I can read what feedback is being given on RC's so I don't duplicate feedback/concerns cause unneeded effort to things you already are aware of.
- Thanks on blog that's great to hear!!
Andred Darwin
Plus 1 to all these requests.... but, increasing the default exposure to 1.5 ( https://github.com/secondlife/viewer/issues/2916 ) is not the "fix" either using ACES... even in RL, when would you raise exposure during sun light? ( Maybe for night pictures we do that... actually phones today do that automatically for "really" low light scenes, the viewer goes nuts with that auto-exposure).
The fix that probably makes sense for dark, is to use lights... either point lights, or for nights scenes add moonlight to EEP. Also... if the old viewer will stay for a while, would make sense to tweak the code of such viewer to handle EEP's made for PBR (Ambient Color set to black, and Reflection Probe Ambiance > 0 ).... that way its not so dark when arriving with old viewers. That would allow users that need or want to use the old viewer to continue to enjoy it and still be able to at least see scenes with PBR EEP's, without screwing with PBR rendering.