✨ Feature Requests

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.

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.

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)

Enable users to create and import on SL custom made shaders. Their computation cost could be evaluted and reflected in an li cost. Like VR Chat an option to disable user made shaders or maybe block some user's shaders could be added just like it already exist with derrender and block tools. Allowing post processing shaders would greatly improve the look of SL. See this proposition ( https://feedback.secondlife.com/feature-requests/p/suggestion-to-add-overlay-based-shaders ) It's a bit clumsy but it does show a need for more rendering customisation. SL being used by a lot of peoples to take screen shots of their avatars most using post processing from other sources like Reshade heavily. There is also this new viewer https://github.com/ApertureViewer/Aperture-Viewer/releases/tag/1.0.0 addressing this issue of giving post processing controls. Why ? -It would improve performance. Creators wouldn't have to rely on "hacks" to make certain effects like the so called cell shade and others. Adding details using Height map / bump maps without making the meshes more complex. Endless possibilties. And a better, more varied and interesting looking SL will always be a good thing on top of the perfomance gains from using less textures and meshes required to obtain the same effects. -It would reduce the amount of texture usage and thus cache size. If someone is able make a single master material for decors using classic video game industry standard techniques like World Aligned textures, Triplanar textures and whole lot of others techniques. Then just a single material could be used for an entire set of entities. (I don't even know if SL uses batching but that could also help batching. Easily batching more assets together before rendering them for quite a huge boost of performances in the rendering pipeline.) -It could be an extention of the already existing PBR material system. The current shader used could be the default lit one. And users could create their own with custom variables for parameters and textures that will be used. Just like we can see on Unity or Unreal. Maybe having a fallback lit shader in case it's disabled for any reasons listed here. -It would be quite an advanced new tool for many users. But it would really bring SL to more modern standards. If you can spare the dev time of an integrated shader graph like seen in game engines it would be even better. Allowing less experienced users to make their own shaders this way and also have more control over what is possible to limit any abuse and broken shaders that would tank perfomances / cause issues. -It could be tied to LSL scripting using a similar synthax as seen in Unity. Something like llSetMaterialFloatValue(llGetMaterial(link_index,face_index),"Transparency",1.0); And perhaps output a boolean to know if it failed or not. -It would actually probably indirectly answer a lot of other suggested features in one go. Like better water with waves. As well as open up other avenues for improving SL capabilities. Like tying shader params to LSL interpolated over time functions or being used in the particle system (that could use improvements as well) with maybe updating particle's variables over time for more stunning effects. It would allow to create better looking effects for a fraction of the cost than current methods uses. For exemple particle leashes could finally look continuous. -It creates a new market. As we all know at the end of the day money is what drives the world. So why pass the opportunity to make some by have a whole new kind of products to be sold ? Shaders effects and post processing ones could easily become a new thing people make exchange and sell on SL. -It could be part of Experiences. If people accept a land's Experience maybe it could allow for Experience Post Processing to be added. The download cost of few line of code from a shader is very low. Even if all items on screen used a custom one. The only real cost is user sided and should be limited if proper system are in place. Maybe have some kind of rendering cost calculator like seen in engines like Unreal canceling the upload and use of costly shaders. Maybe tie this to some of the rendering settings. Culling any shaders over a certain complexity. This would also probably give PBR a better image than it currently has in a lot of SL communities. If PBR was not only looking better but giving a new way of people to express their creativity through shaders. It would probably redeem a lot of the bad press it has. The only downsides are of course development time and costs mainly. As well as making the system able to limit abuse and be enjoyable by most users is also a big difficulty to tackle. But imho I think it would be worth it. You'll excuse the few typos, bad grammar and what not. I am not a native english speaker. Tho I am a game dev programmer with an interest in engine programing so at least there is a glimpse of knowledge behind my words if it matters.

Add a toggle to allow PBR emissive to be full bright or non-full bright . This would be good for small applications of glow that one wouldn't want to also full bright, but also for using the emissive layer as a non-glowing overlay layer, reducing the need for onion layers for various applications. In addition, add said full bright toggle to the PRIM_GLTF_EMISSIVE function in llSetLinkPrimitiveParamsFast and llGetLinkPrimitiveParams. Alternatively: Allow the normal SL full bright to affect PBR emissive, that way we already have all the options for toggling it normally.

Greetings This has been a bug for nearly 2 years now since all the recent FPS gain viewer updates and forward. ~I thought it may have been reported and hoped it would be fixed over the viewer updates, But now after 2 years i am here to file this report. This only seem to affect Rigged Meshes,. Unrigged prims/meshes are unaffected by this issue. Steps to produce the issue: Blender, create a cube and rig it to SL Skeleton... any bone lets say (mChest) for this test Copy the Cube 2 times and make each cube slightly bigger than the other. So we create a layer stack. SO Base / Middle and Top layer. So 3 seperated meshes intotal Export and upload the Rigged cubes to SL Now in SL. The Base layer can be left untouched Middle Layer, Set it to a color and assign a glow and give it some transparency lets say 0.5 glow and 0.5 Transparency The Top layer, Assign a Transparent texture >>> Give it a Default Normal map >>> And blank specular map Now activate Animated mesh on it and you will then see the glow does not shine through the very top layer. Solution to avoid glow being eaten.. Is to remove the Normal Map from the top layer, for some reason then the glow on the middle layer shines through. This bug does not affect default unrigged prims but does however affect rigged meshes. Can this be fixed please. This may even resolve the alpha blending issue on layer mesh stacking in SL Provided some image on information on bug within SL

Potentially a bit of a pie in the sky request here but... Tiled Texture Masking is a main stay of modern game rendering techniques that allow the use of lower resolution, smaller data, tillable textures in a manner that visually looks less repetitive, creating a higher quality end result from less intensive texturing. Second Life could GREATLY benefit from such a feature. It could be a drop-down option in the pbr materials menu to enable a procedural texture and allow the creator to put in 3 different materials and a map texture that uses the red green and blue channels to define masks for where each of the materials can show up on the face, using whichever channel value is the highest for that pixel with Red>Green>Blue as a priority fall back for any values that are equal. The alpha channel of the map would be ignored. Each material would still share the same offsets, repeats, animation settings, etc. To avoid too much strain that would potentially be caused by too many high-res textures. The materials for this feature should be limited to 512x512 at maximum for any texture that is a part of the material. A full suite of 3 materials that use all 4 textures at 512x512 with alpha layers and the map texture including an alpha layer would still take up less memory than a single material that used 1024x1024 textures with alpha channels for each texture in the material at 13mb vs 16mb. Take out the two unneeded alpha channels and remove the emissive mask and the numbers fall to 3.25mb (less than a single 1024x1024 w/ alpha channel) vs 10mb. Here's a youtube video of the concept by well known blender artist the Blender Guru on the concept. I have set the link to skip straight to the part of his explanation on how the technique works. https://youtu.be/1aNnERnHRZg?si=47z1q1197Nqs61Zi&t=376

Title says all the rendering is glitchy as flip I cant load Faerun for the life of it it wont even show a single object nor my maitraya avatar

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

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