✨ Feature Requests

Just what the title says. The ability to de-render all objects owned by a resident, or de-render entire parcel.

Storing color data in the vertices of our meshes allows the PBR shader to run an efficient, client-side linear multiplication of that color over the Albedo/Base Color texture map. This is incredibly useful for breaking up macro repetition on trim sheets and tiling textures across large builds in a far more precise way than the full material slot tinting we have now. It allows creators to reuse materials more heavily without resorting to unique bakes for every single wall or structural chunk, mitigating excessive decal use and secondary macro-variation layers. This workflow is ideal for adding fine artistic control, such as deeper ambient occlusion shadows in crevices, highlights on edges, or entirely new stylized aesthetics (like low-overhead cartoon texturing) that rely primarily on vertex colors for variance & styles. Key Considerations Texture Memory (VRAM) Savings: Texture memory consumption is a primary source of client-side viewer lag and texture thrashing. By allowing vertex colors to drive object-based ambient occlusion, gradients, or unique room/object shading variations, creators can aggressively reuse a very small set of tileable materials or trim sheets while maintaining visual variety. Without this, creators frequently tend to generate massive, unique texture sets for every single wall and asset variant simply to display localized baked ambient occlusion & variations. Reduction in Alpha Pipeline Bottlenecks & Mesh Bloat: Currently, creating macro shadows or grimy variations requires duplicating face geometry shells to use as decals or AO layers. This forces the engine to run overlapping draw calls and increases geometric complexity. Furthermore, if creators use alpha-blended textures on those shells to soften shadow edges, it triggers expensive depth-sorting calculations which can tank viewer frame rates. Moving this occlusion data directly into the vertices removes the extra mesh layers & textures entirely and completely eliminates alpha-sorting overhead. The glTF Pipeline "Easy Win": Because Second Life's rendering engine is now anchored to the glTF 2.0 specification, the underlying framework for this already exists natively. The mesh importer simply needs to retain the COLOR_0 attribute data during processing instead of stripping it out, and the PBR shader needs an efficient vertex color multiplier step applied to the base color factor. Perhaps if you choose to move forward with this you'll also consider some Object Properties panel settings, likely an on/off checkbox for vertex color effect and a slider to tweak its power would be more than enough. Maybe even opening this up to scripting could prove interesting for creating all sorts of different techniques and effects that leverage vertex colors. For Vertex color you get the full RGB spectrum to multiply over the albedo, but that still leaves the alpha channel you could potentially use for other things, like adding emissive, or even going as far as allowing a two material texture blend shader. Using the alpha channel to control emissive would be super light and efficient, but material blends can get heavy if not optimized properly, still it is possible lol, so I figured I should add it in context. Community Discussion Reference: I made a community thread to gauge interest and feedback, which can be found here: https://community.secondlife.com/forums/topic/534987-any-thoughts-on-adding-vertex-color-multiply-to-the-new-pbr-shader/#comment-3097036 Just to be clear this is no demand nor expectation! Its just an inspiration I had when considering you all are working on performance boosts and adding new features for creative potentials, I feel like this could be an easy win in both regards.

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.

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.

I build race tracks, full sim builds, and lighting them can be a problem because of the maximum 20 meter radius: in real life, lights are usually outside the track and shining in, so the lighting ends up looking wrong by having to put invisible light sources close to the track. With the ability to use light sources from longer distances, we'd be able to make much more realistic looking tracks, with more realistic reflections and shadows on the cars. I can also see this being a big benefit to clubs, other sports venues, airports, and live music setups. There have been so many changes to lighting and shaders in SL, but the light radius is still what it was when I started in 2006.

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.

Current local light rendering is done from the light nearest to the camera, in order by distance, up to the RenderLocalLightCount. This has a set of disadvantages, e.g. the lighting on the subject can change when moving the camera (with Count < the number of lights in range), the lights near the subject are not necessarily lit, etc. Imagine filming with the lights on the camera, not the subject. Just ... no. When the user picks the subject using Alt/Point/Left-Mouse/drag.., the lights nearest that point are the ones to prefer. The current list and sort order code is retained, but the sort key should be a distance_from_camera_cursor, not distance_from_camera*. May require the continuity of any other code using the existing sort, so new sort switch should be added, old by default. Switch on prior to sorting the distance table for light management. * my labels for the purposes here, not labels looked up in code.

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

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.

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!