✨ Feature Requests

Hiya everyone, i wrote some weeks ago already a feedback about the too high number of disconnects and crashes in SL and we got told during the round table meeting, that this will be fixed and LL is working seriously on this now. But all our sailors didn't stop thinking about the reasons of the disconnects and crashes as well and we are now very sure, that LL wont ever solve the problem with software changes. To explain why, we need to go some years back in history and and look at when the disconnects started to become a frustrating problem. LL moved SL to Amazon servers about 6-7 years ago, changed the crossing process for that and the disconnects began. During the 6-9 months test time i had minimum 10 crashes EVERY DAY and was very close to leave SL like a lot of friends did. It became less over the years, but NEVER stopped and a lot new friends start to leave SL frustrated. LL is doing a great job to make SL much more beautiful and exciting with new connected continents, much better graphics like PBR and many more things. That is like giving us a Porsche or Bentley to drive, but unfortunately they forgot to improve the roads as well and let us still drive on the dirt tracks with only 25km/h. This means for SL: Our sailors cut down the graphic parameters to a minimum, decrease DD and view angle to a minimum, reduce all their scripts in their active Avi to a miminum and more and more are using the old default Avi for racing to reduce the crash risk. And we thought for some times it would work, but it was a fake and the conditions didn't really change much. We talk a lot about our races after our races in our bar and the idea i want to write about now grew more and more. Our problem is the organization of the servers. There are about 5 regions on one server. They will be randomly new combined weekly with every rolling restart. That means for example region A, M, G, O, and W are this week on server 1 and next week the 5 regions can be on server 1, 5, 8, 15 and 20 and on sever 1 can be region H, D, P, Y and B. The regions are all different equipped and so the servers will work differently every week. In my last feedback i wrote, that we have in our race area regions, which are statistically worse that others and we crash there more often, but we didn't understand why that changes weekly. Now we know. I am not a server expert, but i am a shopping expert and i can tell you that shopping all your stuff in one big shop is much faster than to buy all in 5 differenmt shops. 5 shops can be a bit cheaper, but when time is my priority then i am willing to pay a bit more and can use the time i won for nicer things i enjoy more. Here is now our idea: Have neighbored regions like A, B, C, D and E on always server 1 and region F, G, H, I and J always on server 2... and so on. I don't have to change the server, when i cross from region A to B or C or D or E. Server changes happen a lot less, because i have neighbored regions on the same server and they don't get reorganized weekly new. I will win time for crossings and they will be much safer. if i still crash on some regions i can easier analyze the reason for that. I suggest to try and test this idea for example on a small part like Blake Sea area, if you need to test this idea on RC Channel first, because i think those regions should be all on RC Channel. Our racing community can support the tests in our race area, because that is all on Main Channel and there i will collect the feedback from our community for you. This will be a game changer and all your awesome work to make SL more beautiful can be used much safer and more. Isn't that a great feeling? Cheers Bianca♥

🔴 Summary 🔴 Second Life has come a long way, but OpenGL is becoming outdated. To ensure SL remains visually competitive and runs smoothly on modern hardware, I propose that Linden Lab begins development on Vulkan support as a long-term goal. This transition would greatly improve performance, reduce crashes, and allow SL to take full advantage of modern GPUs. 🟡 Why Vulkan? 🟡 ✅ Better FPS & Performance – Vulkan is optimized for multi-core CPUs and modern GPUs, meaning higher frame rates and less lag in complex environments. ✅ More Stability & Fewer Crashes – Vulkan manages memory more efficiently than OpenGL, reducing viewer crashes and graphical glitches. ✅ Future-Proofing Second Life – OpenGL’s development has slowed, while Vulkan is the industry standard for new and upcoming graphics engines. ✅ Improved Graphics Potential – Vulkan supports advanced rendering features that could enhance lighting, shadows, reflections, and materials in SL. 🟢 How This Transition Could Work Smoothly 🟢 Instead of a sudden shift, I suggest a gradual development plan (2025-2030): 1️⃣ 2025-2026: Linden Lab researches Vulkan feasibility and starts experimental development. 2️⃣ 2027-2028: An optional Vulkan beta mode is introduced for testing and optimization, running alongside OpenGL. 3️⃣ 2029-2030: Vulkan becomes the default renderer, with OpenGL as a fallback for older systems. 4️⃣ Community Engagement: Regular updates from Linden Lab on progress, plus support for third-party viewers adapting to Vulkan. 🔵 Why Start Now? 🔵 Even though this transition will take years, starting early ensures SL stays ahead rather than falling behind other virtual worlds. A well-planned Vulkan integration could attract new users while making SL smoother for current residents. If you agree, please upvote and share your thoughts in the comments! Let’s show Linden Lab that the community is ready for a modern and optimized Second Life! 👍 💬 �

