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.
This commit removes a seemingly duplicated `connectRefreshCachedSettingsSafe` call in `LLPipeline::init()` for the `RenderAutoHideSurfaceAreaLimit` setting.
A duplicated registration for this setting was identified during a review of `LLPipeline::init()`. Double registration can lead to unexpected behavior, including potential CPU overhead.
The duplication *may* have been introduced with commit 440c7b2 (Added CollectFontVertexBuffers feature), though this requires further confirmation.
Testing Performed:
After removing the duplicate registration, the `RenderAutoHideSurfaceAreaLimit` functionality was validated by ensuring the following behavior (consistent with the existing code):
* A value of 0 (zero) causes all objects to appear regardless of size.
* Values slightly above zero result in only small objects appearing, with all others hidden.
* Increasing the value causes objects of increasing size to appear, while smaller objects remain visible.
This change merits careful review to ensure it has no unintended side effects, and to confirm the accuracy of these observations from other developers.
Problem:
When selecting a new cloud texture in the Personal Lighting floater (LLFloaterEnvironmentAdjust), the sky did not visually update. The code previously only updated LiveSky->setCloudNoiseTextureId() and called mLiveSky->update(), which failed to notify the global LLEnvironment mechanism or the renderer about the new texture.
Cause:
Relying solely on mLiveSky for environment changes is insufficient. To update the live environment layer (ENV_LOCAL) and trigger a render refresh, calls to LLEnvironment::setEnvironment() and LLEnvironment::updateEnvironment() are required.
Solution:
1. Remove an unnecessary null-check for getChild<LLTextureCtrl>, as getChild() never returns null.
2. Clone the current sky settings (mLiveSky->buildClone()) to avoid modifying a shared environment object directly.
3. Apply the new cloud texture ID to the clone.
4. Use LLEnvironment::setEnvironment(ENV_LOCAL, sky_to_set) to apply the updated settings to the user's local environment override.
5. Call LLEnvironment::updateEnvironment(LLEnvironment::TRANSITION_INSTANT, true) to ensure the renderer recognizes and displays the updated texture immediately.
6. Reset the picker control’s value to match the newly applied texture for UI consistency.
Additional Note:
A partial implementation was inadvertently committed earlier (commit`04af042`) due to a local staging error. This commit supersedes that incomplete change by correctly implementing the intended fix.
Result:
Selecting a new cloud texture from LLFloaterEnvironmentAdjust now immediately updates both the in-world sky rendering and the texture preview UI, ensuring consistency and clarity for users.
Testing:
- Open the Personal Lighting floater and select various cloud textures.
- Verify that the sky updates immediately for each new selection.
- Confirm that the texture picker also updates to reflect the selected texture.
Problem:
Opening the Fixed Environment floater generated three distinct XUI parsing warnings in the logs:
- Failed to parse parameter "decimal_digits." in xy_vector.xml
- Failed to parse parameter "user_resize." in xy_vector.xml
- Failed to parse parameter "logarithmic." in panel_settings_sky_clouds.xml
Cause:
These attributes were either not recognized/utilized by the underlying C++ widget implementations ('decimal_digits', 'user_resize' in LLXYVector) or were using an incorrect value ('logarithmic="1"' instead of a boolean 'true'/'false' in LLSliderCtrl).
Solution:
This commit addresses these three warnings:
- Removed the extraneous 'decimal_digits' and 'user_resize' attributes from the definition of the 'xyvector' widget in xy_vector.xml.
- Corrected the 'logarithmic' attribute value from "1" to "true" for the 'cloud_scroll_xy' slider in panel_settings_sky_clouds.xml.
Result:
Eliminates these specific parsing warnings from the logs when the Fixed Environment floater is opened.
Testing:
- Launch viewer.
- Open World -> Environment Editor -> My Environments.
- Select a sky setting and click Edit (or create a New one).
- Observe the logs upon the Fixed Environment floater opening.
- Verify the absence of the 'decimal_digits', 'user_resize' (from xy_vector.xml), and 'logarithmic' (from panel_settings_sky_clouds.xml) parsing warnings.
Problem:
A warning "Failed to parse parameter 'user_resize.'" appeared in the logs during UI loading, originating from sun_moon_trackball.xml.
Cause:
The 'user_resize' attribute is not a recognized or utilized parameter for the 'sun_moon_trackball' widget type, as defined in the corresponding C++
(LLVirtualTrackball).
Solution:
Removed the extraneous 'user_resize="false"' line from the sun_moon_trackball.xml widget definition.
Result:
Eliminates the parsing warning from the logs upon viewer startup or UI reload.
Testing:
- Launch viewer.
- Check logs for the absence of the "Failed to parse parameter 'user_resize.'" warning.
Problem:
When selecting a new cloud texture in the Personal Lighting floater (LLFloaterEnvironmentAdjust) using the cloud map texture picker, the sky rendering did not update to reflect the selected texture. The callback only updated the internal mLiveSky object and its subsequent call to mLiveSky->update() was insufficient to trigger a live render update.
Cause:
The onCloudMapChanged callback modified the mLiveSky settings object directly and called its update() method. However, in the context of live environment adjustments, changes require propagation through the central LLEnvironment singleton to correctly update the active environment layer (ENV_LOCAL) and signal the renderer. Relying solely on the settings object's update() method bypassed this necessary mechanism.
Solution:
This commit refactors onCloudMapChanged to correctly handle the update:
1. Uses the LLEnvironment singleton to manage the state change:
- Explicitly targets the local environment layer (ENV_LOCAL) via setSelectedEnvironment().
- Clones the mLiveSky settings object.
- Uses LLEnvironment::setEnvironment() to apply the modified clone to the ENV_LOCAL layer.
- Uses LLEnvironment::updateEnvironment() to trigger the render update.
2. Synchronizes the UI preview:
- Calls picker_ctrl->setValue() on the LLTextureCtrl widget after the environment update to ensure the UI preview matches the applied texture.
Result:
Selecting a cloud texture in the Environment Settings floater now correctly updates both the sky rendering and the UI preview widget simultaneously.
Testing:
- Open World -> Environment Editor -> Environment Settings.
- Go to the Clouds tab.
- Click the cloud texture preview to open the texture picker.
- Select a new cloud texture and click OK.
- Verify the sky updates immediately to use the selected texture.
- Verify the texture preview in the floater also updates immediately.
- Repeat with several different textures to confirm consistent behavior.
Resolves the root cause of shadow rendering failures when changing RenderShadowResolutionScale immediately after modifying other graphics settings (e.g., SSAO, HDR).
Investigation revealed that LLPipeline::createGLBuffers, which is called during certain graphics setting changes that require full buffer recreation, contained lines that incorrectly set mRT->width and mRT->height to zero *after* the call to allocateScreenBuffer had already established the correct dimensions.
This created a state inconsistency. If RenderShadowResolutionScale was changed immediately following the graphics setting change, the subsequent call to LLPipeline::resizeShadowTexture (triggered via handleShadowsResized) would read these incorrect zero dimensions from mRT. This led to failed shadow buffer allocation (allocateShadowBuffer(0, 0)) and resulted in corrupted or missing shadows.
This commit removes the erroneous mRT->width = 0 and mRT->height = 0 lines from the end of createGLBuffers. This ensures that the render target dimensions remain valid after buffer recreation.
With this fix, resizeShadowTexture now correctly reads the valid screen dimensions immediately following a graphics setting change and successfully resizes the shadow buffers without delay or error. This eliminates the need for previous workarounds like guard conditions or forced shader recompiles.
Ref: #3719
Using the echos from the last run, it appears that the tagged builds have Workflow Head Branch = Second_Life_X.
Edit made so the file looks for this rather than what was there previously.
tl;dr - this helps avoid frequent texture reuploads to VRAM in some texture heavy areas. This speaks to some bigger problems we're seeing in our texture streaming system however. You will see similar problems by manually setting the texture VRAM manually.
Ansariel