* #3103 Add the ability to disable the emissive buffer for older GPUs with low memory bandwidth.
* #3135 Add a "vintage" mode for slower GPUs
* #2719 Fix for skies being overbrightened
* #2632 Do not apply tonemapping on legacy skies
Obvioulsy, there has been a typo done when copying WL default sky parameters to EE ones.
This causes "static" and quite unrealistic clouds when this default setting is used as a
base for a new sky setting, and we see this bad static sky resurfacing now with PBR and
its "adjusted" (more like hacked, but this is another story) mid-day sky setting.
Let's fix this typo once and for all in LL's code base (most TPVs have it fixed already,
and this ever since EEP got released).
@LL: please also fix the cloud scroll rate in the PBR mid-day inventory setting accordingly.
This was a longstanding complaint: that Boost shouldn't dump the (somewhat
mysterious) _1, _2 et al. names into the global namespace. Recent Boost has
fixed that, requiring 'using namespace boost::placeholders;' if you want to
use them unqualified.
Hack for desaturating legacy materials has been removed for performance and quality reasons.
Adds a new setting for auto adjusting legacy skies. This is the PBR "opt out" button. If disabled, legacy skies will disable tonemapping, automatic probe ambiance, and HDR/exposure. If enabled, legacy skies will behave as if probe ambiance and HDR scale are 1.0, and ambient will be cut in half.
HDR scale will act as a sky brightener, but will automatically adjust dynamic exposure so the sky will be properly exposed. If you want relatively even exposure all the time, set HDR Scale to 1.0. If you want a high range of exposures between indoor/dark areas and outdoor/bright areas, increase HDR Scale.
Also tuned up SSAO (thanks Rye!).
Reviewed with Brad.
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
(cherry picked from commit bb718155bd)
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
Maxim Nikolenko