Having regions stuck in a crashed state for 15+ hours due to the lack of support and inadequate tools to address such problems is unacceptable. This is a common occurrence, and as I write this, one of my regions is experiencing this very issue. As a 20-year veteran of Second Life, I remember when Concierge support was available 24/7. We still need that level of support or the tools to handle these issues ourselves. Landowners like myself spend tens of thousands to hundreds of thousands of dollars per month on our regions. This level of support neglect is detrimental and will ultimately hurt Linden Lab financially. Cutting support for your backbone is not a sustainable strategy. Even implementing a dedicated "Region Offline" 24/7 ticket handler to quickly bring downed or crashed regions back online after support hours would be a step in the right direction Please reconsider and restore the necessary support to ensure the success and satisfaction of your loyal customers.

Will we see a switch from the outdated Open GL to Vulkan anytime soon? Vulkan generally runs PBR (Physically Based Rendering) better than older graphics APIs like DirectX 11, Open GL because it provides a much lower level of access to the GPU. Can also solve the overheating issue with PBR.

Please make a versions of the Second Life viewer for Windows on ARM chips.

With the new "extraFPS" second life viewer, i've noticed a massive decrease in actual frames per second even with a top end rig. i'm not sure why this is the case considering the video philp linden put out today and it looked so smooth! Please can i have some help with this.

I keep getting logged out within about 15 minutes of being online.

Avatars can take a long time to have clothes on etc when teleporting though my own avatar was already baked before teleporting. It would be much more pleasant to be displayed instantly, even if others don't see my avatar immediately but after a certain time, the same way i see them as clouds until they are rezzed.

Add a maximum FPS setting for users who which to throttle how often Second Life updates. This is particularly important for users with high refresh rate monitors, where even with vsync enabled SL will run 145 fps+. This is important as SL currently uses as much GPU resources as it can, turning computers into toasters.

As discussed briefly at the Server Users Group on 2025-10-15: it is apparent that the graphics team is interested in exploring the possibility of integrating certain virtual reality features into the standard SL viewer (again). Attendees brought up concerns including challenges maintaining a high framerate and the low market penetration of VR hardware. This post was revised on 2024/10/24 in light of Crexon's remarks that telemetry already exists in the SL viewer via the tracy library. To substantiate these anecdotes with concrete data, I'd like to propose a strategy for collecting and sharing information: Conduct a hardware survey to assess the market for adding VR features. This could be as primitive as a Google Forms page with voluntary data submission, or something more sophisticated like adding a hardware profiler to the viewer itself. An explicit poll might be useful for gathering data about VR hardware deployment or the potential of buying VR hardware. Open up basic aggregated data gathered by the profiler so SL residents can see what counts as 'typical' performance. Present average FPS, normalized by polygon count and m² of visible textures, as well as standard deviation of framerate (FPS stability). Segment on teleportation or graphics setting change. Also aggregate performance data on a per-region basis. (No idea if you guys do this already—sorry if this is redundant.) Prior to anonymization, aggregate data on a per-region basis, allowing establishment of a performance index for each sim. This can then be used to normalize data over a certain time period, correcting for biases in data caused by popular or overdecorated regions. Present alongside figures for mean region FPS (time dilation) and population to establish a sim performance score.