Age | Commit message (Collapse) | Author |
|
when probe ambiance is zero.
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Add a binary cache for compiled shaders using glProgramBinary
* Add additional sanity checking to shader binary save and load, hook up cache clear and menu option
* Fix default init of shader cache data struct and clear gl errors before glGetError calls
---------
Co-authored-by: RunitaiLinden <davep@lindenlab.com>
|
|
|
|
|
|
|
|
preferences that no longer exist.
|
|
DRTVWR-559 merge 539
|
|
for adjusting legacy gamma when probe ambiance is 0 and dynamic exposure when probe ambiance is not zero.
|
|
|
|
|
|
Value gets rounded towards closest increment, no point displaying smaller values
|
|
preferences and featuretable. Remove Reflections checkbox. Don't persist reflection probe volume display between sessions. Incidental decruft.
|
|
enabling AutoFPS
|
|
brightness to allow ACES Hill all the time.
|
|
prioritization. Incidental decruft.
|
|
exposure controls not persist, limit exposure range, and do a debug gl pass.
|
|
* SL-19538 Remove hacky ambiance scale and take the mittens off probe ambiance values. Fix for sky brightening being done in sRGB space.
|
|
# Conflicts:
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/llfloateravatarrendersettings.cpp
|
|
|
|
|
|
# Conflicts:
# indra/cmake/CMakeLists.txt
# indra/newview/skins/default/xui/es/floater_tools.xml
|
|
|
|
|
|
|
|
|
|
The viewer currently presents a startling "Grid emergency" warning if an
unrecognized error is returned from login. Let's tone this down a bit
and present the error as it is: an unrecognized login failure rather
than SLearth exploding.
|
|
material selector, incidental decruft.
|
|
material swatch to "Material"
|
|
|
|
|
|
|
|
|
|
commit -- immediately apply scale to sphere probes.
|
|
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
|
|
running under wine)
|
|
wrong color space.
|
|
# Conflicts:
# doc/contributions.txt
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
|
|
|
|
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|