Feature Requests

I can not build in a way that allows for daylight and shadows on mainland without someone else's skybox interfering with my experience.

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/

In modern engines the ability to bevel an edge can make simple prim constructs seem more natural and add complexity to the build. This can be achieved by using mesh, but the LI, and bespoke nature of mesh, would cause issues with stretched mesh not being beveled correctly.

Dear Second Life Development Team and members of our community, I would like to suggest a feature that allows users to load only the parcel they are currently on. Implementing this feature could offer several benefits: + Reduced Lag: By loading only the current parcel, the viewer would not need to process adjacent parcels, leading to a smoother experience and significantly reducing lag. + Improved Performance: With fewer items and scripts to render, users with lower-end hardware would experience better performance, making Second Life more accessible to a wider audience. + Efficient Resource Use: This feature would decrease the strain on both the user's computer and Second Life's servers, leading to more efficient use of resources. + Focused Experience: Users can concentrate on the area they are actively engaging with, enhancing their immersive experience without distractions from nearby parcels they are not interacting with. + Optional Toggle: This feature could be optional, allowing users to choose between loading only the current parcel or the surrounding areas based on their preference and device capabilities. I believe these improvements would greatly enhance the user experience and performance in Second Life. Thank you for considering this suggestion. Best regards, Jesiris Resident

The ability to assign an object as a volume to either be a mass of water, or remove water, this could work in the same manner as reflection volumes, but would allow builds to be able to be in a body of water without rendering water inside, or using the underwater shader, an inverse would also allow expanded creation of areas with sim matching water in builds that are above the sim water level

Please introduce a new set of HUD attachment points with perspective rendering capabilities, allowing for HUD objects to have depth and Physically-Based Rendering (PBR) lighting effects on HUD elements. Current Situation: At present, Second Life offers a series of attachment points for the HUD (e.g., bottom, bottom left, center, center2, etc.). These HUD elements are rendered as though they are attached to the view camera using an orthographic perspective. This limits the ability to incorporate depth and advanced lighting effects into HUD designs. Eg, if I want to draw shiny spinning gold coins on a game interface, they look flat and solid yellow. Proposed Enhancement: Add a new set of HUD attachment points that prepend "Perspective" to their names (e.g., Perspective Bottom, Perspective Bottom Left, Perspective Center, Perspective Center2, etc.). These attachment points will render HUD elements in a perspective frame, enabling designers to leverage depth and PBR lighting effects. Positives: Allows for more immersive and visually appealing HUD designs by incorporating depth and realistic lighting. Provides designers with the option to choose between orthographic and perspective rendering based on their specific needs and creative vision. Makes HUD elements in 3D Secondlife look like 3D things!

I've noticed that there will be way to adjust the gamma of the alpha channel for textures to compensate for the change from sRGB to linear gamma, e.g. referenced in this issue on github https://github.com/secondlife/viewer/issues/2655 I have not seen mention that the adjustment would be available for particles, but it definitely should be as they too can be just as affected by the change in rendering. Unfortunately there would be no easy UI-based way to add such an adjustment by end-users, but at least a new parameter for llParticleSystem would let allow scripters to fix their effects.

Although interpolation and movement smoothing are generally A Good Thing, there are many situations where it is distracting and undesirable behavior because the change represented is supposed to be instantaneous. In these cases, the visibility of the motion impinges on the convincingness of the situation, leading to either a threat to the user's suspension of disbelief (for objects in-world) or a reduction in the perceived quality of the product (mainly for HUDs.) Personally, I find this happens a lot when repositioning HUD elements that were previously off-screen; particularly annoying are cases where the final state of an element is, due to rounding errors, imperfect. But it can also happen with in-world objects that are meant to suddenly appear or move, such as a door that snaps between open and closed positions (and unintentionally tweens through a space it shouldn't), or an "instant" forcefield that actually takes a half second to stretch to the intended size. In these situations, interpolation causes "jank," which is not in-line with the goal of presenting users with a polished, modern virtual world. The interface for this would probably be something like: llSetPrimitiveParams([PRIM_INTERPOLATE, <TRUE/FALSE>]); which would default to TRUE. Ideally, if a child prim has PRIM_INTERPOLATE set to FALSE, then movement applied to the entire linkset would still cause interpolation for even that child prim. If this is inconvenient to implement on a per-prim basis, then a simpler per-object basis (maybe a new llSetStatus flag?) would also be very usable.

Right now clouds are a 2d map that gets manipulated by sky settings. It has been this way for 20 years? The current state of the art is Volumetric - Using this for clouds would enhance skies, and could be used to overhaul the billboard 2d particle system as well.

So when using ambiance and HDR settings, we lose the possibility to increase gamma on the Windlight settings, which always worked as a mean to increase exposure and get a proper and bright sunny day. Since we got PBR, using those settings makes shadows very dull, ambient lighting it's excesive even setting them just at 1.0 and the sun barely changes increasing it's color value above just 40. We definitely need some way to make the light of the sun stronger while keeping the darkness of the shadows because right now we have to choose between one of the two. So everything it's either too bright and lacking shadows or too dark and lacking lighting from the sun. This request goes tied to a better management of the auto exposure settings as well.