sl-service-account
commented
11 months ago JIRAUSER341305 commented at 2023-09-26T07:03:09Z, updated at 2023-09-27T05:00:46Z
I presume there'll be an associated magic texture UUID, and the viewer will respond to that UUID by rendering the prims face text property, allowing the usual texture manipulations to affect it. (Would be nice if it generated a temporary texture, even if it only lasted to the next sim restart — but there be dragons there.)
Were you planning on allowing different text on each prim face? How long can this text be? Please give us more than 256 characters or something similarly woeful — though decent text length, by 8 faces of a prim, are probably contradictory goals (which would be removed by the temporary texture suggestion above).
Can we call them TEXT rather than FONT? There'll likely be terms that don't refer directly to the font (and the command is llRenderText, not llRenderFont). I'm assuming TEXT_WRAP is specifying the column to wrap at? Or is it the method of wrapping (none, clip, word, or hyphenate). We obviously need both. Also, specifying sizes in pixels is useful, since fonts can vary from system to system, or at least some way to get font metrics and measure the text we're trying to render (would also be useful for float text, etc.).
We absolutely need the ability to mark up the text in some way! (But we also still need to be able to render raw text with nothing more than line feeds) This is something we've been desperately wanting in float text, and even the more prim heavy methods struggle with it (especially when you're trying to save prims by squeezing in more than one character per cell).
For non-plain text rendering, Markdown would be a good baseline option giving us headings, italics, bold, etc. (Images? Tables? Clickable links?) But people have been desperately wanting to use colours in their text, and more esoteric formatting like drop shadows, super/sub-script, etc. (Have seen bots generate and upload rendered textures to achieve these text effects.) Not sure what rich text specification you're thinking of, something with at least basic style sheet capability hopefully. (This might also be a good time to revisit BUG-233599 — SVG allows fun things like rotating the text as well, with complete freedom to mix and match fonts, colours, styles, and more.)
I personally think MoaP could be very successfully hijacked for this; using an internal URL (internal://renderer?options), that essentially pulls the content from a prim property (presumably the same one you're planning to use with llRenderText — with more space than the MoaP URL field), and then attaches a custom internal content type constructed from the renderer part (eg. "secondlife-internal/"+renderer). This internal content type would then bypass the rest of the MoaP machinery (or kick it back out if it's already running, like from a link on a HTML page) using the specified internal renderer (plain-text, Markdown, rich-text, SVG, etc.) instead of the built in browser. If the initial URL fetch can be done before starting the MoaP machinery, it needn't ever even invoke the built in browser at all (and all the settings and tribulations associated with it) while still allowing the HTTP song and dance to be used for safer rendering of text content that's larger than the prim property will allow. A built in command like llRenderText could then simply load up the prim property, and apply MoaP (bypassed) with the appropriate internal renderer URL. These internal renderers would of course ignore most of the MoaP settings, just getting their job done quickly and safely.
As a way left-field alternative, going back to the temporary texture idea, just allow a script to have one temporary texture that it can render to (or one per prim, or 4 per object), which can be applied to any prim face in the region, and some text/graphics primitives (would be best to render to a frame buffer and then push that to the texture, since scripts can get suspended during the render). Would be an LSL alternative to SVG — the render commands could even essentially build an internal SVG-equivelant, rather than a straight up texture… (sorry, bad bit of humour there… but yet, not sorry…)
How would you like the feature to work?
Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing.
Concept...
Why is this feature important to you? How would it benefit the community?
Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText, or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc.
A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck:
Limited in scope (easier to implement than grand UI-creation ideas)
Easy to kitbash into existing and new creations
For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful.
Other details
Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red)
Questions
Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params.
Possible Parameters
Possible Features
Markdown / rich text
Links
Related
Duplicates
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-234464 | | Summary | llRenderText Dynamic Text | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Signal Linden (signal.linden) | | Created at | 2023-09-25T22:23:23Z | | Updated at | 2024-01-17T16:38:36Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-09-26T02:03:09.285-0500', 'How would you like the feature to work?': 'Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing.\r\n\r\nConcept...\r\n{code}\r\n// Signature\r\nllRenderText(integer face, string text, list params);\r\n\r\n// Basic example\r\nllRenderText(ALL_FACES, "Lorem ipsum...", [\r\n FONT_ALIGN_RIGHT,\r\n FONT_WEIGHT_BOLD,\r\n FONT_FAMILY_SANS_SERIF\r\n]);\r\n{code}', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText, or using a complex and resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc.\r\n\r\nA scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck:\r\n\r\n- Limited in scope (easier to implement than grand UI-creation ideas)\r\n- Easy to kitbash into existing and new creations\r\n\r\nFor inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful.\r\n\r\nOther details\r\n\r\n- Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red)\r\n\r\nQuestions:\r\n- Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params.', } ```