| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Media plugins enabling not yet.
OpenXR is disabled for now (it hasn't been used anyway).
perl-FindBin is needed to be able to build OpenSSL on Fedora aarch64.
Setting the C standard to 90 when building cURL is needed, otherwise
it would fail at configure time with a misleading error of not finding
link/run time requirements for dependencies (such as nghttp2 and zlib),
at least on Fedora (and macOS too back then, I remember).
GCC treated SSE2NEON warnings as errors on so many files,
so -Wno-cpp is added globally.
The same Linux CPU frequency calculation needs to be out of the x86 scope,
otherwise the viewer would complain about not meeting the requirements
at launch time.
|
|
develop → 2025.05 sync
|
|
|
|
|
|
|
|
|
|
to fit favorites tab
|
|
|
|
|
|
Clean up LLUI and fix/add suggestions from VS
|
|
Snapshot fixes from archived develop branch
|
|
Restore currently entered text in chat entry textbox after going through history with Ctrl-PgUp/PgDown
|
|
Remove obsolete cmake_minimum_required that is lower than the required version in the main CMakeLists.txt
|
|
# Conflicts:
# indra/llui/lltextbase.h
# indra/llui/lltexteditor.h
# indra/llwindow/llwindowsdl.cpp
|
|
"Current Window" to determine correct image size and upload cost
|
|
on previously selected snapshot type and not necessarily snapshot to inventory
|
|
image size and display upload cost to user
|
|
# Conflicts:
# indra/newview/llpanelsnapshotinventory.cpp
|
|
history with Ctrl-PgUp/PgDown (#2680)
|
|
version in the main CMakeLists.txt
|
|
# Conflicts:
# indra/llmath/v2math.cpp
# indra/llmath/v2math.h
# indra/llmath/v3math.h
# indra/llmath/v4math.h
|
|
Add a bunch of old and new math improvements
|
|
* Make eligible functions constexpr
* Use constants for vector indices where applicable
* Reformat to match actual coding conventions
|
|
|
|
that don't work using /fp:fast floating point behavior under MSVC
|
|
|
|
Turns out it hasn't been needed, might be leftover from system Collada
DOM, and LL has their own URI parser.
|
|
It's installation is not implied by any other package for the project,
at this moment.
|
|
Turns out it wasn't forwarded, when I was building on macOS 15 arm64.
|
|
due to version mismatch.
Should use LLInventoryModel::changeItemParent
|
|
since it's upgraded to 1.4.1 in Fedora 42 from stable 1.2.7 in Fedora
41, and there seem to be API changes and we're not ready for them yet.
|
|
|
|
|
|
|
|
Fix: Remove potentially redundant RenderAutoHideSurfaceAreaLimit sett…
|
|
# Conflicts:
# indra/llcommon/lldate.h
# indra/newview/llappviewer.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llmaterialeditor.cpp
# indra/newview/llviewerparceloverlay.cpp
# indra/newview/llvoavatar.cpp
|
|
Refactor tonemap blending to preserve HDR detail during mix
|
|
Merge 2025.03 release into develop.
|
|
|
|
Release/2025.03
|
|
|
|
|
|
|
|
|
|
Key improvements:
1. Better error handling for thread detachment
2. More careful sequencing of operations
3. Ensuring the window is hidden before proceeding with other shutdown steps
4. Proper checking of thread joinability before detaching
|
|
The blending operation for the `tonemap_mix` uniform in `postDeferredTonemap.glsl` incorrectly used a prematurely clamped color value as the source for the linear mix target. Specifically, the exposed HDR input color was clamped to the [0, 1] LDR range before being used in the `mix()` function when `tonemap_mix < 1.0`.
This premature clamping resulted in the loss of High Dynamic Range (HDR) detail in highlights during the blend operation. As `tonemap_mix` was reduced, instead of smoothly blending towards the linear scene representation, clipped highlights were incorrectly reintroduced.
This commit modifies the `toneMap` and `toneMapNoExposure` functions to correct this logic:
1. The original linear input color is preserved before exposure/processing.
2. The appropriate exposure factor is calculated and applied separately.
3. The chosen tone mapping operator is applied to the exposed color, storing the result.
4. The `mix()` function now correctly blends between the appropriately scaled, *unclamped* linear input color and the fully tone-mapped result.
5. The final clamp to the [0, 1] LDR range is applied *after* the blend operation.
This change ensures that HDR information is preserved throughout the blending process, resulting in a smoother, more perceptually correct visual transition as `tonemap_mix` is adjusted. While the effect is nuanced, it is noticeable in bright highlights; with the legacy code, these highlights appeared visibly clipped and less intense during the blend, whereas the corrected code allows them to retain their peak brightness and detail more accurately. This makes the `tonemap_mix` control more intuitive, behaving as a true intensity blend for the tone mapping effect without introducing clipping artifacts. The computational cost is negligible.
|
|
in List view; update persistence of new settings
|
|
|
|
|
