6 files changed, 263 insertions, 1 deletions
diff --git a/doc/contributions.txt b/doc/contributions.txt
index 5a4d276a20..1f911a8b39 100755
--- a/doc/contributions.txt
+++ b/doc/contributions.txt
@@ -1210,6 +1210,7 @@ PanteraPolnocy
 	SL-18937
 	SL-19207
 	SL-19681
+    secondlife/viewer#2483
 Parvati Silverweb
 Patric Mills
 	VWR-2645
@@ -1436,6 +1437,30 @@ Sovereign Engineer
     SL-18534
     SL-19690
     SL-19336
+    secondlife/viewer/pull/1283
+    secondlife/viewer/pull/1287
+    secondlife/viewer/pull/1906
+    secondlife/viewer/pull/1930
+    secondlife/viewer/pull/1941
+    secondlife/viewer/pull/1946
+    secondlife/viewer/pull/1948
+    secondlife/viewer/pull/1950
+    secondlife/viewer/pull/1951
+    secondlife/viewer/pull/2066
+    secondlife/viewer/pull/2077
+    secondlife/viewer/pull/2078
+    secondlife/viewer/pull/2080
+    secondlife/viewer/pull/2085
+    secondlife/viewer/pull/2098
+    secondlife/viewer/pull/2099
+    secondlife/viewer/pull/2105
+    secondlife/viewer/pull/2115
+    secondlife/viewer/pull/2116
+    secondlife/viewer/pull/2124
+    secondlife/viewer/pull/2125
+    secondlife/viewer/pull/2135
+    secondlife/viewer/pull/2136
+    secondlife/viewer/pull/2149
 SpacedOut Frye
 	VWR-34
 	VWR-45
