Text on HUDs

Outside of the 3D environment... not outside of the client environment.

To integrate the functionality with the client indeed is being done by the SL team and further will be done by others. That does not mean the 3D environment itself needs to support such funtionality. Have you seen Xgl/Compiz?

http://www.youtube.com/watch?v=Cz_2vKq5cZk

Anotherword, instead of trying to integrate the desktop into the 3D environment, do the reverse and integrate the 3D environment into the desktop. That way you could HTML, browsers, movie players, sound recorders, photoshop, 3D modelers, etc etc all you want in a 3D viewer.

I wouldn't doubt that LL will remove some menus from the client and make them accessible by web instead.

What you'll need then is a parent window that sits transparent over the 3D viewer (note I typed viewer here and not environment) that take place as the HUD. That's the future. Right now we have a client that gives you a cross platform "desktop" (or window system) on top of the 3D viewer.

I don't want to go too much off topic on this...

Exactly! One step at a time... =)

And llRenderText is the logical first step, because it can be easily and verifiably implemented in a small amount of code.

You propose to make it work without SVG and later make it work with SVG? That means backward compatibility issues. People might just make tons of objects with llRenderText() applied, and they spent lots of time to get the text to look just right. However, you already plan to change the text in support of SVG. Anotherwords, that sounds like going from a rasterized font found somehwere on the client side to a uniform vector font found on the server. That could have a major difference in appearance and cause many to redo what they already created. It would break content, and that is not good.

Argent, I believe if it was that easy that it would have been already done. With my ultra nerdy experience at project management, it takes awhile to design a decent computer program. Sure, it can be easily and quickly thrown together, but then you work harder to fix it or even improve it. Most game makers take 2-5 years to make a best seller. However, those games are not even openly programmable as Second Life.

dunno, my 10 year old copy of pain er i mean paint shop pro can take raster fonts and deal with them as vectors with little issue, in realtime

and as far as ez = done ... maby you havent spent much time with LL running the show

oh and those games that take 2-5 years have a hollywood budget, if you look at most long waited killer games you will find that most of their budget goes to writers, animators, producers ect ... little goes to the advancement of engines and code

(cept for Id,epic, and maby valve, altho they produce "games" 99% of their biz is selling their technology to the hollywood "top 10" every month publishers like EA)

What I do is analyze and plan. I have a good perception to be particular with details in design. Sometimes, I want it to be perfect with every "t" crossed and "i" dotted, but I also realize that isn't always possible within a given amount of time.

For example, I realize the llRenderText() could be thrown into the system; however, it provides no easy way for future expansion. What if you wanted to render Japanese, Chinese, or Hebrew. We know that Unicoded fonts only go so far.

If we wanted to do it the easy way, I guess we can make functions of llRenderTextUnicode(), llRenderTextCyrllic(), llRenderTextChinese(), etc. Pretty soon we have a bunch of functions thrown in because they were justified by being "easily made."

If LSL was more of an object oriented language, it would make sense to have all those functions. However, it isn't.

I propose to make it work. If SVG is added later on, AND it's more efficient to use SVG instead of native OpenGL operations, then it can be updated to do so.

Both llRenderText and SVG would absolutely have to use vector fonts on the client to get anything like decent performance and save network bandwidth. If SVG requires downloading vector fonts from the server with the content, rather than keeping them (cached, or built in) on the client then that's a good reason NOT to implement it at all.

Ask any Linden, they'll all tell you they've got a meter high stack of things that are easy to do that haven't been done simply because of all the other things that are "easy to do" they're already doing. And llRenderText is one of them.

You are describing SL to a tee. Seriously.

I propose that you study whatever documents you can get about SL and develop the code for it to work and then LL can *easily* slap your code into SL. Yes, that would make it easy.



And, who voted for these things to do?



SL uses OpenGL. That is an open standard that started early 1990.

Back in 1990, it took specialized console computers to run graphics like SL does today. Some highlights early in 1990:

1. "Hypertext" was proposed
   
2. "Windows 3.0" was released
   
3. "XGA" hits the market
   
