Text on HUDs

Refer to Marcus's post below --> that defines this proposal
=====================================


We need some text now. Persumably doing text on objects is not a simple job. And text with textures ... seriously ... that is not practical and also expensive on prims.

So how about something much simpler: Text on HUDs and objects linked to HUDs, similar to the functionality of floating text (but not floating) and llDialog combined. A new llText function would simply place text on an object provided it were displayed as a HUD or were part of a HUD. This should allow Linden to simply display the text without any special rendering. Of-course HTML would be better, but I'm not even proposing that so that we can just eke out a basic text function. And there would be a host of applications that could use this. PLEASE, PLEASE, help me get this. I'VE already added a feature request.

I can't imagine how they could implement text on huds without at the same time implementing text on all prims, without doing more work than implementing text on all prims.

Given that they have llDialog, the already have the code to put text on something that is similar to a head up display. Text on HUDs can be radically different, because there will be not need to implement a textured 3D rendering method for text on 3D prims. This text can use the same code as the llDialog text, and not be rendered 3D. Therefore, my guess is that time to development will be much faster for Linden, as they will essentially be extending llDialog code to apply to prims when displayed in HUD mode.

uhh... wait, what about LSL Hover Text?

Not good enough I guess? oy!

A new summary:

1. Text has been implemented for all prims already: floating text. It's floating for two reasons. It does not get rendered 3D as it just always faces flat on the screen. And it is offset off of the object and you have no control over that.

2. floating text on a HUD is also offset so it appears outside of the PRIM. So if you want your prim to be clickable, well the text is not on it, and so it is confusing to figure out just what is to be clicked.

3. My proposal is simple. Just implement a modification of the floating text function so that for HUDs it can be positioned exactly on top of the PRIM. A small step for Linden, but a giant leap for SL'kind.

A HUD *is* 3D prims. You can't put text on a 3d prim on a HUD and not on a 3d prim on not-a-HUD.

Prims in "HUD mode" as you call it are rendered isometrically, but they are still 3d objects. They can be at any angle, either in the plane of the screen or rotated out of it it. They can be any size. I don't see any mechanism that could apply text in a mask over the location of a HUD prim that wouldn't involve making the CPU duplicate the 3d calculations that the GPU is doing already in OpenGL.

Why restrict this to HUD prims? This would equally be useful for prims in-world.

So basically you're asking for a new llSetText as follows:

llSetText(string text, vector color, float alpha, vector pos);

Where "pos" would be an XYZ vector relative to the center point of the prim.

Example:

llSetText("Hello", ve<1,1,1>, 1.0, <0.0, 0.0, 0.0>);

Would put the Text at exactly center (still have to be visible).

An alternative would be:

llSetText(string text, vector color, float alpha, float z-pos);

Where "z-pos" is the distance along the Z-axis relative to the center of the prim. This assumes that X and Y need to be centered at all times for SetText to make sense.

Either of these would work for me and I'd enjoy them thoroughly.

MM

I think the last post from Marcus Mareau summarizes it best. Let us position the floating text at the offset we want. Then on HUDs they would appear right on top of the prim if we wish it. That would solve a lot of problems.

Thx for the help.

I don't want to restrict it to HUDs. I guess I was just new to SL and trying to figure out how we can eke features out of Linden without some poor Linden programmer throwing a fit and saying these guys want blood. I'm trying to figure out the least functionality so a programmer at Linden can say: "Right. That's easy, I'll do it in a heart beat, and I don't have to go to a dozen meetings to hash it out."

But you're all correct, this is just a function of llSetText (I now understand that, duh, sorry for being such a newbie) and if we can change the offset of the text then it will work for all prims, HUD or not.

Wow the things we could do with such an enhancemet.

I deleted the old proposal and created a new one to reflect a new title per Marcus's suggestions. Thanks for all of your input and support.

