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

How about allowing us to use mesh as reflection probes? Sometimes a cube and sphere don't work for us and by using a mesh we create we can use that as our refection probe for stuff like odd shaped houses etc

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.

Not necessarily in the same form. I don't think you want to draw all the skyboxes, that's going to look like trash. There are two ways of doing this, I think, which don't expose skyboxes. One is a full solution that takes a long time, like multiple quarters to a year. The other, you could probably launch in less than a quarter with not too much effort, and possibly 100% client-side with assets you already have. (Yes, really.) What for? To drive interest, naturally. Perhaps to recapture interest of people who left long ago. To spur more exploration, which then causes random encounters, gives people Something To Do (biggest problem w/ user retention in SL), etc. This kind of change could get you mentioned in articles on gaming publications. It will definitely get you mentioned on social media. I notice that when I fly around very quickly, I can see terrain and water from quite a long distance, like a kilometer or so. There's no objects, of course... _But it isn't bad!_ I like it! Unfortunately, it goes away pretty quickly, and I'm back to smog alert-level draw distance. To me, the really good, fully-complete solution would be this: Select all objects in the space between terrain and some reasonable altitude, like terrain Z+50 or terrain Z+100. This includes linked objects, so if you're selecting everything within terrain Z+50 and part of a link set is poking up to 55 meters above terrain, you get the whole link set. Bake that into something like a .kml every so often (daily/weekly/etc), Google Earth-style. Apply reasonable LOD. Beyond draw distance, fall back on that .kml-like mechanism. It'll be a little outdated sometimes, but so what. All we see now is smog! Obvious consequence of this: skyboxes don't show up. :) That's the full-blown solution that takes months to engineer, but it's a solved problem in computer graphics, and has been for well over ten years. I can look at Google Maps on a $200 Chromebook, and see that .kml stuff (sides of buildings, etc) just fine. Now, you're thinking, that is one heck of a project. Is there a quick, easy win that gets us part of the way there, right quick fast in a hurry? Like, something that could be banged out in a matter of _weeks?_ Yes! Here is what I propose, to get the ball rolling, measure user feedback, etc.: Let the user specify that terrain/water can be loaded past the draw distance. How far would depend on empirical testing. Maybe the answer is 1KM. Maybe it's 5KM. A terrain mesh is a 256x256 image, so we're not talking about a huge bandwidth impact. (You already stream the map to the viewer, so it's not like this is some undiscovered territory.) The upper limit is, more or less, "what can we draw on a high-end graphics card without turning it into a slide show?" You could give users the option to overlay the terrain mesh with the overhead map tiles you're already sending. This would make the terrain look odd here and there, as people sometimes put "sprites" way up in the sky: ads, drawings of hearts, airport/road hub information, etc. Still worth trying. With this, you don't see skyboxes either. Win-win. Now, what about sims that aren't edge-connected, like the private estates? What if you don't want to show one private estate from another, or from the mainland? I implemented an A-star algorithm that would pathfind its way across the grid as it existed in summer 2003. It ran in LSL back when that was a 16KB affair, and it ran fast even then. It even had the ability to back its way out of blind alleys! The algorithm that tells you whether you can see a terrain mesh from where you are, given arbitrarily long draw distance, is just that, A-star or something like it, written in the 1960s, and capable of running on 1960s hardware. This is not remotely difficult, or CPU-intensive.

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.

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.

It would be very beneficial to have a toggle to change the texture filtering on a material face to "nearest neighbour" instead of linear. (Especially for pixel art) This would allow for much better looking and efficient pixel art and is already a thing under the hood in opengl. This has been requested before but couldn't be done at the time because of database constraints for each object. But that would have already been changed with the support for PBR materials I believe.

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.