Text on HUDs

I believe that any proposal for minor changes to floating text that don't actually provide any functionality you can't get using an extra attached prim is just a distraction. There's already HUDs that do what you want, without a new function, and without laggy kludges like XYtext.

I respectfully disagree with Argent.

The functionality of controlling the offset of floating text is not a distraction. Creating HUDs with multiple prims to compensate for shortcoming of floating text control is bad programming practice (especially after all the effort Linden has gone through making objects). And control of the offset of floating text is a natural and necessary extension of its function.

Extra prims in HUD objects are not a significant problem. Since they're only rendered for the wearer they don't cause lag for other residents, and a dozen or so extra prims is a tiny tiny percentage of the total objects in view, so the impact in the wearer is negligable. The scripting impact is non-existent... in almost all cases the same number of scripts are necessary to display text on a button directly or from an extra prim, since the button itself normally doesn't need to be scripted.

Floating text is really a kludge: it's ugly, limited, and should be supplemented by a proper text rendering call as quickly as possible. Minor improvements where there are perfectly acceptable workarounds are simply a waste of time.

You know I basically agree with Argent. It is much better to have real text. We need it and it is essential.

There are only two places I differ:
1. I don't have much faith in the ability of Linden to deliver. They seem to be swamped. And a lot of essential functions are languishing in the doledrums. After all they were demoing mono over a year ago. But I'm new to SL and respect the fact that Argent has been at this longer. But given Linden's track record, I remain unconvinced, that they can deliver. That is why I am pushing for this now, because I believe that it's development is far easier, needs far less hair-splitting at Linden and can be done by essentially a single programmer.

2. Floating text probably will not go away any time soon (unless we expect everyone to rewrite their legacy objects). And the control of the offset is a natural and reasonable extension to the function. It should be part of it regardless of whether a proper text function is implemented.

In summary, yes I would absolutely prefer proper text, and very probably proper HTML text. But I don't believe Linden can deliver any time soon (or even anytime late). So I vote for this.

If I am wrong then I would be more than happy to be proven so.

You can get the float text to display over the prim by rotating it so that Z faces you and then setting Z scale to .1m and then cutting and rotating it so that the prim center is at the bottom.

The text offset starts from the prim center and it uses the prim’s Z scale regardless of it’s rotation.

Hello. I've already used llSetText on a HUD, it's just tricky to implement:

http://img516.imageshack.us/my.php?image=sdialogboxkz7.jpg

The main problem I see is that I cannot control "justification" so the text appears on the left side expanding to the right, like in a normal text box.

It is possible to simulate justification of text that is always centered (as it is now) but it is a SERIOUSLY ANNOYING pain in the ass, and I've not tried doing it yet.


What you do is pad a short string of text with spaces to right of it:



As characters are added, remove spaces from the trailing padding to keep the text in the same spot.




But since the text is proportionally spaced, this padding will not be perfect and the text will jump around a little. The letter i needs one space removed, but the letter m needs 3-4 spaces removed from the padding. And some letters are not a perfect match for the width of n number of spaces.

Neither do I, but I have faith in their ability to push broken workarounds. For example, they might "give" you a vertical offset on text in the HUD, but not give you justification control, and break line wrapping while they're about it.

They broke floating text REALLY badly on Linux for months and didn't do anything to fix it until very recently, and line wrapping has been mildly messed up and not properly fixed in normal floating text even on Windows, so don't expect them to get this right or correct it if they don't.

I don't see a need for HTML text on a prim. The implementation using Gecko would make it unusably laggy unless it was massively restricted. llRenderText could be efficiently implemented by one programmer in a week.

Depends on what way you're proven wrong. (see above)

SVG would be more useful than HTML. Most features of HTML on a prim would be useless.

Also... llSetText(...) as redefined here would break backwords compatibility with scripts that already exist. A new function name would be needed.

I agree with Argent, llRenderText would be the ideal function. Does any of you believe there's a chance they would go for this?

(I wish they would just open up their code so one of us would implement it.)

What exactly is the basis for this assertation? Gecko is a rendering engine for HTML. When used in the context of Ubrowser, all it does is output static texture renderings of an HTML page. I don't see how having textures on an HUD or even in-world prim would cause any more overhead or 'lag' than they currently do on textured prims. Of course, if you had 5 arms/mouses and were actively scrolling all the pages on the browser windows simultaneously, it might cause some slowdown. Other than that, how is displaying a static texture on an object going to make it unusably laggy?

