✨ Feature Requests

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.

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!

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

Note: This issue was previously accepted on the JIRA as BUG-231731 in 2022. Resubmitting it to the Canny because I think the idea has been lost in the move. The feature requested is a high performing set of functions that can draw text onto prim surfaces. With multi-line support via \n, measured font sizes, batched draws, and baked font styles compiled into the viewer engine. Restrict this feature to face 0 of the LINK_ROOT prim in an object. A maximum arbitrary number of "screens" could be allowed per region. The maximum limit of llInitDrawString calls per region could be set to for example 256. Attachments would not contribute towards this limit. Styles baked into the viewer originating from ttf: integer FONT_STYLE_DEFAULT = 0; // e.g. arial integer FONT_STYLE_ARIAL = 0; integer FONT_STYLE_CANDYSCRIPT = 1; integer FONT_STYLE_SHELLEYALLEGRO = 2; integer FONT_STYLE_BAUB = 3; LSL prototypes: llInitDrawString(integer fontstyle) Initializes the text context. If this is called again with the same style it should silently return. If called with a different style then change the style. In C++ call initialize the opengltext to delete the previous glyphInfo. If the GLSL program is already linked it is reused. parameters: fontstyle: Uses an integer of FONT_* constants that reference baked fonts llBeginDrawString() Begins drawing. float llMeasureString(string text) Measures the size of the string. parameters: text: The text to draw return value: The measured size. llDrawString(x, y, text, color) Draws the string at the position and color. parameters: x: x position y: y position text: the text string color: the color llEndDrawString() Swaps the buffer onto the face of the prim. Note: llBeginDrawString just sets an integer in the C++ code to 0. Example SL script: drawMyStrings() { vector pos1 = <0, 0, 0>; vector pos2 = <0, 30, 0>; vector pos3 = <0, 60, 0>; vector color1 = <1,0,0>; vector color2 = <1,1,0>; vector color3 = <0,1,0>; string text1 = "Hello World!"; string text2 = "It worked."; string text3 = "This is a\nmultiline string."; vector sz1 = llMeasureString(text1); vector sz2 = llMeasureString(text2); vector sz3 = llMeasureString(text3); llBeginDrawString(); // This draws "Hello World!" on the first line. llDrawString(pos1.x - sz1.x * 0.5, pos1.y - sz1.y, text1, color1); // This draws "It worked." on the next line. llDrawString(pos2.x - sz2.x * 0.5, pos2.y - sz2.y, text2, color2); // This draws "This is a" on the third line and "multiline string." on the fourth. llDrawString(pos3.x - sz3.x * 0.5, pos3.y - sz3.y, text3, color3); llEndDrawString(); } default { state_entry() { llInitDrawString(FONT_STYLE_DEFAULT); drawMyStrings(); } } The OpenGL C++ implementation to place in the viewer code to support this functionality is on github. A patch exists for gltext to for baking. In the viewer these can be looked up with FONT_* constants. The init of the ogl context per font for the text should be instanced once per object using llInitDrawString to be used for multiple scripts and prims without reinitialization. This is destroyed when the viewer releases the object. https://github.com/tlorach/OpenGLText There is a bakeFonts.exe for turning ttf fonts into texture atlases to ship with the viewer to bake the fonts and can be produced as .bin and .tga files with offset info. Or, baked into font_xx.h and font_xx_bitmap.h files that can be compiled. This solution does not require the freetype library.

Hello Linden Lab, First of all, thank you for the EEP system. The ability to use custom textures for the Sun and Moon already gives region owners many creative possibilities. However, I have noticed that the night sky itself cannot currently be customized. While the Sun and Moon can be replaced with custom textures, the background night sky always remains the same. I would like to suggest adding an optional Night Sky Texture to EEP. It could work exactly like the existing Sun and Moon texture slots: If no Night Sky Texture is assigned, the default Linden Lab night sky is displayed. If a Night Sky Texture is assigned, it replaces the default night sky. This approach would be fully backward compatible and would not require any changes to existing EEP settings. Such a feature would give region owners many new creative possibilities. For example, custom night skies could include the Milky Way, galaxies, nebulae, alternative constellations, fantasy skies, or science-fiction environments. Since EEP already supports optional textures for the Sun and Moon, adding an optional Night Sky Texture would be a natural extension of the existing system without changing its current behavior. Thank you for taking the time to consider this suggestion.

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.

The freezes are especially annoying with vehicles. Some places can cause rendering to stop for most of a second as you move near them. Specs: CPU: Intel(R) Core(TM) Ultra 9 185H (3072 MHz) Memory: 65015 MB OS Version: Microsoft Windows 11 64-bit Graphics Card: NVIDIA GeForce RTX 4070 Laptop GPU/PCIe/SSE2 Maximum bandwidth setting: 8,000 kbps Test 1: Standing still Draw distance: 512 Position: NE Albion, looking west towards Abbotts Framerate: Stabilizes around 11FPS CPU: ~11% GPU: ~18% Test 2: Flying unassisted: Albion - Yamato Draw distance: 512 Framerate: Varies between 4-8FPS CPU: ~20-30%, occasional spikes to 49%, depending on object density GPU: ~18%

As we hide SL water using the Exclusion layer, it would be a great idea if particles could be hidden too using this layer. Perhaps particles would need a flag to allow them to be hidden or not. This couild be used in boats, where we want to hide water and water spray from entering the hull.

A parcel setting that would derender all objects and avatars outside of the parcel boundary. I believe this setting would be welcomed by many particularly on mainland parcels. It would be entirely optional to use but would make mainland parcels a more viable option for every resident. I also believe a side effect of a setting like this would be to "clean up" mainland in general, reduce the use of ugly privacy screens, inappropriate skyboxes as ground level etc as the need for them would be lessened. This setting would also improve performance within parcel boundaries due to lower render load and not require residents to manually adjust draw distance to improve performance. This setting would be entirely optional and disabled by default.