4. "id Software" (makers of DOOM, the first - first person, fast paced, 3D shooter on the PC) is founded
   
5. OMG!!! "QEMM386 v5.1" was released (yes, the 80286 didn't have memory management and any program in the computer had access to everything in the computer - even another program with your personal data.) (oh, and Windows didn't originally protect memory with memory management.. OMG!)
   

That last highlight is pretty scary. I mean, consider of all the people who complain about CopyBot... OMG... we might as well blame the 80286 as an attempt to steal data. How did the world even let that one go and even forgive that era? =p

That was only 15 years ago. It has taken LL over 5 years to develop SL?

Let's go back further... Ever heard of MOO... LambdaMOO? It was based on a MUD Object Oriented language called MOO. MUD is short for Multi-User Dungeon. People used to log into MUDs, and they were only text based. MOO still is a much more advanced language than LSL. Being only text, you had to visualize what you read. That actually all started before 1990, but officially founded in 1990. Wikipedia states that it had 10,000 users and about 300 active at any time back then.

Before MOO, there was MUD... MUDs go way back before the Internet even began, which was late 1960s. MUDs were born from the BBSs, another text based system. Before the Internet, people used modems to call other computers individually. Between 1960s and 1990 we find text based games like Adventure, Colossus, the famous Zork series, and more. There was even ADL, the Adventure Definition Language -- text based.

If the question is to implement text is easy... your right, the answer is yes. It's been done all along - with the easy way.

Instead of the easy way and with 45 years of pragmatically proven problems with "the easy way" - there are those that want to do it "the right way" or at least "a better way." It may take a little more time to do it right.

SL is pratically unusable for anybody that does not speak/write a language that works with SL fonts, which appears to be unicoded based. That'll work for many languages, but it isn't easy for everybody.

As for vector fonts versus rasterization -- rasterization only occurs because of the default display limitation of pixels. Some older game consoles (like Vortexx and Star Wars) used vector CRTs, and no rasterization was done. That was the past. Today, vector fonts use much smaller bandwidth than rasterized fonts. Why? Rasterized fonts need several copies of the same character at different resolutions. If you look at the rasterized font on your system, you'll see the size of the file -- anywhere from a couple kilobytes to several megabytes. Vector fonts only need one version of the font made, and it works for all resolutions.

How does that relate to SL? Take a cube prim and look at one of the faces directly on. Now rotate it around. You'll notice that some corners appear closer to you. If you write text along one of the faces while rotated, you get large letter close to you and smaller ones further away. With a rasterized fonts, it'll have to use several versions of the same character to make the render look decent -- one version for the large, another version for smaller one, and it'll have to compensate for everything in between. With vector fonts, it just passes the font model onto OpenGL to render it.

There already exists SVG to OpenGL translators. I'll have to mess with that. It's on my stack of things to do under those things that make more immediate money.

I hope you have time to code llRenderText() and also the commitment to support it when users come and complain about it because they want more features that are easy to do.

Damn long post... hope I got my point across.

Technically if you're doing a raster font applied to the prim face, you only need 1 size as well. It distorts as a texture does when rendered.

Either way, I'm pro-vector.

Haven't read all of this. But I would love to see an llSetTextHeight(float height) function everywhere in SL to change the position of the text. Then additionally it would be nice to have llSetText support longer strings when used by HUDs, though the issue of detecting this and ensuring you can't use this as a hack to get longer string on in-world objects is avoided.

