✨ Feature Requests

Currently, the Bakes on Mesh (BOM) baking stack places the Universal Layer above standard Tattoo Layers. Because the Universal layer covers all texture channels simultaneously, using it to distribute a full skin (Head, Torso, Legs, and auxiliary parts) completely cakes over and hides a resident’s existing inventory of standard Tattoo layers—including makeups, hairbases, and body art. As a result, creators are heavily discouraged from utilizing the Universal layer for complete avatars, forcing its use to be almost entirely restricted to isolated attachments like mesh ears. Moving the Universal layer's position in the baking hierarchy to sit directly under Tattoo layers and directly above the System Skin layer would fully unlock its original design potential. Use Cases & Community Benefits • Complete-in-One Asset Creation: Skin creators could leverage a single Universal layer file to package an entire avatar skin. This includes simultaneous coverage of the head, body, left/right ears, custom eye textures, fingernails, and auxiliary channels without forcing residents to give up their cosmetics. • Massive Inventory De-cluttering: Instead of a customer having to locate and wear separate system skins, auxiliary body appliers, and independent tattoo layer extensions for specialized mesh parts, everything fits perfectly into one clean wearable asset. • Seamless Customization Workflow: Residents could wear a complete full-body baseline asset via the Universal layer while safely overlaying their existing library of traditional standalone tattoos, hairbases, and cosmetic makeups right on top of it. • No Structural Disadvantages: Because the Universal layer natively supports alpha masking and transparency channels across its target outputs, positioning it underneath specialized tattoo cosmetics introduces no regressions to traditional layout styling or transparency blending. Proposed Technical Change Modify the server-side and viewer-side texture composition pipeline so that the texture baking order stacks as follows (from top/visible to bottom): [Upper Layers: Jackets, Shirts, Underwear, etc.] Tattoo Layers (User-reorderable cosmetics, makeups, hairbases) Universal Wearable Layers (Unlocks baseline full-body/asymmetric texture baking) System Skin Layer (The absolute baseline texture)

It would be really nice to be able to scale the our whole avatar with a global scale slider so we can be really big or really small without changing our shape valaues, Idealy this would act much the same as the hover height slider. This would also increase or decrease this scale of hitbox to match the new scale. Additinally it would be great to have a LSL function to control it like llSetAgentScale(float scale_value); or something to that effect that sets the scale of the owner of the object. If a permissions request is required I would be fine with that as well.

I suggest an enhancement to the Bakes on Mesh (BOM) system by introducing an opacity option for BOM layers. As a designer, the current limitations of BOM force us to add additional mesh layers, particularly for makeup applications. This increases mesh complexity and necessitates the use of complex HUDs. Enabling opacity control on BOM layers could eliminate the need for extra mesh layers, thus optimizing mesh complexity and enhancing overall performance. Additionally, this would allow for greater flexibility and creativity, as BOM makeup layers wouldn’t be limited to one or two mesh layers (depending on the number of mesh layers created by a designer). With the recent introduction of 2k BOM textures, the capability to adjust blend modes directly on BOM layers would be highly beneficial for both designers and users. It would offer more customization options and improve the user experience. It would positively impact the creative community and contribute to a more streamlined and efficient design process.

Change or create a new file type for the application of Alphas to avatars. THE PROBLEM. Classic and Mesh avatars need Alpha clothing to be worn to hide avatar bodies from poking through Clothing attachments. Currently you can do this efficiently with a simple Alpha clothing file thanks to the introduction of BoM. But many mesh avatars still use a very render heavy system of multiple face layers of mesh and use HUDS to 'apply' masking, becasue it's easier and quicker for the user than having to browse through folders full of many Alpha Clothing files. ANSWER Would it be possible instead allow avatar creators the ability apply alphas clothing files efficiently via LSL script instead of creating these HUD systems, reducing the amount of mesh and render costs needed for these quicker easier Masking options? If we can Set a material change, can't we set an Alpha change either by using a UUID of existing alpha file or a new file type? llSetRenderAlpha(AlphaUUID);

There would be a huge benefit to creating two separate wearable objects one with the shape settings for heads and another with the settings for bodies. If dividing the base shape is not feasible then having a built in official way to manage the settings for each and upload/download them as needed would be a good alternative. Actual shapes though make it very easy when swapping a head to simply wear the appropriate shape. Another alternative would be to allow shape settings to be adjusted via LSL.

Make it possible to click an avatar/animesh, select "Sit on ..." and get a list of skeleton targets that the avatar/animesh has enabled to be sat on. This would make the sitting avatar follow the skeleton as if they were an attachment. Needs permissions handling for avatars. The avatar/animesh can define a (limited?) number of skeleton targets like "Head", "Spine", etc. by script with an offset and rotation for each.

Sometimes I click "wear" instead of "add". Then, I lose half of the objects on that particular bone attachment. I want to be able to lock an object to my avatar so I don't accidentally remove my Reborn body.

BOM layers that can glow. Would be quite nice and remove onion layering for mesh models and help save on resources. I know PBR is a thing but it does not allow the flexibility of BOMs. I have species that have different glowing markings and bioluminescence on their bodies that I'd love to be able to do in SL. My team and I heavily utilize BOMs so our customers can make rather unique pattern and color combinations. Shiny BOM layers would also be really nice.

Problem Currently, when users need to reset their avatar's skeleton, the changes only apply locally to their own viewer. For other users to see the reset skeleton, the avatar owner must use a workaround that involves resetting their skeleton locally, teleporting elsewhere, and then teleporting back. This process is cumbersome and interrupts the user experience. Solution Implement a system where when an avatar owner resets their skeleton, it automatically sends a packet to all viewers that can see that avatar, instructing their clients to also reset the skeleton display on their end. The same functionality could be extended to animations, allowing users to clear all animations across all viewers simultaneously. Links BUG-225527 Github: Make it so that reset skeleton is a networked ViewerEffect