Last spring I built a HUD using a modified version of TLML that used both floating text & XyText to render text; it was all built dynamically. When i get around to I'll release that version of TLML with the LTWAPI manager (don't have time).

It can be done, and it can look good you just have have to put in the work to make it so.

You can put text on prims, you can do it with Quicktime.

Screw text on a prim, just give me mozilla on a prim.

to the previous post is LOL.

What you have achieved is great. And your skill and knowledge surpasses mine by a league.

But, Mozilla on a prim sounds like a large development project. Something that would require a bunch of meetings (I hate going to meetings) and lots and lots of discussion at Linden. They will do it in good time I'm sure, but when?

My request is for the mere mortals (like me). I just want a little function .. a tiny little itsy function. So I can get them to agree to do it fast. Honestly, I believe a little now is much better than a massive amount god knows when. Plus I think a lot of applications could be unleashed with just a simple text implementation, without bringing in Godzilla (oops, pardon me, Mozilla).

Mozilla on a prim would be nice, but maybe just mozila on a window, no need to make it three dimensional, while waiting for mozilla on a prim.

Heck, give us the ability to use the code that produces panels like the search dialog and the preferences dialog. Editboxes, sliders, folder-item navigators, increment buttons, etc.

New lsl function to supplement existing llDialog: llGoodDialog.

What do you think LL is using currently to render HTML in the client? It's Mozilla, they are just working the bugs out still is all. They have been working on it for *ages*. It's actually looking like it might get added sooner rather then later. They defined the functions in 1.7 llSetPrimURL (look it up on the wiki).

The trouble with just doing "text on a prim" is that what exactly is "text on a prim"? What font? Whats the scaling? Background color? Aspect Ratio?

Floating Text is simple, the text renders at the same size reguardless and the aspect ratio is a given. All those things fall apart when you put it on the face of a prim; where size & orientation changes.


haha

Putting the webpage on the prim isn't the hard part, it's interacting with the webpage. LL has had alot of problems getting interaction to work; mostly with regards to plugins (the mozilla plugin interface is a mess).

I agree with everything said about llGoodDialog -- we need all those functions. Please give us...

But consider the development effort. When I worked at a rather large s/w organization a request like that required a bunch of consultation and meetings and lots of opinions. It took hours as the discussion circled around and around. I felt dizzy. It was unbelievable.

But this proposal is essentialy a minor modification on an existing function that should be doable by one developer in less than a day. It does not require massive design meetings and considerations about ramifications. That lowers the barrier for acceptance at Linden hugely, and has, in my opinion, a much better chance of being accepted.

Heck they could just do something like this...

If we are going to do this, we might as well do things right.

key llCreateWindow(key user, string interface, list defaults)
//"user" is the user key to open the dialog
//"interface" is the inventory interface item (or asset key)
//"defaults" set of attribute pairs used to fill in default data into the interface.
//return is an access key to be used to update the interface.
llUpdateControls(key id, list pairs)
string llGetControlValue(key id, string control)

event:
window_message(key id, integer type, string control)

i'm too tired right now to define a simple window interface... too much work.

Your proposal, as I understand it now (after reading the above posts), wouldn't work well outside of a HUD. A function to offset hovertext would still render the text in 2D. On the HUD, it would look great, on regular 3D objects, it would only look good when viewed from the ideal angle and distance... otherwise, it wouldn't fit and/or would be rotated half-inside a prim.

Besides, off-setting hovertext can already be accomplished both inside or outside the HUD without need for an extra function. Outside the HUD, it requires an extra prim... a downside, but still makes it possible.

Inside a HUD, you can use linked messages between various label/button prims for the desired effect.

For example... a click on the button#1 prim, in a stack of buttons, passes execution to a script within button#2, which then updates button#2's hovertext. The button#2 hovertext appears on button#1's prim, providing the same result as your proposed modification. I've seen this accomplished with very good results, so I know it's possible.

That is assuming similar screen specs. Different screen resolutions result in different spacings. Though it's not hard to let the user adjust that (or your can be brave and build a slider control).

