✨ Feature Requests

When traveling, shopping, exploring, building, etc. with friends, it would be a nice function built into the client to be able to copy the position and focus direction of my own camera to paste into chat or IMs so that other users have the option to left-click/touch/tap it (similar to a SLurl, maybe call it a SLookAt? lol) to look at whatever it was I was looking at. I know there are scripted camera gadgets that can already do this, but having a native copy/paste "Look at this thing" function in the client itself would be immensely helpful for keeping users (especially new users) within the client instead of paying for a gadget or needing to rely on video screen-sharing in third party apps.

Hey everyone, I’d like to suggest this feature because banning someone should give a venue some protection against them coming straight back on another account. I work at Actually Love, a dating agency in Second Life. Like other businesses and public venues, we deal with griefers who threaten to return on alts to keep causing problems. Recently, someone threatened to come back on five alternate accounts to harass our staff and visitors. Abuse reports have been filed, but so far we haven’t seen anything come of them. My suggestion is that when an estate owner or estate manager estate bans an account, its IP connection and any accounts Linden Lab knows belong to that person are also blocked from entering the region covered by the ban. Linden Lab could also use device identifiers to help recognize accounts returning from the same computer, even if the IP changes. Accounts identified as associated later should be included, and known associated accounts should stay blocked when they change connections. Linden Lab would handle this privately. Estate managers, staff, and other residents would not be shown alt identities, account links, IP addresses, or device identifiers. Those accounts would simply be denied entry. They could still log into Second Life and visit places outside the region covered by the ban. I understand connection or device restrictions could also affect a partner, roommate, or someone sharing a computer. Managers should see a clear warning before applying these restrictions and be able to remove them without lifting the original account ban. They should also be able to allow a specific account as an exception if someone unrelated gets caught by it. This won’t stop every attempt to get around a ban, but it would give us a better chance to stop repeat harassment. Staff could spend more time helping visitors and running the venue instead of waiting for the next alt to show up.

We already have avatar complexity controls that help limit how demanding other avatars are to display. I’d like similar control over objects and scenery, available to every resident without needing land ownership or estate permissions. Sometimes a location looks fairly simple but still causes a noticeable drop in FPS. Poorly optimized mesh, excessive detail, and heavy texture use can contribute to that, yet visitors don’t have a straightforward way to identify which objects are the most demanding. Lowering graphics settings affects the entire scene. Residents should also have the option to find and hide individual objects that may be hurting their performance. The main request is a simple viewer tool that lets us: List nearby objects and sort them by estimated rendering cost. Select and highlight an object so we can identify it. Derender that object directly from the list. Easily review and restore anything we’ve hidden. Where practical, the tool could show useful details such as triangle count and texture usage, with a clear explanation that rendering cost is an estimate and performance varies by computer and settings. An optional object complexity limit, similar in purpose to avatar complexity controls, would also be useful. Users should be able to exempt selected objects from automatic hiding, particularly buildings, floors, and objects they need to interact with. These controls would affect only the resident’s own view. They would leave the build and everyone else’s experience unchanged. Even starting with the sortable list and manual derender/restore controls would give residents a practical way to troubleshoot low FPS. It could help people stay and enjoy shops, venues, and events where they might otherwise have to leave because of poor performance.

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

Group chats lack the ability to be moderated like in most forms of widespread chats. As such we get things such as scam links, hate speech and various other undesirable aspects. I propose we add a new feature to groups that allows the ability of chat moderator. That chat moderator(s) is able to delete chat sent, mute a participant from chat for x minutes, 0 would be forever making them unable to chat. Chat moderation could allow for things like blocking hyperlinks all together, muting people indefinetly within the group chat.

To further optimize environment rendering and reduce the massive alpha-sorting overhead currently found in many Second Life regions, we could implement a native way to handle "decal" layers extremely efficiently. Currently, creators simulating stains, rust, signage, grime, and variations must place thin mesh geometry slightly offset from a surface using Alpha Blending. This forces the renderer to perform expensive transparency sorting calculations on every single frame tick to determine pixel draw order, while frequently introducing visual artifacts like z-fighting at mid-to-far camera distances, or even in high altitude skyboxes. Key Considerations: Optimized Alpha Pass Routing: By introducing a dedicated checkbox/flag in the Object Properties and/or Material panel to designate an asset or material-slot as a "Decal," the renderer can route the asset or slot through a specialized, high-efficiency shader pass, tailored to making decals both better performant & better looking. Elimination of Alpha Sorting and Z-Fighting: A designated decal shader pass allows the graphic pipeline to project or clip the texture directly onto the underlying static geometry buffer. This forces the decal to cleanly adhere to the surface below it without requiring continuous frame-by-frame alpha sorting depth checks, yielding superior visual quality and an immense performance lift especially in dense regions/builds. This is not a demand, just a logical suggestion IMHO, something you may have already been considering. It could be both relatively simple for you to implement (based on your choice of industry standard techniques), and bring considerable positive impact on looks and performance.

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.

Simple request - people ejected or banned from groups, shouldn't be notified that they have been. Sometimes a user is being removed through no major fault, or for fault that isn't immediately occurring within the group itself. Being able to remove or ban silently is less likely to cause immediate or more volatile response. Sure, sometimes it'll still happen - but there's also good chance it'll go by unnoticed, or unnoticed enough for tension to die down. You aren't notified when someone removes you from their friends list, or bans you from a region or parcel - so why are people still notified when they're removed from groups? If the admins wish to inform a user a reason for the eject / ban, I don't see why they can't just send an IM of their own accord. I don't currently see good reason to keep these notifications.

When we import mesh, we can attach a custom physics modle to the mesh. But, we have to rez in-world, then change the physics shape type from Convex Hull to Prim in order to use the physics we attached, then take back into inventory. For every build with custom physics, this is a strange annoyance. For large builds with many parts, this is crazy! Can there be an option in the uploader, if a physics mesh is included, to set physics shape type to Prim? A checkbox, maybe, on the Physics tab when a model is chosen?

Lately a lot of SL groups have been getting hit by spammers posting phishing links that look like real Marketplace stores. Here’s an example of the kind of thing going around: [12:16:37] Rẙaḽīể (ryalie): New store! Outfit + Shape, Everything is free, limited quantity https://marketplacsecondlife-style-body-mesh-catwa-185089.store It’s clearly meant to trick people, and residents are falling for it because it looks close-ish to a legit SL URL. People are losing their Lindens because their accounts become compromised, thinking they’re logging into a trusted site. The scammers then use those compromised accounts to spam other groups (sometimes even pay-to-join ones), which just keeps the cycle going and leads to more stolen Lindens and MORE hacked accounts. My suggestion is to remove clickable URLs in group chat and IMs unless they’re from trusted sites. Maybe have a whitelist for known, safe domains like: marketplace.secondlife.com secondlife.com community.secondlife.com flickr.com primfeed.com gyazo.com Or other KNOWN and trusted sites. Everything else could just show up as plain text or with a warning before opening. Other possible options could include: color-coding links (safe ones in green, unverified ones in grey or red), adding a short delay before opening non-trusted URLs (“This link will open in 5 seconds”), or even giving users a setting in Preferences to allow clickable links from trusted domains only. This would stop a lot of the spam and protect people from phishing. It would also cut down the workload for in-world group moderators (who constantly have to boot spammers) and reduce support tickets from compromised accounts; meaning less work for your support team, cost savings for you, and a safer experience for everyone. Thank you!