diff --git a/doc/testplans/PRIM_MEDIA_FIRST_CLICK_INTERACT.md b/doc/testplans/PRIM_MEDIA_FIRST_CLICK_INTERACT.md
new file mode 100644
index 0000000000..afb3d5b337
--- /dev/null
+++ b/doc/testplans/PRIM_MEDIA_FIRST_CLICK_INTERACT.md
@@ -0,0 +1,158 @@
+# Test plan for PRIM_MEDIA_FIRST_CLICK_INTERACT
+
+## Requirements
+
+- At least two accounts
+- At least one group
+- Land under your control
+
+## Feature Brief
+
+Historically media-on-a-prim (MOAP) in Second Life has been bound to a focus system which blocks mouse click/hover events, this feature creates exceptions to this focus system for a configurable set of objects to meet user preference.
+
+## Testing
+
+The following scripts and test cases cover each individual operational mode of the feature; in practice these modes can be combined by advanced users in any configuration they desire from debug settings. Even though the intended use case combines multiple modes, individual modes can be  tested for functionality when tested as described below.
+
+If testing an arbitrary combination of operational modes beyond what the GUI offers is desired, the parameters of the bitfield for calculation are located in lltoolpie.h under the MediaFirstClickTypes enum. As of writing there exists a total of ~127 possible unique/valid combinations, which is why testing each mode individually is considered the most efficient for a full functionality test.
+
+### Scripts
+
+#### Script A
+
+This script creates a media surface that is eligible for media first-click interact. Depending on test conditions, this will exhibit new behavior.
+
+```lsl
+default {
+    state_entry() {
+        llSetLinkMedia( LINK_THIS, 0, [
+            PRIM_MEDIA_CURRENT_URL, "http://lecs-viewer-web-components.s3.amazonaws.com/v3.0/agni/avatars.html",
+            PRIM_MEDIA_HOME_URL, "http://lecs-viewer-web-components.s3.amazonaws.com/v3.0/agni/avatars.html",
+            PRIM_MEDIA_FIRST_CLICK_INTERACT, TRUE,
+            PRIM_MEDIA_AUTO_PLAY, TRUE,
+            PRIM_MEDIA_CONTROLS, PRIM_MEDIA_CONTROLS_MINI
+        ] );
+    }
+}
+
+```
+
+#### Script B
+
+This script creates a media surface that is NOT eligible for media first-click interact. In all but one test case, this will behave the same way.
+
+```lsl
+default {
+    state_entry() {
+        llSetLinkMedia( LINK_THIS, 0, [
+            PRIM_MEDIA_CURRENT_URL, "http://lecs-viewer-web-components.s3.amazonaws.com/v3.0/agni/avatars.html",
+            PRIM_MEDIA_HOME_URL, "http://lecs-viewer-web-components.s3.amazonaws.com/v3.0/agni/avatars.html",
+            PRIM_MEDIA_FIRST_CLICK_INTERACT, FALSE,
+            PRIM_MEDIA_AUTO_PLAY, TRUE,
+            PRIM_MEDIA_CONTROLS, PRIM_MEDIA_CONTROLS_MINI
+        ] );
+    }
+}
+
+```
+
+## Standard testing procedure
+
+You will be asked to enable media faces on multiple cubes, make sure that the webpage loads on each, and interact with them in the following ways.
+
+1. Enable media for the cube, and verify that it displays a webpage.
+2. Click on the terrain to clear any focus.
+3. Hover your mouse over UI elements of the webpage, and **observe** if they highlight/react to the mouse cursor.
+4. If hover events are not registered, clicking on the webpage and then **observe** if they begin reacting to hover events.
+5. Clicking on the terrain to clear any focus once again.
+6. Clicking on a UI element of the webpage and **observe** if it reacts to the first click, or requires a second click. *(Maximum of 2 clicks per attempt)*
+
+These steps will be repeated for one or more pairs of cubes per test case to ensure that media first click interact is functioning within expectations. Unless otherwise mentioned for a specific test case, you simply need only be in the same region as the cubes to test with them.
+
+## Test cases
+
+All test cases begin with at least two cubes rezzed, one containing Script A henceforth referred to as Cube A and one with Script B referred to as Cube B. The steps of some test cases may impact the condition of the cubes, so keeping a spare set rezzed or in inventory to rapidly duplicate should improve efficiency if testing cases in series.
+
+### Case 1 (MEDIA_FIRST_CLICK_NONE)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `0`
+
+Starting with Cube A and Cube B, perform the testing procedure on each.
+
+**Expected observations:** Both webpages do not react to hover events until clicked, both webpages do not react to clicks until clicked once to establish focus
+
+### Case 2 (MEDIA_FIRST_CLICK_HUD)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `1`
+
+Starting with Cube A and Cube B, attach them both to your HUD and perform the testing procedure on each. You may need to rotate or scale the cubes to fit on your screen before beginning testing. You may attach both at the same time, or only one at a time.
+
+**Expected observations:** The webpage on Cube A will react to mouse cursor hover events and clicks without needing a focus click, but the webpage on Cube B will not.
+
+### Case 3 (MEDIA_FIRST_CLICK_OWN)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `2`
+
+This test case requires two pairs of cubes, and the second pair must not be owned by your testing account. What owns them is not important, it can be a group or your second testing account.
+
+Perform the testing procedure on both sets of cubes.
+
+**Expected observations:** The webpage on Cube A will react to mouse cursor hover events and clicks without needing a focus click, but the webpage on Cube B will not. The other pair of cubes will react the same as your Cube B.
+
+### Case 4 (MEDIA_FIRST_CLICK_GROUP)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `4`
+
+This test case requires two cubes, and the second cube must be deeded or set to a group that your testing account is a member of. As long as the second set of cubes is set to a group that your test account is a member of, the avatar that owns them does not matter.
+
+Perform the testing procedure on both sets of cubes.
+
+**Expected observations:** The cube owned by your primary account will not react to mouse cursor hover events and clicks without needing a focus click. The cube set to group will react to mouse cursor hover events and clicks without needing a focus click.
+
+### Case 5 (MEDIA_FIRST_CLICK_FRIEND)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `8`
+
+This test case requires three sets of cubes, one owned by you, one owned by another avatar on your friend list, and a third set owned by an avatar that is not on your friend list, or deeded to group. You can optionally use two sets of cubes, and dissolve friendship with your second account to test non-friend cubes.
+
+Perform the testing procedure on all cubes
+
+**Expected observations:** Cube A owned by a friended avatar will react to mouse cursor hover events and clicks without needing a focus click. All other cubes will not.
+
+### Case 6 (MEDIA_FIRST_CLICK_LAND)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `16`
+
+This is the most tricky test case due to the multiple combinations that this operational mode considers valid. You will need multiple cubes, and can omit Cube B for brevity unless running a full test pass. This is probably most efficiently tested from your second account, using your first account to adjust the test parameters to fit other sub-cases.
+
+Note: This requires the avatar that is performing the tests to physically be in the same parcel as the test cube(s). If you are standing outside of the parcel the media cubes are in, they will never react to mouse cursor hover events and clicks without needing a focus click under this operational mode.
+
+1. Place down a set of cubes owned by the same avatar as the land
+    - The second account should see Cube A react to mouse cursor hover events and clicks without needing a focus click
+    - Cube B if tested, will not react in all further sub-cases and will not be mentioned further.
+
+2. Adjust the conditions of the cubes and parcel such that they are owned by another avatar, but have the same group as the land set
+    - The second account should see Cube A react to mouse cursor hover events and clicks without needing a focus click
+
+3. Adjust the conditions of the cubes and parcel such that they are deeded to the same group that the parcel is deeded to
+    - The second account should see Cube A react to mouse cursor hover events and clicks without needing a focus click
+
+4. Adjust the conditions of the cubes and parcel such that the parcel and cubes do not share an owner, or a group
+    - The second account should see Cube A NOT react to mouse cursor hover events until clicked, and clicks WILL need a focus click before registering.
+
+### Case 7 (MEDIA_FIRST_CLICK_ANY) (optional)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `32767`
+
+Repeat test cases 1-6.
+
+1. Test case 1 should fail
+2. Test cases 2-6 should pass
+
+### Case 8 (MEDIA_FIRST_CLICK_BYPASS_MOAP_FLAG) (optional)
+
+Ensure that debug setting `MediaFirstClickInteract` is set to `65535`
+
+Repeat test cases 1-6, there is no pass/fail for this run.
+
+All cubes including B types should exhibit the same first-click interact behavior.
diff --git a/doc/testplans/pbr_materials.md b/doc/testplans/pbr_materials.md
new file mode 100644
index 0000000000..1ef7945b94
--- /dev/null
+++ b/doc/testplans/pbr_materials.md
@@ -0,0 +1,12 @@
+# PBR Materials
+
+## KHR Texture Transforms
+
+Texture repeats for PBR materials on prims are based on the [KHR\_texture\_transform](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform) spec, and thus should be expected to behave according to the spec. We currently suport offset, rotation, and scale from the spec. texCoord is not currently supported.
+
+PBR materials should have approximately correct lighting based on the normal texture:
+
+- With default texture transforms, assuming the prim or model has correct normals and tangents
+- With a texture transform applied, especially rotation or negative scale
+- With a texture animation applied via `llSetTextureAnim`, especially a rotation animation
+    - Note: Texture animations are not guaranteed to loop when a PBR texture transform is applied
diff --git a/doc/testplans/pbr_terrain_appearance.md b/doc/testplans/pbr_terrain_appearance.md
index 11b501be3a..eab5b8bf44 100644
--- a/doc/testplans/pbr_terrain_appearance.md
+++ b/doc/testplans/pbr_terrain_appearance.md
@@ -39,7 +39,7 @@ PBR terrain does not support materials with alpha blend or double-sided. In addi
 
 ## PBR Terrain Texture Transforms
 