Honestly, I'm not campaigning against HTML on a prim. I'd love that too. Like everyone else. And as for floating text all going wrong on a prim ... well that takes me back to my starting point. I just want this for simple text on a HUD, so that there will be very little rendering issues.

The fact that they have been working on Mozilla for a long time proves my point: it is difficult, full of ramifications, bugs, discussions etc. They have been working on Mono for a long time too and they have been working on ORBs for a long time too. And who knows when these functions will come out.

This function will help us all out, it will not delay Linden, it is not destructive, it does prevent other functions, and it does not impinge on anyone's previous prims. It also is not an example of things badly done. We should be able to control the offset of floating text, don't you think?

As for Mozilla, having it demoed in a lab is very different than having it released. I bet you that the testers are having a field day with it and I bet that as they fix one thing another thing breaks. I hope that I will be proven wrong on this, but in the absence of any guidance from Linden, I bet they will go around circles on Mozilla for a good time to come.

It will work best for HUDs, I agree, and that's how I proposed it in the start. But if you implement it might as well implement it for all floating text, that will be simpler since there will then be no special code to detect whether the prim's on a HUD or not. Looking good is the problem of the scripter.

And having floating text on one prim masquerading as text for another prim, It will work, I admit.

But I have one word for that: SPAGHETTI CODE & KLUDGE.

Okay that's three words.

Just imagine the confusion in your code as one prim has to behave as if it's another, it's text not relevant to itself. The very antithesis of object-oriented progamming and a recipe for buggy code. You move one button and everything is now in disarray. And all because we need to get around a shortcoming in the implementation of floating text, the fact that they do no allow us to control the offset to the floating text.

HTML on a prim that wasn't as restricted as Quicktime on a prim is now would be so high overhead that it would be useless.

Text on a prim (what I've called llRenderText) would be FAR more useful than HTML on a prim and no harder than any kind of HUD-only proposal.

HTML on a prim that wasn't as restricted as Quicktime on a prim is now would be so high overhead that it would be useless.

Text on a prim (what I've called llRenderText) would be FAR more useful than HTML on a prim and no harder than any kind of HUD-only proposal.

llRenderText(string text, integer face, integer font, integer color, vector scale);

The background would be whatever texture is already applied to the face. The text would be composited over the texture on the face, to create a temporary texture that would be rendered on that face. The compositing would take place when the prim was first rendered or the text was changed, and the only cost after that would be one extra texture in GPU memory... just as if it was another bitmap... but one that didn't have to be downloaded.

This would be maybe a million times more efficient than HTML on a prim (maybe as little as a hundred thousand times, but no less than that... they both require a temporary texture, this requires in addition maybe a couple hundred bytes of code that's mostly lookups, instead of megabytes of code with multiple layers of interpreter).

This would actually be *less* resource and bandwidth intensive than bitmapped textures. It would make SL *faster*.

I can see one possible caveat, you'd likely have to restrict the offset to prevent griefing/abuse by floating text over parcel boundaries, or prevent the text from floating across parcel boundaries.

I totally agree. It should probably have some restriction like a couple of meters either way.

I agree with RenderText too.

But consider this point of view:

1. RenderText will be an entirely new function and as such needs
its own in-depth discussion so issues relevant to it can be discussed.

2. Offset for floating text: they already offset the text anyway. So
giving us control is a small modification to an existing function.

3. We should be able to control offset to floating text anyway. This
function is natural ... it should be part of it. Example: what if you
need to have a tree above the object ... then the floating text will be in
the tree and difficult to see.

Summary: I believe that RenderText is a worthy suggestion, but I believe
it needs a new proposition and a separate discussion thread as it is a new
function all-together. It's discussion thread, I guess will be at least as long
as this proposal. Once my votes are freed up from this prop, I'll
be voting for it. For Second Life to integrate with the outside world THERE MUST
MUST BE TEXT.