✨ Feature Requests

the probes can get in the way when building turning off there selection is great but sometimes you need to turn on highlight transparent and then the whole area is covered in red spheres and boxes making it difficult, would be nice if they toggled off from highlight when there selection is disabled

Loading into a large event, or a well-decorated region can be a hassle, especially for those on low-end computers. It is not uncommon for vendors to use high resolution textures that seem to load after everything around you has loaded first. This often forces users to idle for long periods of times in shopping event regions and stores, just waiting to see the things they might want to buy. In the early days of an event's opening, this often means jam-packed regions for multiple days straight. This request will help ease this bottleneck, and allow those on lower-end machines to shop with ease. I am suggesting an optional setting in the edit window that pushes an object's textures to the front of the rendering queue. This option would only be enabled for objects a user owns, that are modifiable, and that are set to sale, or have their "click to" setting set to "Buy" or "Pay". By default, with this setting enabled, a user would see these priority objects' textures load in first, before anything else, with all other objects displaying the unloaded grey texture until the priority objects are finished. In addition, there should be an option in preferences to ONLY load textures on priority objects, leaving everything as untextured mesh shapes, and one to IGNORE priority and render objects normally. In any case, avatars, terrain, and environments would be unaffected by this setting, since they have their own optional rendering settings already. It's kind of a "show friends only" but for vendors!

Is there a function to llOffsetTexture using PBR Materials?

New graphics preferences to control how many additional regions your client will render. I have seen this feature before in an older client and I really loved that level of control. This gives users much better control over their performance allowing them to determine how many additional regions their client will render. Draw Distance would still affect additional regions being rendered. The way I would suggest handling this is through two additional sliders in the graphics preferences under a new category: Region Visibility Region Grid Range: A slider (1-9, unlimited option) This controls how many grid layers can be rendered Set to 1 you will see any regions directly connected to the region you are in (including connected by corners) Set to 2 in addition you will see any regions connected to the layer 1 regions, and so on Region Rendering Limit: A slider (0-361, unlimited option) This controls how many additional regions in total the client renders Set to 0 you will only see the region you are in Set to 1 you will only see one additional region closest to you Set to 2 you will only see the two regions closest to you, and so on The reasoning behind adding the Region Grid Range slider would be allowing for higher draw distances while still limiting how many connected region grids you can see. As an example if I kept my draw distance at 4096, but kept my Region Grid Range to 1, I would then see every region connected directly to the region that I am currently in but nothing beyond that. If set to 2 I would then see every region connected directly to the region I am in, and then also any regions directly connected to those additional regions.

Title says all the rendering is glitchy as flip I cant load Faerun for the life of it it wont even show a single object nor my maitraya avatar

I just tried the HDRI Preview feature. I did love the effect it had on the environment light, but using the HDRI I tried with (the one initially recommended by you at LL for PBR work) did cause a field to be drawn on the sky dome, which looks really funny and out of place... screenshot attached with a view from an unenclosed skybox. In my case, a simple sky-and-maybe-clouds texture there would probably be better. I'd love to see this feature evolve to where one is able to upload an EXR or HDR file and apply it to the environment. I'd also love to see the feature evolve such that... The light from the HDRI is kept but the rendering of the image on the dome can be disabled. This effect is possible to set in both Blender and Substance Painter for example, also an option to blur it. In conjunction with the above feature, combining the use of an HDRI and the animated cloud texture we already have today, and the clouds should of course cast shadows! This would be great especially when you have very small or no clouds in the HDRI texture when you choose to keep it rendered. I'd love to be able to have one HDRI above, and another one under sea surface. Combining this with the previous mentioned features could allow for really cool effects under water! The ability to set one HDRI for environment light, and a separate HDRI for "texturing" the dome. Setting this texture to a built-in Transparent texture (or a new one like that for HDRI) could be the mechanism to cause the first-mentioned feature of hiding the image of the HDRI on the dome, only keeping its light. Without the above few features, I wonder if this feature would end up only really being good when you're taking photos. Hope this makes some sort of sense... Thank you! =)

Many lower-capability devices contain very high DPI screens, such as thin and light laptops with 3k displays and integrated GPUs. The ability to reduce the render resolution of Second Life to a "1080" equivalent would significantly help performance on this class of devices. Two improvements would allow a significant FPS increase: Allow the "RenderResolutionDivisor" debug setting to have fractional values. Third-party viewers have a separate "RenderResolutionMultiplier" setting for this, but the official viewer lacks similar functionality. Expose the RenderResolutionDivisor/RenderResolutionMultiplier as an advanced graphics setting in the UI. This would allow people with very high DPI displays to easily boost their performance.

Terrain height maps use lossy compression, which causes land spikes around sharp slopes of terrain. The amount of data for the land height must be minuscule compared to all the other data in the scene these days. Make terrain lossless, and allow true WYSIWYG editing of the terrain height. Notes: This would require a server component for physics as well. This would require a step where the current lossy height map is baked down to a lossless height map.

Dear Second Life Development Team and members of our community, I would like to suggest a feature that allows users to load only the parcel they are currently on. Implementing this feature could offer several benefits: + Reduced Lag: By loading only the current parcel, the viewer would not need to process adjacent parcels, leading to a smoother experience and significantly reducing lag. + Improved Performance: With fewer items and scripts to render, users with lower-end hardware would experience better performance, making Second Life more accessible to a wider audience. + Efficient Resource Use: This feature would decrease the strain on both the user's computer and Second Life's servers, leading to more efficient use of resources. + Focused Experience: Users can concentrate on the area they are actively engaging with, enhancing their immersive experience without distractions from nearby parcels they are not interacting with. + Optional Toggle: This feature could be optional, allowing users to choose between loading only the current parcel or the surrounding areas based on their preference and device capabilities. I believe these improvements would greatly enhance the user experience and performance in Second Life. Thank you for considering this suggestion. Best regards, Jesiris Resident

Is there a way to setup the shadows for eachlights ? For example an outdoor shooting with bright sun and an umbrella, the sun shadow is sharp and umbrella shadow is soft.