Merge pull request #2513 from secondlife/lua-merge-dev

Merge develop branch into Lua project branch.

4 files changed, 80 insertions, 1 deletions

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).