✨ Feature Requests

Optically you can see from a region to the next one - the sim border is invisible. Physically though the next region does not exist until you travel over the border between the recent region and the next one. Let's suppose you are traveling by boat. If you hit a pier in a region, your boat is bounced back. But if you hit a pier located on the next region reaching until the region's edge, your boat first travels over the sim border and suddenly gets caught in the pier bouncing like crazy. Suggestion: the physics engine of each region should also load (render?) the physical shapes of the neighbor regions borders, which are pointed to the region, so a vehicle is bounced back and does not enter the next region where it is blocked by some object. Advantage: physical experience would be far more natural, collisions on sim borders would not be special. Since it is very common to build right until the sim borders, this is issue not a trifle at all imo. Vessels that have a damage system responsive to collisions (to make sailing more challenging) use to sink immediately when hitting these sim edge builds (since being caught on an object causes plenty of collisions in a very short time), while they would only take some damage while hitting the same build from the other side. This particularly is annoying, if there is a very tiny or even invisible object on the sim border, so you have no chance to recognize it before your ship suddenly sinks for no obvious reason.

The freezes are especially annoying with vehicles. Some places can cause rendering to stop for most of a second as you move near them. Specs: CPU: Intel(R) Core(TM) Ultra 9 185H (3072 MHz) Memory: 65015 MB OS Version: Microsoft Windows 11 64-bit Graphics Card: NVIDIA GeForce RTX 4070 Laptop GPU/PCIe/SSE2 Maximum bandwidth setting: 8,000 kbps Test 1: Standing still Draw distance: 512 Position: NE Albion, looking west towards Abbotts Framerate: Stabilizes around 11FPS CPU: ~11% GPU: ~18% Test 2: Flying unassisted: Albion - Yamato Draw distance: 512 Framerate: Varies between 4-8FPS CPU: ~20-30%, occasional spikes to 49%, depending on object density GPU: ~18%

At present, lights are clamped to an "imaginary" range of 0 to 1 that have no basis in physical reality. The GLTF spec defines a physically based light falloff and specifies real world radiometric units - which is aligned with most major game engines and 3D modeling applications. This change should apply to all sources of lights - point lights, projectors, and the sun/moon. Sun/moon would be easiest to support first.

As it stands, Second Life (secretly) supports global illumination via reflection probes. This is confusing to users - as we only really specify it as part of the reflection probe. In reality, there's often a need to have more light probes for GI than there is for reflection probes. This change means that: Probes can have three modes. Reflection, light, or both Existing probes would be both for reasons of content compatibility Potentially, changing how we store light probe data (using spherical gaussians or spherical harmonics or some such)

SL has for a very long time supported dynamic shadows for up to two projector lights. This requests asks for: A viewer-controlled count of shadow casting lights Shadows on point lights Note that this has technical implications in the viewer, namely how shadow filtering works. The shadow filtering in the viewer is handled as a post process that can filter up to four shadows in the viewer - ambient occlusion, sun/moon, and up to two projectors. This change requires changing how shadow filtering and sampling works, which in turn changes how shadows will look.

Creating an environment means you have an idea how of the sky, lighting and colors of the scene look. By adding a tonemapper to the mix, which is hidden as an advanced graphics setting and defaulting to a different one than we have been using to build our PBR content in the past year feels counterproductive to the effort put into said content. The tonemapper could instead function as a parameter of the EEP sky. Default all legacy settings that have not been resaved under PBR to Khronos, default ones that HAVE been saved under PBR to ACES-linear mix, and make them all editable to whichever mapper+mix level as desired after the fact. Additionally, add a feature to override the EEP tone mapper to use a fixed one instead of environment-based, giving the functionality that exists right now in viewer 7.1.11 - one tone mapper to rule them all. Discussion on the subject and source for the idea: https://community.secondlife.com/forums/topic/517003-khronos-tone-mapper/

Now the mesh in sl has no physics at all, you wear stiff clothes, with stiff hair, as you walk, the fabric stretches against your body into strange shapes, when you sit down, your long hair will bend 90 degrees to fit your legs. everything is very stiff. When i see those long flowing hair and those fluttering gorgeous skirts, i miss the good old days. Even though they look messy sometimes, but that's intuitive. But the prims is behind the times, everything is in mesh now. Why not give mesh physics too! Mesh greatly improves the quality of props in sl, but it loses the most intuitive physics, they just look good, but once they move, they will reveal their flaws. This is just like how people used to paint gloss on textures, only viewable from the front, otherwise it will be a mess. Now we have the advanced lighting, PBR, make objects looks more and more real, there's one step left, that is mesh physics! Imagine a cute girl with long flowing golden hair, wearing a flowing dress, dancing gracefully, her hair and clothes fluttering with dance, how beautiful! You must watched MMD dances! fluttering, inertia, collision, make MMD dances lifelike! SL need mesh physics, we can dance in sl like MMD! Many similar games already have these physics effects, but sl has not yet, please! If we have mesh physics, how to deal with rigged object is a problem. Could we make old items physics-enabled with edit? Or only the authors can handle it to release a update? What tools could authors use? There's really many problems.

As we hide SL water using the Exclusion layer, it would be a great idea if particles could be hidden too using this layer. Perhaps particles would need a flag to allow them to be hidden or not. This couild be used in boats, where we want to hide water and water spray from entering the hull.

A parcel setting that would derender all objects and avatars outside of the parcel boundary. I believe this setting would be welcomed by many particularly on mainland parcels. It would be entirely optional to use but would make mainland parcels a more viable option for every resident. I also believe a side effect of a setting like this would be to "clean up" mainland in general, reduce the use of ugly privacy screens, inappropriate skyboxes as ground level etc as the need for them would be lessened. This setting would also improve performance within parcel boundaries due to lower render load and not require residents to manually adjust draw distance to improve performance. This setting would be entirely optional and disabled by default.

This function is available in Firestorm and is one of the biggest helpers in SL, both for shopping on full sims and for photography on busy sims. Please implement in the main viewer! Thank you!