-Like PBR materials on prims, PBR terrain repeats are based on the [KHR\_texture\_transform](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform) spec, and thus should be expected to behave the same way.
+Like PBR materials on prims, PBR terrain repeats are based on the [KHR\_texture\_transform](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform) spec, and thus should be expected to behave the same way. We currently suport offset, rotation, and scale from the spec. texCoord is not currently supported.
 
 The southwest corner of a region, at z=0, is the UV origin for all texture coordinates of the whole region. Unless an offset is also applied, scale and rotation of the terrain texture transforms are relative to that point.
 
@@ -50,3 +50,14 @@ If triplanar mapping is enabled, and an avatar faces an axially-aligned wall, th
 Textures of materials should not appear mirrored.
 
 When triplanar mapping is enabled, rotations on the axially aligned walls should apply in the same direction as they would on flat ground.
+
+## PBR Terrain Normal Textures
+
+This section assumes terrain normal maps are enabled at the current graphics setting.
+
+PBR terrain should have approximately correct lighting based on the normal texture:
+
+- When on flat ground
+- On cliffs, when triplanar mapping is enabled. Lighting will be somewhat less accurate when the cliff face is not axially aligned.
+- If no Terrain Texture Transform is applied.
+- If a Terrain Texture Transform is applied, especially for rotation or negative scale.
diff --git a/doc/testplans/pbr_terrain_composition.md b/doc/testplans/pbr_terrain_composition.md
index 731da90aba..bac0e8662e 100644
--- a/doc/testplans/pbr_terrain_composition.md
+++ b/doc/testplans/pbr_terrain_composition.md
@@ -44,6 +44,8 @@ The PBR terrain texture transform flag should be set automatically when logging
 
 When the PBR terrain texture transform feature is enabled, the UI of the Terrain tab should be overhauled. Availability of features depends on the type of terrain.
 
