Merge develop into release/2025.04 #3944
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…G_SPECIAL, The metadata can contain information about the bot status of the sender. It may also contain a system-injected notification that is displayed to the agent as part of the 1:1 chat window.
…essage on behalf of the system, optionally specify the agent id and name that should be used. (cherry picked from commit 7ff297e)
Shadows were not updating correctly after a shader change occurred in-session and then the RenderShadowResolutionScale setting was adjusted. This issue is present in Second Life Release 7.1.12.1355088671 (64-bit) and Second Life Test 7.1.12.250701803 (64-bit).
**Specifically, after any shader-related setting is changed in-session (such as toggling Advanced Graphics options like SSAO, HDR, Depth of Field, SSR, Antialiasing, or changing the Graphics Quality preset), subsequent adjustments to `RenderShadowResolutionScale` via Debug Settings result in broken shadow rendering.** The shadows become corrupted or disappear entirely and do not reflect the new resolution scale. Correct shadow rendering is only restored by toggling a shader or restarting the viewer. This behavior is inconsistent with other render settings that update immediately after modification and degrades the user experience when dynamically adjusting shadow quality.
This commit changes the signal listener for "RenderShadowResolutionScale" in **llviewercontrol.cpp** from `handleShadowsResized` to `handleSetShaderChanged`.
`handleSetShaderChanged` ensures a full shader update, which is necessary for this setting to take effect immediately—similar to other render settings like RenderDeferredSSAO.
This change ensures that shadows update correctly and immediately when the resolution scale is changed in Debug Settings, even after prior shader changes in the session, without requiring additional shader toggling or viewer restarts. This provides a smoother and more responsive experience for advanced users adjusting shadow quality in various rendering scenarios.
---
**Steps to Reproduce (Bug)**
_Verified in Second Life Release 7.1.12.1355088671 (64-bit) and Second Life Test 7.1.12.250701803 (64-bit):_
1. **Fresh Install Preparation:** Ensure a clean Second Life installation state. Ideally, uninstall and reinstall the viewer or clear/rename all folders in `AppData\Local\Second Life` and `AppData\Roaming\Second Life` before launching.
2. Launch the Second Life Viewer and log in.
3. Enable the Debug Menu: Open Preferences (Ctrl+P), go to the "Advanced" tab, and check "Show Advanced Settings".
4. Open Debug Settings: Click the "Advanced" menu in the menu bar and select "Debug Settings."
5. Locate the `RenderShadowResolutionScale` setting (which should be set to 1.0 on a clean install).
6. Initially, changing `RenderShadowResolutionScale` at this point may not exhibit the bug. Proceed to the next steps to reliably trigger it.
7. **Trigger the Bug:** Open Preferences (Ctrl+P) again and go to the "Graphics" tab.
8. Click the "Advanced Settings" button.
9. **Toggle *any* of the following Advanced Graphics options:**
- Screen Space Ambient Occlusion
- HDR and Emissive Rendering
- Depth of Field
- Screen Space Reflections
- Antialiasing
- *Alternatively*, change the "Graphics Quality" preset slider (e.g., Low to Ultra or any other change).
10. Return to the Debug Settings floater.
11. Change the value of `RenderShadowResolutionScale` to a different value (e.g., from 1.0 to 0.5 or 2.0).
12. **Observe the Bug:** Notice that shadow rendering does not update correctly—shadows become corrupted or disappear.
13. **Workaround (in buggy version):** To restore correct shadow rendering without the fix, either:
- Toggle a different shader (e.g., change graphics presets in Preferences, or toggle SSAO, SSR, etc.), or
- Restart the viewer.
**Steps to Verify (Fix):**
1. Build the viewer with this commit applied.
2. Launch the viewer and log in.
3. Repeat steps 1–9 from "Steps to Reproduce (Bug)" to ensure an Advanced Graphics setting is toggled before proceeding.
4. Open Debug Settings and locate `RenderShadowResolutionScale`.
5. Change the value of `RenderShadowResolutionScale` (e.g., from 1.0 to 0.5 or 2.0).
6. **Verify the Fix:** Confirm that shadow rendering updates immediately and correctly—even after toggling Advanced Graphics settings—with the shadows visibly changing resolution in real time. No shader toggling or viewer restart is required.
---
- No specific regression testing is required for this targeted fix. However, standard viewer functionality should be verified after building to ensure no unintended side effects have been introduced. Pay particular attention to shadow rendering in various environments and lighting conditions to confirm the fix has not negatively impacted other shadow-related features.
---
- No documentation changes are needed as this is a bug fix for an existing debug setting.
…mensions after shader changes; **Replaces forced shader refresh with lightweight guard** This commit introduces a guard in `LLPipeline::resizeShadowTexture()` to prevent shadow texture resizing when the shadow render target (mRT) has invalid (zero) dimensions. **This replaces a previous, less efficient approach of forcing a full shader recompile whenever `RenderShadowResolutionScale` was changed in-session.** **Background and Problem:** Previously, the code forced a full shader recompile whenever `RenderShadowResolutionScale` changed in-session (after toggling advanced graphics settings like SSAO or HDR). While this “sledgehammer” approach did fix broken shadow rendering, it unnecessarily thrashed the shader cache and reset many pipeline states. **Solution:** This commit removes the forced shader recompile in favor of a guard check in `LLPipeline::resizeShadowTexture()`. The guard ensures mRT (the shadow render target) has non-zero dimensions before resizing. If mRT is zero for that frame, the resize operation is skipped, and a warning is logged. Once mRT becomes valid (usually in the next frame), the shadow texture is resized successfully without requiring a full shader refresh. **Detailed changes:** - Reverted the binding of `RenderShadowResolutionScale` to `handleSetShaderChanged`. - Restored the original `handleShadowsResized` listener for `RenderShadowResolutionScale` in `llviewercontrol.cpp`. - Added guard checks in `LLPipeline::resizeShadowTexture()` to skip resizing when `mRT->width` or `mRT->height` is zero. - Added logging statements to track how many frames are skipped. **Benefits:** - Prevents shader thrashing while still avoiding shadow corruption. - Shadows now update correctly as soon as mRT dimensions are valid. - Maintains a detailed record of frames skipped. - **Lightweight and targeted interim solution, much less disruptive than a full shader recompile.** Testing: 1. Reproduce the bug as described in the bug report (toggle SSAO, then change RenderShadowResolutionScale). 2. Verify that shadows are no longer broken after these steps. 3. Check the logs for the warning message indicating skipped frames when the bug is triggered. 4. Confirm that under normal operation (without shader changes causing mRT issues), shadow resizing works as expected without excessive warnings. Documentation: No user-facing documentation changes are needed for this interim fix. However, internal developer documentation should note this guard and the ongoing investigation into the root cause. Further Development: This guard is a temporary fix. The root cause of why mRT becomes invalid after shader changes needs to be investigated and resolved. See the bug report for detailed next steps for investigation.
* prevent erroneous edit of wrong parcel Fixes jira-archive-internal/issues/70771 [SL-20409] Erroneous Local Parcel Twins - Parcel Updates Across Region Borders - unrequested updateDatabaseParcel changes * remove unused argument in sendParcelPropertiesUpdate()
…tattle Fix conflicts
Resubmit PR#2908+2951 Bot self identification and bug fix.
Previously in the develop archive. Recent change is to only run the workflow for tagged builds. The code to running other builds has been commented out.
Added QA workflow file
GHA does not like comments inside an if statement. These have been removed.
Removed unnecessary comments in QA workflow file
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.
…Buffers 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
Allow QA workflow to run on Second_Life_X branches
fix: Correctly update shadows on RenderShadowResolutionScale change
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.
…ckball 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:
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.
…ver/viewer into fix/xui-parsing-fixes
Add discord channel for open source discussion.
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.
Fix: Resolve Minor XUI Parsing Warnings in Environment Widgets
…ing registration 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.
… based on previously selected snapshot type and not necessarily snapshot to inventory
…n is "Current Window" to determine correct image size and upload cost
# Conflicts: # indra/llui/lltextbase.h # indra/llui/lltexteditor.h # indra/llwindow/llwindowsdl.cpp
Remove obsolete cmake_minimum_required that is lower than the required version in the main CMakeLists.txt
Restore currently entered text in chat entry textbox after going through history with Ctrl-PgUp/PgDown
Snapshot fixes from archived develop branch
Clean up LLUI and fix/add suggestions from VS
Geenz
approved these changes
Apr 18, 2025
marchcat
approved these changes
Apr 18, 2025
Merged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.