| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
* updateImageDecodePriority - Avoid Long Face Loop
To avoid running a long loop on thousands of faces, some textures were being set to a BOOST level to avoid the updateImageDecodePriority function entirely but this was causing many of them to never be deleted over the course of a user's travels.
Instead of relying on BOOST, this commit changes the logic of the texture channel loop such that the face loop will only run if the number of faces is below the threshold.
To do this, we move the face_count incrementing outside of the face loop into the channel loop and increment it using the getNumFaces function instead.
We then check the face_count against the maximum number of faces we want to check and if it exceeds the number we set the number of faces for the face loop to check down to zero.
This avoids branch prediction misses and the long face loop issue.
Later, if the face_count is above the threshold, we assign the virtual size to the maximum.
I personally believe the max_faces_to_check should be lower than 1024, but I left that value in for continuity. I use 64 faces as my max on my compiled version of the viewer without any noticeable issues for memory use.
* updateImageDecodePriority - Face Loop Increment Swap
Looks like compilers like knowing the incrementing in the for loop information for optimizations and parallelization.
Sorry for the tiny commit.
* updateImageDecodePriority - Suggested Cleanup
Remove trailing white-space.
Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
|
|
KDU is uploading 2k files with 7 and 8 layers which is shifting the location of discard 1 and 2.
To accommodate, this commit adds a max_layer check based on max_dimension and the MAX_BLOCK_SIZE to allow the extra layers for 2k.
Also shifted the starting size to the MIN_LAYER_SIZE instead of MAX_BLOCK_SIZE's area to allow smaller files to be decoded at discard 5 completely.
Finally able to walk around Fantasy Faire without any gray blobs!
|
|
LLAgent::leftButtonGrabbed() must report TRUE only when an attachment has
**actually grabbed** the left mouse button (accept = TRUE, pass_on = FALSE), like every other ...Grabbed() function below it
|
|
[#3972] Implemented Texture Panel Repeats per meter improvements and PBR feature
|
|
|
|
Increment viewer version after 2024.05
|
|
|
|
|
|
std::string_view and heterogeneous map lookups (#3970)
|
|
|
|
meter
|
|
|
|
|
|
Restore option to change location of existing pick
|
|
# Conflicts:
# indra/newview/llviewerdisplay.cpp
|
|
|
|
|
|
frame (#2640)
|
|
|
|
https://github.com/Ansariel/viewer into devleop-picks-improvement
|
|
|
|
|
|
|
|
|
|
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
|
|
# 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
|
|
* 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
|
|
Fix: Remove potentially redundant RenderAutoHideSurfaceAreaLimit sett…
|
|
Refactor tonemap blending to preserve HDR detail during mix
|
|
Merge 2025.03 release into develop.
|
|
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.
|
|
Fix: Apply Cloud Texture Changes from Environment Settings Floater
|
|
|
|
|
|
|
|
|
|
|
|
|
