✨ Feature Requests

Vehicles are typically shiny, highly reflective objects. The go-to method for a very long time in game dev is to attach a reflection probe to the vehicle itself. It has been so successful of a solution that it's only now being replaced by raytraced reflections in ultra modern games. I feel Second Life could benefit from a similar system. How I envision the probe system working for SL is that when a linkset is being acted on by the llVehicle system and the agent is sitting on it, the viewer will place a probe at the geometrical center of the object. This probe will ignore rendering the linkset (including agents) and only have it's influence affect the linkset. There could also be an additional probe parameter as part of this system called Blending. This would control the blending between probes and the Hero Probe: 1.0 = Overrides Manual Probes 0.0 = Blends with Manual Probes -1.0 = Overridden by Manual Probes I envisioned this system having two important controls: a llVehicle parameter (defaulted off as to not change existing vehicle behavior) and a Viewer toggle for the system. I feel this would contribute greatly to the driving, flying, and sailing experience on SL as more PBR content makes its way out there. I've linked an example of a game that uses this hero probe system, BeamNG. It has several novel features regarding reflection probes and mirror simulation, but this video only focuses on the primary hero probe system: https://youtu.be/fUrOGDQ8nnY

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.

The problem is that terrain blending is currently inconsistent in Second Life causing a lot of grief and even some economic issues as people can't use landscaping products as they expected the land to look the same between viewers and operating systems. Terrain textures in Second Life are historically blended by using a Perlin Noise Generator to create more interesting variation: https://github.com/secondlife/viewer/blob/develop/indra/newview/llvlcomposition.cpp#L535-L554 The Perlin Noise Generator is expected to source the random numbers from a static seed (42) for repeatable noise for stable terrain textures as per: https://github.com/secondlife/viewer/blob/develop/indra/newview/noise.h#L313-L314 However, documented in another viewer source file it is mentioned that you should use a different random number generator if you want stateful random numbers as per: https://github.com/secondlife/viewer/blob/develop/indra/llcommon/llrand.h#L34-L37 This is because the functions used "srand" and "rand" from the c++ standard library are implementation defined and can even change across compiler versions / operating systems, which is why terrain blending can look different even across TPVs even if all the relevant code is unchanged. Therefore, I request that the viewer is updated to use a stateful random number with a fixed seed going forward as it is EXPECTED to work that way, as per the code's own comments left by developers in the past.

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.

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)

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.

No matter how much LL and the FS team fixes viewers and makes PBR available to more people, there will still be many who simply can't use PBR. Their current option is to use the older Firestorm release, which the FS team has promised to retain online indefinitely. But in such case PBR items (becoming increasingly common) appear solid white. That is not a desired experience. I am wondering if it would be possible for LL to create a "PBR Translator" for systems that cannot handle PBR / Advanced Lighting. Such a Translator would convert PBR textures to a suitable Blinn-Phong approximation, so that PBR items don't appear solid white. Such a translator would make the system more usable for a lot of people, and perhaps less laggy and crash-prone than the current system. I learned a long time ago that when it comes to computer software, practically nothing is impossible. It all depends on how dedicated someone is to achieving that goal. One would think for the sake of Second Life overall and the users who have been using it for years (as well as new ones who may be trying SL for the first time)... that a PBR to Legacy graphics translator would be a sensible addition.

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.

The ability to hide prims rezzed in other parcels above 1000m would allow users living in densely populated sims to not have their views obstructed by their neighbor's skyboxes. This would also include disabling the physics of hidden prims on other parcels so your neighbors cannot obstruct your own land. We can already hide avatars on other parcels, so this seems to be a logical extension.