Teleport into a mall where there are 150 HTML-onna-Prims. With 12 other people scrolling on some of them.
You now have to load 150 different web pages complete with pictures. 8 to 12 on a page each with the resolution of a good texture that normally be on a prim (10x10 (nav buttons) up to 512x512 (images of textures to buy)).
That A LOT of data.
Oh yeah, and all the normal prims too.

llRenderText() you think is easy? So, you want it to basically bake a new texture for the side of a prim everytime the text or texture itself changes? You know how well that has worked for avatars.. missing image and all. That'll make the server work harder to render the text, which could give the appearance of more lag.

Sure, it may be easy to implement in one week, but the implementation may not be what you expect in the long run.

If you remove the texture underneath and just have the text on the face... there is no need to bake the texture everytime the text changes. However, the there will be a need to send a completely new image to the client. This still leaves the network bandwidth issue to send these updated images to the client. I'm sure this won't be fast enough to match a normal keyboard speed if you tried to implement a input box this way where it shows changes on a per key level. I'd rather use the chat entry as an input box.

I saw that example of a keyboard HUD. With a level of implementation of SVG, that entire keyboard could be made by SVG on a single prim. If the prim is clicked in a certain area, an SVG event could be raised. SVG is much more efficient on prim allocation and script allocation. Every prim for each key contains a script. Each script allocates 16KB of server memory. There are at least 30 prims with a script for each prim, so that is about half a megabyte of server memory. Doesn't seem like a lot, but compare that to what SVG could do with 1 prim and 1 script that only needs 16KB of server memory - the same thing even with text.

Yes.
It wouldn't effect the server at all. The rendering would only be done client-side, and never uploaded to the server. OpenGL has efficient tools to composite text onto textures, and they're *fast*. The whole Mac OS X user interface is based on OpenGL compositing in realtime.
Absolutely not. The only thing sent to the client would be the text string and attributes.

llRenderLinkText(link,text,...);

Gecko is a heavy duty and inefficient rendering engine for HTML. Every change to a texture would require loading a web page. that includes *every* object wen it comes into view.
If all you want to do is render a static texture, then you don't need HTML.

Even if you add the "link" parameter, that would not be enough. Let's say somebody sits on a car. The avatar becomes a link to that car. The car could then use llRenderLinkText( avatarPrimLink, ...) to change the text on the avatar's chest, and that may be unwanted. To prevent that, the script would have to query the server for permission to put text on a prim's face. Is there another function that does a remote change like this to another prim in a link?

Also, your suggestion allows multiple fonts. There would be a need to make sure each client displays every font the same.

Just as you don't NEED any particular system, but it would be more useful than almost any other typography system I can think of. First of all, HTML is widely known, widely accepted, easy to use (basic features), there are hundreds of visual tools available to create it if you don't enjoy using notepad, and most importantly, the tools are already available to linden labs to integrate support for an HTML browser, which already puts it ahead of any other system, such as LaTeX, as far as development costs/useability. The fact that nearly any page already available on the internet would be available to show in SL is also a plus.

Furthermore, just as the current HTTP scripting functions cache pages on the server rather than the client, I imagine any HTML on a prim implementation would do the same. A single page could be rendered to a large out-of-memory texture and scrolled instead of actually using gecko to render every frame every time it is changed. The textures themselves could even be tiled so that they wouldn't have to be sent to the client all at once, saving load times and helping out the poor gpu memory.

All in all, I don't really see - after all of these 'optimizations' were done - how performance-wise it would be any different than looking at a bunch of different textures, which any 3D engine should be capable of doing.

Only as far as the physics engine is concerned. Not for permission purposes, otherwise the existing llXxxLinkXxxxx() calls would already be abusable that way.

llSetLinkAlpha() and llSetLinkColor() just off the top of my head.

The same is no less true for either SVG or HTML. In fact my proposal has far fewer problems since it's not allowing arbitrary fonts there: note that it's specifying the fonts as an integer. The fonts used would be limited to a set supported by all clients. It could be as small a set as FONT_SERIF, FONT_SAN_SERIF, and FONT_FIXED.

Speaking of which:
HTML is not a "typography system", it's a hypertext markup system. The same HTML page is rendered radically differently on different browsers, even when the different browsers are the *same* program running on different computers of the same make and model with different fonts loaded.
It would still have to be rendered every time it was changed, because the only way to tell what effect an arbitrary change to an HTML page has is to render it.
The textures would absolutely have to be rendered by the client.

