✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
SVG Canvas: A way to generate dynamics graphics on prim faces (without MoaP)
Motivation: Second life is full of information and very often you have to display some information dynamically: Radars, navigation signs, fancy menus, information boards, HUD applications. And that is a rough listing. For doing this we have prepared textures, MoaP, hover text. Textures can use a wast number of faces if you want to display an arbitrary text. MoaP is doable but has problems with transparency. And security concerns. Hover text works well but it can not be limited to a certain area. Like not at all. SVG Canvas tries to counter these issues and to give a way to create simple graphical information dynamically (but it will be much richer then a simple hover text). Basic idea A SVG canvas is a container for a SVG image and provider of its content: The container is created by a script, it has an own UUID which can be applied to any prim face like a regular texture. To display this image the viewer receives the SVG content from this container. The SVG canvas is stored within the heap memory of the script created it (parent script). As long the script is available, the region can provide the SVG content to the interested viewer. Thus, the SVG canvas is best used on HUDs and in-world objects also running the parent script. The canvas is created via the call key llSVGCanvas(list options); The options list defines the <?xml> header (the only way to set the <?xml> attributes). The result key is used in the following commands and is also applied to prim faces. To check the current status of the canvas we use the function integer llSVGStatus(key canvas); The function checks if the key is a SVG canvas, if it was created by the same script, if it is stil valid etc. Result is 0 or error code. Since SVG is a XML dialect, to build/draw the SVG image we use DOM commands, but a non-OOP way. The commands can only be called within the parent script (for now). integer llSVGGetElementByID(key canvas, string id); This command finds the element having the given "id" attribute and returns its number. Each SVG element is addressed by a distinct number maintained internally, which can but must not be saved in the "id" attribute explicitly. For example we can use the order in which the elements were added while the top-level <svg> node has the element number 0. integer llSVGSetAttributes(key canvas, integer element, list attribs); integer llSVGUpdateAttributes(key canvas, integer element, list attribs); list llSVGGetAttributes(key canvas, integer element); The commands set or read attributes of the SVG element given by the number. The attributes are given by name and value (alternating). The .Set. command replaces the element attributes, the .Update. command only changes values of named attributes. Both return a negative value on error and the (same) element number on success. integer llSVGSetXML(key canvas, integer element, string xml); string llSVGGetXML(key canvas, integer element); This command sets and retrieves the XML content of the given element. This is used to change the text of the <text> element but also allows to draw the <svg> image at once when desired this way. integer llSVGAddElement(key canvas, integer parent, integer sibling, string tag, list attribs, string XML); This call creates a new SVG element with given tag, attributes, and content and places it is as child element of the given parent element after the element given by sibling when it is an element of the parent element. Otherwise the new element is placed after all child elements of the parent. The result is the number of the new element or negative on error. This operation may change numbers of some elements. The top-level <svg> node exists by default and must not be created. integer llSVGRemoveElment(key canvas, integer element); This operation removes the SVG element having the given number. The top-level <svg> node can not be removed. Extensions Besides the simple elements (path, text etc.) we can also have commands for drawing of UI elements. The commands will provide only logical definition while the viewer will render the elements with respect of the current skin. This will allow to create apps with a look and feel of viewer floaters while they will operate on scripts running on the region. Since some of these elements must be clickable, the elements can be added proprietary attributes working like interaction listens and eg. on touch triggering the event on_svg_event(key object, key canvas, integer element, integer action) Within this event one could call then llDetected... functions for further information. Instead of creating the feature for SVG only we can first create the framework for building and updating a XML documents and use this to define SVG images among other uses. Example follows in a comment.
5
·

under review

Ability to bundle Blinn-Phong textures as materials the same way PBR is
Since PBR came out, I've essentially been almost PBR-exclusive with my store creations, mainly because PBR is just so much easier to work with for texture HUDs than Blinn-Phong (aka non-PBR textures, classic textures, legacy textures, traditional textures, etc). Part of this is because all of the textures involved are bundled into materials that are a single object with all of the settings saved rather than having to put everything in manually like non-PBR. It would really help creators offer both options and cut down workload by a TON if we could also bundle blinn-phong textures as materials. I don't know about other stores but I like to really tweak the specular settings and often the specular colors as well for metallic and generally more realistic effects rather than leaving everything white for all colors, and coding that into the HUD is fankly, a gigantic pain in the ass. Even if they were called something different like texture bundle or something to avoid confusion for people who sell them and to differentiate in our inventories that would be fine. I know we would not be able to upload them together the same way as PBR because it involves separate files, but there's no reason we shouldn't be able to create the material in-world manually on a cube or something and save it the same way. Bonus if double-sided can be an option for blinn-phong too! It would cut down on geometry needed on a mesh if we don't want it to be one-sided since we could simply check that on like on PBR materials, rather than needing to solidify a mesh (and essentially double its geometry) in order to get the same look. PLEASE let us manually create blinn-phong material bundles that include diffuse, normal, specular, alpha, glow, shininess, environment, shine color, full bright, and blending mode settings. It would make the jobs of creators working with blinn-phong in any capacity much easier, coding HUDs would be easier, and if double-sided can be an option it would also cut down on mesh complexity since people wouldn't need to solidify or fake edges on their meshes to hide that it's just a plane.
6
Load More