✨ Feature Requests

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.

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.

It would be very beneficial to have a toggle to change the texture filtering on a material face to "nearest neighbour" instead of linear. (Especially for pixel art) This would allow for much better looking and efficient pixel art and is already a thing under the hood in opengl. This has been requested before but couldn't be done at the time because of database constraints for each object. But that would have already been changed with the support for PBR materials I believe.

Hello programmers, In the Firestorm viewer there is a feature named Blacklist. This allows users to blacklist certain objects and even avatars so they are no longer visible to them. This feature is used on a regular basis by many Residents in world for many years now. It often solves frustration when users can derender eyesores from neighboring objects next to their land. However this feature is not perfect, while it solves issues for a single person, Residents are not satisfied as their guests are still confronted with the Objects that form an eyesore to them. In order to solve this, instead of a single avatar a parcel should have the power to enforce derendering of particular objects on neighboring parcels. This would then actually solve the issue for both the parcel owner but also for their visitors. Parcels can have this power on avatars so you can program it so parcels also have the power to views on certain objects surrounding them. I think this is a feature that should have been coded a long time ago. I think this will benefit many Residents in world and fix a lot of frustration people still experience today.

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.

Screen space reflections have been broken since a past update that is causing several visual issues: -Alpha masked textures are not properly rendered by screen space reflections. As I understand it it is not possible to accurately display alpha blending in these reflections, but it is possible with alpha masking (Visible in attached image, the trees are alpha masked, and the smoke particles from the fire are alpha blend) -Visual bug following the cameras POV on reflective surfaces (Check attached image) -Incorrect blurring on linden water, and banding when moving camera (Check attached image) I would like to see an optional planar reflection method for flat surfaces such as water, mirrors, glass, etc. that can be optionally enabled when editing object faces, and possibly the default or optional for linden water in the windlight settings.

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

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! =)

As it stands, Second Life (secretly) supports global illumination via reflection probes. This is confusing to users - as we only really specify it as part of the reflection probe. In reality, there's often a need to have more light probes for GI than there is for reflection probes. This change means that: Probes can have three modes. Reflection, light, or both Existing probes would be both for reasons of content compatibility Potentially, changing how we store light probe data (using spherical gaussians or spherical harmonics or some such)

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.