+**Known issue:** The Region/Estate floater may have to be closed/reopened a second time in order for the UI overhaul to take effect, after teleporting between regions that do and do not have the feature flag set.
+
 When "PBR Metallic Roughness" is checked:
 
 - There should be a way for the user to change the texture transforms for the terrain in the current region
@@ -87,6 +89,12 @@ If saving the terrain fails for any reason, the terrain should not be updated.
 
 Unlike a viewer without PBR terrain support, the new viewer will no longer treat textures with alpha channels as invalid.
 
+### Saving PBR Terrain Texture Transforms
+
+If "PBR Metallic Roughness" checkbox is checked, a user with saving composition permissions should also be allowed to edit and save PBR texture transforms.
+
+One texture transform may be set for each material swatch. Setting texture transforms for each individual texture on the material is not currently supported.
+
 ## Graphics Features
 
 Texture terrain with transparency is not permitted to be applied in the viewer.
diff --git a/doc/testplans/pbr_terrain_paintmap.md b/doc/testplans/pbr_terrain_paintmap.md
new file mode 100644
index 0000000000..0dab5fc2eb
--- /dev/null
+++ b/doc/testplans/pbr_terrain_paintmap.md
@@ -0,0 +1,48 @@
+# PBR Terrain Paintmap
+
+## Introduction/Disclaimer
+
+As of 2024-08-06, PBR terrain painting is **WIP**. Currently, there is only a client-side terrain paintmap, with no way to directly edit it. This document will explain how to informally explore this feature and compare it to the existing heightmap with noise. In the future, a testing document will be added for PBR terrain painting.
+
+## Background
+
+Historically, PBR terrain in a region has several parameters for controlling its composition. These are:
+
+- The four materials
+- The elevation of the terrain, which roughly controls the material, with some noise added on top ("heightmap with noise")
+- Material Elevation Ranges, which control where the materials start and end
+
+This allows for some coarse control over terrain composition. For example, you can have one corner of the terrain be a sandy beach and the rest of the coastline be rocky. Or you can have the peaks of your mountains be covered with snow. However, artistic control is limited due to the gradient imposed by the material elevation ranges, and the unpredictability of the noise.
+
+A terrain painting option would allow for more control over the terrain composition. The first step to getting that working is the paintmap.
+
+## How to activate the local paintmap
+
+The local paintmap is a good way to assess the quality of the PBR terrain paintmap. By default, the newly created local paintmap inherits its composition (i.e. where the grass and dirt goes) from the existing terrain. This allows for a direct comparison with the terrain heightmap-with-noise shader.
+
+Activating the local paintmap is similar to [applying local PBR terrain via the debug settings](https://wiki.secondlife.com/wiki/PBR_Terrain#How_to_apply_PBR_Terrain), but with a couple extra steps.
+
+You will need:
+
+- Four fullperm PBR material items to copy UUIDs from
+- A region with a good variation of elevations which showcase the four composition layers (no special permissions needed)
+
+Open the Debug Settings menu (Advanced > Show Debug Settings) and search for "terrain". The following relevant options are available:
+
+- LocalTerrainAsset1
+- LocalTerrainAsset1
+- LocalTerrainAsset3
+- LocalTerrainAsset4
+- LocalTerrainPaintEnabled
+- TerrainPaintBitDepth
+- TerrainPaintResolution
+
+By setting LocalTerrainAsset1, etc to valid material IDs, you will override the terrain to use those materials.
+
+The next step is to "bake" the terrain into a paintmap (Develop > Terrain > Create Local Paintmap). This will *automatically* set LocalTerrainPaintEnabled to true. **WARNING:** LocalTerrainPaintEnabled will *not* do anything until one of LocalTerrainAsset1, etc is set.
+
+You are now looking at the same terrain, but rendered as a paintmap.
+
+To compare the quality of the paintmap version and the heightmap-with-noise version, toggle LocalTerrainPaintEnabled in Debug Settings.
+
+To change the bit depth and/or resolution of the paintmap, change TerrainPaintBitDepth and TerrainPaintResolution as desired, then "re-bake" the paintmap (Develop > Terrain > Create Local Paintmap).