However, a dedicated function just for HUDs (information which simply isn't sent for in-world objects) would be neat too, I like the idea of special dialogue function.
The ability to have left/centre/right justified text would be neat too along with a large string size. Allowing for things like interactive stories/articles on a HUD to be handled more effectively.

...

I'm at a loss to make out what you're getting at here.

I know what computing was like in 1990. I was there. I was writing video games.

I know what MUDS and MOOs are like. I used one of their ancestors in 1979 and wrote my own version of it in 1980. Oh, and in 1980 I was quite excited about the possibilities of hypertext as described by people like Nelson. That's 1980, not 1990.

I wrote my first progam in 1972, my first game in 1976, my first graphical game in 1977, my first font editor in 1983.

And you've completely lost me here. I write a message where I point out that I'm assuming that vector fonts would be used, and you come back and argue that raster fonts shouldn't be used because vector fonts are better. Are you actually reading what I wrote?

The question isn't "do they exist", the question is "how computationally intensive is it".

Every platform SL is running on already has calls to render outline fonts in OpenGL both as 3d objects and composited on a texture. This code is well optimised, and rewriting it myself would produce a lower quality result I doubt you or I could do as well.

Integrating it to SL would require access to their source tree. I'd love that, though I'd fix the parsing and code generation problems in LSL first.

Honestly, I don't think you did.

Timeframes were mentioned, and I noticed the concern about time it takes to develop SL. I put up a comparison.


I didn't question that.



Kind-of like the web wasn't official until 1995 even though we know it started much earlier, gopher kind-of made hypertext official in 1990 when it was released and used widely.

http://en.wikipedia.org/wiki/Hypertext




*sigh* yes...

I read a message that shows your concern of timeframe, and you noted that it would be easy within the timeframe. I put the comparison up to show you how the overall timeframe of computer evolution has develop pretty darn rapidly, and that there are many perspectives put into thought over the years. One being the text. It's actually a pretty major piece. It is the main device for communication. You stated you just wanted it to work. Yes, you're right, to get text done, by how it has always been done, is easy, but you get the same problem that we have had with those text systems.

The real question is why easily throw something into the system that you know by 45 years of pragmatic experience is going to be a headache to support and improve?

Once that feature is in scripts, it'll be hard to take it out or change it to improve it. We don't want to break content. If in the future there is the case to improve text, you can't just simply upgrade the function or remove it to replace it with a better function. Scripts will break.

We got a simple idea to implement. The hard part is to design it so that it'll be extensible or flexible to the needs of the future. That takes time. Look how long we have debated over this already.



You're not the only one. Unless you work at LL, libsl is an option.

Um, you're a LOT less likely to get locked into a bad implementation with a simple API than with a complex one. The structured vector graphics of yesteryear -- NAPLPS, NeWS, DPS -- are all dead. Plain text still works, and a program that called printf("Hello World\n"; in 1979 can have that modified to printf("Halló Veröld!\n"; today... but 0 0 moveto 15 setlinewidth(qlllll-??LHHL??llH?hH7t,7olCAHH@)1 setlinejoin{dup 10 mul rotate 80 lt{50 0 rlineto}{50 0 rmoveto}ifelse}forall stroke showpage would require a lot of work before yu could see the bear on the face of a prim in LSL.

Even if you created a family like llRenderSVGfromText(face,"uncompiled SVG" llRenderSVGbyURI(face,URI,...) if you left out llRenderSVGSimpleText() you'd just get people using copy-and-past development methodology to get a routine to take a text string and attributes, convert it to SVG, and render it on a prim... in 69 different variants all of which would have to be maintained forever.

I'm not the one who's pushing for an interface that will be a headache to maintain.

Indeed. I've got decades of experience designing APIs that are extensible and flexible. One of the most important tools for this is called "abstraction". Abstraction involves creating a subset of the possible alternatives that doesn't restrict the implementation. Abstraction is often confused with adding a layer of indirection, because it looks like adding a layer of indirection that exposes all the underlying capabilities gives you the most flexibility. But that flexibility locks you in to maintaining all the implementation details of that flexibility forever.

Exposing SVG in LSL is "indirection". If it turns out that next year Apple and Microsoft get together and create DirectCorePostscript, llRenderText can be implemented in a handful of lines of Postscript because it's a high level abstraction. llRenderSVGbyURI() will require replacing the OpenGL implementation of SVG with a DirectCorePostscript one.

I'll skip some of this so it isn't to far off topic... I'll glady chat with you about implementation details elsewhere.



I read your text and it doesn't even related to the ideas expressed earlier in this thread. I basically suggested no new interface. An SVG image could be dropped into the same texture selection dialogs. The interface already exists.



Yes. I understand dynamic compilers with a very low level object-oriented style interface. There is no limit to the abstraction that can be applied with the VM that executes this kind of compilation (except physical properties).



My suggestion was to neither expose SVG nor llRenderText().

However if Mono is available, I feel that code libraries could be made as the best implementation for advanced interfaces to do what else is being suggested here.

ahh mono, the year old joke

im finding myself less and less interested in SL as times passes, simple things like a native way of rendering text on a prim has been and still is left to the users to sqabble over, while no progress on anything truly usefull takes place

this argument has been going on since before i joined and we are not anywhere closer to basic computer functionality for this amazing and exciting "next gen platform of the internet" that started in 1999

personally i would drop the whole thing,... but again personally i would burn the current client, and focus on basic functions and a graphics engine that runs abit faster than quake 1 did on my 66mhz 486

This discussion is moot anyways.

http://ubrowser.com/index.php

Judging from some of Callum's recent posts on the Ogre3D forums, the library is pretty much prime time anyways.

http://www.ogre3d.org/phpBB2/viewtopic.php?t=25936

Incidentally, the system works nearly identically to how I described it would work. I really like how he even mentions "I just released a new version that now supports multiple browser windows and has a much improved update scheme - pages are now only updated when they change."

I've read that a subset of ubrowser is in the SL client right now, and I wondered if that meant just NGLayout or the entire Gecko engine. LLmozlib seems to embed the entire thing. This means SVG is that close. =)

Woot! Vote Prop: 2085 - SVG Textures!!!

But that doesn't solve the problem that rendering text from a script onto a prim is unacceptably limited or expensive. Your SVG proposal has nothing to do with text on prims (HUDs or otherwise) at all, it's just a way of getting smaller textures, and partitioning a prim face up in an implementation-dependant manner. Even after you implement it, you will still need llRenderText or an equivalent call in LSL to solve the problem.
Errr... Whether the implementation involves HTML, Postscript, NAPLPS, SVG, Mono, Polo, Java, Javascript, Flash, Zip, Zoom, Pow, Crash, Batman, or the man from A.C.R.O.N.Y.M. doesn't change the fact that you have to have an abstraction visible from LSL to actually make use of it.

That abstraction should hide all those implementation details, just as llSetText hides whether that text is rendered using 2d or 3d OpenGL calls, whether it's part of a scaled or unscaled user interface, and so on.

The problem is that if you have a prim and you want to display information on it, your options are:

1. Load a texture (whether it's SVG, 24-bit, or 32-bit, the script shouldn't care) containing the entire message.
2. Shift a texture containing multiple messages around.
3. Shift textures on multiple faces, each containing part of the texture.
4. Display floating text at a (hopefully) predictable offset from a secondary prim.

The option that you almost always want is:

5. Render a text string onto the surface of a prim.

It turns out that option 5 is actually easy to implement efficiently, with only the string and a couple of dozen bits of additional information being transmitted to the client. And it turns out that the abstraction exposed to the programmer would allow it to be implemented in the client in any of the first three of the above ways, or via SVG, or via native OpenGL calls applied to a vector font stored in the client, downloaded by a standard UUID from the server, or provided in a separate call to allow finer control.

That is, the API:

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

solves the original problem, doesn't interfere with HTML on a prim, or SVG textures, and can be implemented using any of these if it turns out to be efficient (not that it will). In addition, it's extensible. For example:

llSetRenderTextFont(integer font, integer type, string name, list params);

this would define a new font that could be specified in llRenderText. The name could be the name of your SVG texture, or a bitmap texture, or a URL for a vector font file, or anything else that can be provided as a texture, with optional parameters describing the way characters are encoded.

THIS bit is an "indirect" interface. It's something that might lock you in or break in a later release. That's why it's optional, and an extension. ANYTHING that exposes details or capabilities of any particular implementation in the API has this problem. That's one of the reasons why I find myself opposing interfaces (whether in the call and parameters, or in necessary configuration tools like (say) the texture picker) that create dependencies on specific implementation technologies through indirection.

But llRenderText is an "abstract" interface. The encoding of the text and the rendering mechanism can change and the code still works. Just as printf("Hello World"; doesn't know about terminal drivers, the 7-bit USASCII character set, or ISO latin-1, or OpenGL, or window systems, or UTF-8.

The overhead of HTML on a prim, no matter how much work was done to optimize refreshing, is multiple decimal orders of magnitude greater than techniques like adjusting the offset of a texture that are already higher overhead than is really practical for widespread use.

There is no way that HTML on a prim can possibly be used to solve even a fraction of the problems that a traditional design like llRenderText could. That Linden Labs is even considering this, let alone spending time on it, indicates a massive project management or organizational problem.

Have you tried the ubrowser?

What is being proposed is the ability to put text and much more on a prim without the need to even involve a script.

Your proposal forces those that are not experienced at all with script languages to learn something about script languages to put even the most basic text on a prim. I'm sure they'll rather just upload a texture with the text they drew in their favorite paint program.



My proposal is to get the most basic and static image of SVG with a GUI interface that goes with it. While I was in ubrowser, I happened to look at the w3c web page about SVG, and I noticed the new draft for SVG Print, which seems to handle exactly the need for static SVG images. Obviously, I am not the only one who desires this ability.



No need to get hyperbolic illustrative because that confuses me. However, you did mention LSL with Mono. I'll reiterate that I suggest no new interface with LSL in order to keep LSL as much as possible for forwards and backwards compatibility. Being very very strict with that forwards and backwards compatibility is major need.

With Mono, you don't need to use LSL, so backwards compatibility is not even an issues here. There is already talk about being able to include library code into CIL compilations wheter it be from C# or another language that compiles to CIL.

The implementation of your llRenderText(), or just to render text on a prim from a script language, can be best done within a CIL library integration. I'm sure its interface would be a little more towards object oriented style than just a plain flat function call. The benifit here is that you would be able to implement the text ability that your propose and you would not have to work for LL in order to implement it.



Any extension to LSL except to the interfaces that already exist are a problem for forward and backwards compatibility. LSL uses a very flat function call interface. Every program anguage that has used a flat function interface call has demonstrated this problem. It is best to minimize the problem with no new function calls in LSL.

This last reason (paragraph) is the main reason I vote no on llRenderText() in LSL.

I'm not against the different ideas for its implementation, but it is best to wait for the ability to do it in a CIL module.



I'm glad you like abstract interfaces. I'm sure you will agree to the ability to abstract low-level interfaces to the prim in CIL, like:


using SecondLife;
using ArgentTextFunctions;

namespace HelloNameSpace
{}

One more thing...

...using library code like the example above...

The ability to protect Intellectual Property in scripts is possible. Wheras before, you had to either expose the entire script (give it away) or demand LL to "just make it work."

Just like how Sellers want to protect their content from CopyBot, I, and I'm sure there are many others, would love that ability to protect the content of code but still offer an interface to it.

Even if the overhead of the uBrowser is a fraction of the overhead of the lightest graphical web browser's I've ever used... including ones that run on PDAs... it's still too much overhead to use routinely in SL where textures are used now. The gap in overhead between "rendering in OpenGL using operations that take place entirely within the GPU" and "running a copy of the Gecko rendering engine to generate a texture to be applied to a prim" is so enormous that I can't bring myself to write down enough zeroes to approximate it. You'll think I'm being facetious.

The whole point of "text on a HUD" is controlling text from scripts. This whole thread is about scripted control of text. That's why I have been trying (unsuccessfully) to understand what the hell you were getting at, because the context here is "controlling text from a script".

Only in response, and only to point out that it's irrelevant.

You're not going to get "no new interface in LSL" whether LL implements llRenderText, or llAnythingElse, because EVERY new release of SL includes new interfaces in LSL. Let's repeat that. Every new release includes new functions and interfaces in LSL.

Mono is completely and utterly irrelevant here. Really. The API is not "an LSL API" or "a Mono API", and there's no benefit to accrue from not including it in LSL, and whether it's implemented in LSL or not you still need to implement an appropriate and useful abstraction for rendering text on a prim from LSL. How it is implemented is outside the scope of this discussion.

Oh god. Another word corrupted by geeks.

That is NOT an abstract interface. That is an indirect interface. You're using technical jargon that a certain part of the software industry has adopted, where the concept that's more usually referred to as "indirection" has been tagged as "abstraction".

I don't know whether the fault belongs to Microsoft or Sun. You see this misuse of the term "abstraction" all over the place in Java code and in Windows toolkits. But when I'm talking about an "abstract interface" I most emphatically do not mean the kind of thing you're talking about here.

I'm sorry I used the term now. If I knew you were going to run with Javaspeak like that I'd have racked my brains for another one.

There are obvious way to complete optimize SVG and many other functions of the Gecko engine. What the Gecko engine provides is a one stop general purpose document rendered based on open standards. Any general purpose feature is practically incomparable to a feature that is specifically optimized to perform a single function. You have tried to specifically optimize llRenderText() as the main argument to of why it should be implemented over any other more general purpose suggestion.



*sigh*

If speed was the main concern, then llRenderText() would be a good inclusion. However, scalability and security are the main concern. Lindens Labs has even repeated time and time again that they choose scalability and security over other great features. I agree with scalability and security.

With if I created a prim with a specific texture, and I don't want you to put text anywhere over that texture. That is a security issues. I can think of reasons why. Just think of the instances that people have tried to put a clear object over a sploder. Same thing with a vendor I wouldn't want some text on the prim change the price of what the item says it is.

Scalability... We already know that the vector graphics themselves are easily scalable - much easier than rasterized graphics. There are other programatic scalable issues, as I given an example, that we will not get from llRenderText() benig in LSL.



I don't understand this argument because SVG images allow you to control text and other images without a script. However, you argue that is script is needed anyways. Perhaps, the title of this thread should be "Controlling text on a HUD from LSL." It is not that. It is in the feature suggestions for text on a HUD.



To state that it is mandatory to implement in LSL is irrelevant. In discussion in the mailist, you have seen the talk about Mono and know it is an option. It's been shown in the video. Whatever you change about LSL now, you'll also have to implement in CIL. However, there is the question if a function even needs to be interfaced with in LSL, and I bet you'll find with many new features that they do not need to interface with LSL at all.



They implemented new features to give LSL better security control.



At this time, I believe existence of llRenderText() in LSL will not happen, and it is a moot point because of Mono. There simply are ways to do it with textures to satisfy the basic need until Mono is fully deployed. Also see xyText().




I'll avoid the tidbits of uneeded controversy here. I don't use Java. Java isn't a real object-oriented language as it is promoted to be.

Perhaps, you would instead like to provide details of what you disagree is not a lower-level abstraction.

I noticed someone was talking about rendering different languages with language specific functions. LSL currently uses UTF8 as it's internal method of representing Unicode; so the need to have language specific functions is not needed. Just about all of SL now uses UTF8 (except for notecards and a few old interface windows). That said, to use unicode characters you need the unicode version of the arial font.

Unicode, or UTF-8 encoded, only is able to cover so many languages that use an alphabetic characters or serial glyphs. Even when the glyphs are coalesced together in one manner or another defined by unicode standards, it still is limited. Unicode only supports simplified forms of many modern languages. Modern web browsers look for key sequences in text along with a combination of personal user settings in order to switch between unicode and other more funtional styles, like Big5 and related dialects not found in Unicode. The user settings affect the over all view. Hebrew (which is simplified in unicode) and like languages are more phonetically written than glyphically and usually written right to left. The whole perception of those that read Hebrew and like languages is not the same as left to right. It is not as simple as to just implement a text function to change the direction of letters being displayed from left to right to right to left. This is true for many cyrllic based languages.

We are fortunate that many societies have derived a more alphabetic language or basic stroke (radical based) and glyphic language within the context of their main language that can be included in Unicode.

Unicode does not support ideograms, for example. The 65,000 character limitation of Unicode is not enough to support a world agreeble subset of ideograms when there are way more than 65,000 ideograms known. Like Big5 and various dialects, there are plug-ins to the web browser you can get to render many ideograms that are stroke based and also lack radicals.