| Age | Commit message (Collapse) | Author |
|---|
|
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: Resolve Minor XUI Parsing Warnings in Environment Widgets
|
|
Add discord channel for open source discussion.
|
|
|
|
|
|
https://github.com/williamweaver/viewer into fix/xui-parsing-fixes
|
|
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.
|
|
fix: Correctly update shadows on RenderShadowResolutionScale change
|
|
|
|
Allow QA workflow to run on Second_Life_X branches
|
|
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.
|
|
|
|
Removed unnecessary comments in QA workflow file
|
|
GHA does not like comments inside an if statement. These have been removed.
|
|
Added QA workflow file
|
|
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.
|
|
Resubmit PR#2908+2951 Bot self identification and bug fix.
|
|
Fix conflicts
|
|
* 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()
|
|
message_template.msg to agree with master-message-template
|
|
|
|
dimensions 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.
|
|
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.
|
|
Merge pull request #3304 from secondlife/release/2024.12-ForeverFPS
|
|
2024.12 ForeverFPS
|
|
Update develop with ForeverFPS
|
|
https://github.com/secondlife/server/issues/1493 New notification for transfer ownership
|
|
https://github.com/secondlife/server/issues/966 Honor flag sent by server indicating server side autopilot is engaged. When flag is set allow server to update local avatar rotation.
|
|
https://github.com/secondlife/viewer-private/issues/297 Local beacons via script
|
|
|
|
on behalf of the system, optionally specify the agent id and name that should be used.
(cherry picked from commit 7ff297ec3fc5f878cc9a916678987c0033b7eb8a)
|
|
|
|
IM_NOTHING_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.
|
|
|
|
indicate if the world map should be opened and focused.
|
|
engaged. When flag is set allow sever to update local avatar rotation.
|
|
This reverts commit b0d80552b3177269eb24ef9a1e0d58a98d95a96f.
|
|
|
|
#3331 - Mirrors no longer function on relog
|
|
|
|
- #3594 Adjustments to mitigate sun reflection being too narrow.
|
|
|
|
|
|
1. Cover reset with 'generation'
2. Fix lapse of judgement with mLastFontGlyphCount, it should have been
saved before render(), not after
|
|
|
|
|
|
|
|
|
