Add a Text Rendering Method
tracked
Signal Linden
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:
// Signature
llRenderText(integer face, string text, list params);
// Basic example
llRenderText(ALL_FACES, "Lorem ipsum...", [
FONT_ALIGN, "right",
FONT_WEIGHT, "bold",
FONT_FAMILY, "sans serif"
]);
Rationale
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
FONT_WEIGHT
FONT_STYLE
FONT_FAMILY
FONT_VERTICAL_ALIGN
FONT_HORIZONTAL_ALIGN
FONT_TEXT_WRAP
FONT_LINE_HEIGHT
FONT_SIZE
Possible Features
- Markdown / rich text
Log In
Signal Linden
Merged in a post:
Please add "Text On A Prim" to prim face properties
StarWolff2000 Resident
Please add "Text On A Prim" to prim face properties: Basically, displaying a notecard on the face of a prim, like MOAP/Media-On-A-Prim. The notecard would be read-only, uneditable, only displaying the specified notecard's text.
A creator currently can display a color, an alpha, a texture, and a media browser on the face.
There's one similar feature, "data: URI", but that requires media to be enabled, and is very limited on how many characters can be in the string.
A feature like applying a notecard to the face of a prim would be handy for a lot of creators, to easily and reguarly change textual information without the creator needing to create a new texture or for the user to receive a notecard and have to dig in their inventory to read it.
Cain Maven
Yes! This would be a great -- and I think we can all agree, long overdue -- addition.
I like the idea of keeping it relatively simple; even in its most basic version this would be a big step forward.
I'm not convinced that the font color should be controlled by face color. This would mean that the face color changes meaning depending on whether or not text is rendered on the face. I think it's better to leave existing properties alone and handle added capabilities separately, e.g. in the form of parameters such as FONT_COLOR. Transparent background should definitely be a supported feature, but I think that too should be a parameter rather than implicitly tied to the face texture/transparency.
Rich text would of course be nice, but it may be worth considering if that's a candidate for llRenderRichText() to avoid complicating matters too much.
Jenna Felton
I hope the "under review" status allows me to add a suggestion or two :)
I am designing a HUD currently which would allow the user to browse through a list of options. I not wanted to use a XyText-like solution because that are quite many faces for a little text and you only can use a limited number of characters while I'd like to display every character a note card can use.
I also not like to use MoaP because not everyone wants to use media. The only solution remains is using hover text but it has its own limitations.
So, I wanted to write a canny request for writing text over a prim face and was happy to find this one. But I'd like to make a suggestion. I would define the function like this:
llLinkRenderText(integer link, integer face,
integer width, integer height, string text,
list params);
The link number allows to control an other prim in link-set, while using
LINK_THIS
controls the same prim.The function should work so: The viewer creates a buffered transparent texture with the size (width, height) and renders the text into it. Then it applies the texture to the given face of the given prim. This allows to control the size of the text.
The actual text is rendered only within the area on the UV map the given face uses. When, for example the face uses the left upper corner of the UV map, then only in these boundaries the text is rendered. This allows to render different text upon different faces of the same prim.
The text lines are broken regularly but only at the outer right edge of the text area. When the face uses multiple areas in the UV map, the text line continues in the next area but a word is never broken in two except when both areas are connected then a word can be written over the edge connecting both areas.
The function can be called multiple times for every prim, but when two calls set text for the same face, the second call replaces the text set by the previous one.
I would also add one more option:
[TEXT_BACKGROUND, key texture]
When you want the text to be solid you provide a texture to render the text upon it. The texture itself will retain the color and transparency when the face color and transparency changes because these parameters control the rendered text.
Nexii Malthus
Something that may be of interest is this c++ library: https://sluglibrary.com/
This is a modern library specifically designed for drawing text/typography on the GPU and so can be added to 3D environments easily.
This could even be used to replace the current text renderer used in the viewer if it proves to be performant enough which would increase FPS.
animats Resident
I'd suggest going with SVG. Probably the small mobile subset - no animation. That's enough for signs, notice boards, and such. Open source implementations of SVG are available.
It should be possible to change SVG text from scripts, so signs can be changed.
Kristy Aurelia
animats Resident +1 For SVG.
Worth mentioning we don't expect it be rendered as vectors. The viewer should rasterize SVG based on graphic settings and a property on an asset that indicates maximum intended resolution and render it as regular bitmap texture.
With Lua we could potentially have some functions like llTable2SVG and llSVG2Table, so we could edit and create SVGs in scripts, while not having too much script memory overhead from the XML tags and attribute names etc.
SVG also has variety of basic shapes defined too, rectangles, circles in addition to text, which would make it a lot more flexible than just having text.
Kyle Linden
tracked
Fullperm Alpha
This is something i am waiting longer for: thanks for bringing this up StarWolff2000 Resident
StarWolff2000 Resident
I envision llSetTexture/llSetLinkTexture and their llSetPrimitiveParams/llSetLinkPrimitiveParams equivalent could be used. It already accepts a string texture name and texture UUID. The same function could be made to accept a notecard by name or UUID.
Or possibly a separate, dedicated function such as llSetNotecard(string Notecardname, float fontsize, vector fontcolor, integer face)
Ziel Omizu
I and many others would love this for basic information signs, notes, or books!
Woolfyy Resident
To go step by step and have a chance to see things in a near future, having notecard on a prim would already be a great improvement :-)
Load More
→