Basically, every possible performance-, font-, or permission-related objection to llRenderText() applies in spades to any more complex and powerful rendering technology such as HTML, SVG, NAPLPS, TeX, PDF, Postscript, or RUNOFF from the '60s.
Rendering a texture requires loading the texture to graphic memory - if and only if it's not already loaded. Rendering text onto a texture requires this plus a compositing step, it's negligably more expensive than displaying the texture... the only cost is one extra copy of the texture in GPU memory for each distinct text. Rendering HTML requires creating an HTML rendering engine instance, passing it the HTML, possibly fetching one or more graphics images over the network, possibly executing Javascript code, we're talking noticable fractions of a second of CPU time for each HTML prim face in view... and it's MUCH harder to determine if two instances of HTML will produce the same bitmap (in fact it's equivalent to the halting problem), so this would be required for EACH prim face, not just each distinct one.

All done on the client, because the server does NO rendering.

HTML can also do very bad things. Which is why forums (such as this one) don't use HTML markup to do bold, but instead use BBC.
The other thing about HTML is you can create pages that at the click of a button CHANGE without changing URL. And no, I don't mean frames. Check out the search button at the top of this page.

Sounds reasonable there. However, I wonder why there is no llSetLinkTexture(). I can think of a few reasons security wise.



SVG would use fonts defined by vectors, so it is not arbitrary at all. HTML relies on client side fonts and may be arbitrary. The method you suggest uses rasterization, which at different resolutions would make the font look of arbitrary size. When textures stretch, the reasterized font would look very blocky. Here, SVG would do wonders to because the vectored fonts would easily scale to the dimensions.


HTML is out of the question. XHTML would be easier since HTML features can be turned off to make a more secure layout. However, HTML has many features that still does not work well for a single prim. We could have a web page in SL made up of multiple prims. However, that is really not needed - it's overkill, and you seem to agree.

Most features of HTML work great outside of the 3D environment already, so that the immediate need of HTML is solved with references to a browser that already exists on the client-side. We have that ability to refer to web pages from within SL.

We could use an SVG image in place of a rasterized image. The SVG image has the ability to refer to other textures. You would be able to use a SVG image the same way you select a texture. No extra functions, like llSetLinkSVG(), are needed. The system would look at the image and know if it is a rasterized image or made by SVG. With SVG enabled, you would not even need a script to set text on a prim.

This would be nice. I would like to put the price of an item on my vendor, but I neither want to display hover text nor want to upload a different image for each change in price.

I'm sure some would want to display a standard logo next to their text that looks really nice at any distance, and SVG would enable that also.

Any prim you could modify with llSetLinkTexture you can modify without llSetLinkTexture, and the same for any other llSetLinkAnything. The reason is the same as the reason for all the other missing features in LSL. They just can't be arsed doing a complete and consistent API.

Any optimization possible for SVG is possible for llRenderText. If lazy rasterization is more efficient, then llRenderText could do lazy rasterization. If not, then you would do greedy rasterization in your SVG implementation as well. I shouldn't need to point out that you could trivially implement llRenderText using SVG... therefore it automatically has every performance and appearance advantage of that you can attribute to SVG.

And I don't think you can avoid a rasterization step in OpenGL, in any case.

This kind of works. But (you knew that was coming) it does not give you good control of what you need. let's say you want to create your own dialog with programmable text, you have to twist and turn to kind of get it to work awkwardly. In summary i believe that this method has some limited use, but it falls way short of what is needed with text.

The title says it all: "outside the environment."

The goal is to integrate the outside environment with the 3D world. This way SL becomes a tool where information and connection with people is integrated. Refering to web pages outside of the environment results in you leaving he enviroment.

E.G. the Reuters HUD. This tool brings the news to SL. Imagine if everytime you saw these it said: "click on me to get the news from a reuters website." That would defeat the whole purpose of the HUD because you will be breaking the link between the information and your in-world experience that you SHARE with other agents.

llRenderText then is essential to achieve the necessary integration between the outside world and in-world experience.

How about being able to use the existing quicktime viewer on HUD objects, with the user setting the media url independent of parcel media urls?

not to go off course of the thread... but independent media on a hub would be a great improvement, maby open some doors for reasonable shockwave, or later on, java intergration

but there has to be a way to force control it, as of now theres not hud identifier, nor forced attachment / video thing, thats why we do not have it now