Non-graphic way to put text on a billboard/poster?

[Melissa Yeuxdoux]

The other day I was in a store waiting for a sign to rez; I think it described how to use the store's vendors. As it slowly rendered and the text became more legible at a leisurely pace, I had to wonder how it was created. Is it the canonical board with a texture, so that the client has to load a 2^n x 2^n graphics file to paint the board, or is there a way to keep the text on a sign as text for rendering at the client?

I suspect the latter is true, since there's been HTML on a prim for a while. So the real question is--what is making that sign take so long to show up in legible form? Maybe it just looks like the old days in which an interleaved GIF file took forever to download and sat there as a barely recognizable blur until all the data arrived, and the real bottleneck is somewhere else. What is best practice for text-only or text-mostly billboards in SL?

[Peggy Paperdoll]

A sign is a texture placed on some prim.........usually a flattened cube.  That "text" you see that makes up the sign is a texture......hopefully an 8 bit or 24 bit texture and not a 32 bit texture.  And since it's a texture (and not text as in what you see here in this forum or on your word processor) it must rez just like every other texture in SL......that wall over there with the fancy flowers for instance.

 

So I guess you're asking if there's any other way...........the answer is no.  Well, if you want pay for a hosting service I suppose  you could put it there as HTML and stream it back into SL for a media on a prim type display.  That's pretty complicated and expensive for a simple sign.

[Charolotte Caxton]

Hi, Peggy. Why hopefully an 8 or 24 bit and not a 32?

[Sven Pertelson]

Take a look at Xytext and its variants on the SL wiki at http://wiki.secondlife.com/wiki/CatText to see how this is done.

[Drongle McMahon]

"That's pretty complicated and expensive for a simple sign."

Also worth bearing in mind that paranoid people, like myself, have media-on-a-prim permanently disabled for imaginary security reasons.

[Chosen Few]

---

Charolotte Caxton wrote:

Why hopefully an 8 or 24 bit and not a 32?

---

I'm not sure why 8-bit was mentioned, since SL cannot utilize 8-bit imagery.  Everything is 24-bit (RGB) or 32-bit (RGBA).  If you try to upload an 8-bit image, it will trigger an "Unable to read image" error.

As for why "hopefully 24 and not 32", there are three primary reasons one might make that statement: 

1.  As you might have guessed from the numbers alone, a 24-bit image contains 25% less information than a 32-bit image (assuming both have the same amount of pixels, of course).  So, there's less to download, less to store in memory, and less to process.  (Note, the word "less" in this context does not speak to image quality in any way.  Each 8-bit channel in an image has a specific function.  32-bit images merely have an extra function that 24-bit images do not.  More on this in the next point.)

2.  The extra 8 bits in a 32-bit image are for the transparency channel (alpha channel).  If a transparency channel is present in an image, the renderer has to do an extra pass to calculate the blended transparency values before it can render the frame.  Thus, every 32-bit image in every scene causes more lag than would its 24-bit counterpart.  (The first 24-bits, so you know, are for the three color channels: red, green, and blue.  Each of these is an 8-bit data map, just like the alpha channel.  The only difference is the RGB channels are each assigned to govern a color, whereas the alpha channel, if present, is assigned to govern transparency.  As I said above, each channel has its function.)

3.  Due to the nature of how blended transparency works in any real-time 3D simulation, the presence of 32-bit textures can trigger a very common rendering artifact, called the alpha sorting glitch.  Computers don't define concepts such as "in front" and "in back" the same way that humans do, so when two or more surfaces with 32-bit textures overlap in 3D space, the renderer cannot always know the right order in which to draw them.  Hence, objects that you woud expect to appear in the background will often jump to the foreground, and vice versa.

 

For more information on alpha channels, and on 24-bit vs. 32-bit textures, see the stickied guide at the top of the old old forum archive.  Here's the direct link: http://forums-archive.secondlife.com/109/32/80851/1.html

[Charolotte Caxton]

Thank you so much Chosen for your as always excellent mini tutorial. I am one of those persons that thought less bytes means less quality and that 32 would always be better than 24 because I am also the type of person that thinks bread at 1.99 is way cheaper than two dollar bread. 

Now, the two quotes in the middle of your article? I think you mistakenly attributed the quotes to me when you meant the op.

And the part, "These things do run on science and math, after all, not magic."  I hadn't realized there was a difference

 

[Rage Riptide]

What happened to "Text on a Prim"? That was around two or three years ago. I know it was in OpenSim, it was as too easy and convenient for everything text. Guess I just dreamed it was implimented in SL but I wonder why not.

Oh yeah. went bigger shiny with HTML on a Prim and walked all over the simple text.

[Amethyst Jetaime]

You may be thinking of xytext. This is done with a texture and a script.  A simplified explanation of how this works is that the texture is a single one with the whole alphabet on it, and the script tells the prim what position to display the texture in so only one character is seen on that surface at a time.

Since xytext involves textures PLUS a script it can actually take longer to see and cause more lag than a simple 24 bit texture would.  Xytext is handy for boards where the information must be changed constantly, such as a contest board, an event board, or even the boards you see in clubs that tell you what is streaming and the name and title of a song but is overkill for simple signs.

[Chosen Few]

---

Charolotte Caxton wrote:

Now, the two quotes in the middle of your article? I think you mistakenly attributed the quotes to me when you meant the op.

---

 

D'oh!  Sorry about that, Charolotte.  I'll correct that now.

[Chosen Few]

---

Melissa Yeuxdoux wrote:

So the real question is--what is making that sign take so long to show up in legible form?

---

There are a million chaotic factors that will affect the time it takes for any image (or any asset at all) to load.  The amount of network traffic at the given moment, the speed of your Internet connection, your modem and router, your computer itself, the size of the file you're trying to download, the amount of memory the image requires when decompressed for display, the bit depth of the image, as well as a whole list of other things too long to even begin to write, all play a significant role.

Since you mentioned you were at a store (which presumably is in a mall of some sort), the likely most significant singular culprit is just the sheer amount of images that are on display.  The average mall in SL contains thousands of assets, which all have to be individually download before you can see them.  It can take a while to receive any one file out of the lot.  And that's before you even consider what happens after you do receive them all.  The average mall has several gigabytes worth of textures on display at any given moment, while the average video card can only handle a few hundred megabytes at a time.  Hence, it's hardly surprising that things end up slowing way down.  And if there are a lot of other avatars walking around, things get exponentially worse pretty quickly.

With all that in mind, it's fairly miraculous that SL even works at all, at any semblance of usable speed.  In the grand scheme, we can hardly say it's big deal to have to wait a few extra seconds for any particular image to load, when we know how much else is going on.  These things do run on science and math, after all, not magic.

 

---

Melissa Yeuxdoux wrote:

What is best practice for text-only or text-mostly billboards in SL?

---

That's an easy one.  It's the same as the best practice for everything else.  Do more with less, always.  Never ever make a texture any larger than it has to be, and never go 32-bit unless you absolutely need transparency in the image.

Texture abuse is the single biggest reason SL runs as slowly as it does.  People do idiotic things like slap a 1024x1024 image on a little 2-foot sign that's never going to occupy more than a couple hundred pixels worth of space on anybody's screen.  Or they think "more bits" must somehow be better than "less bits", so they use 32-bit textures for everything.

The main reason why video games, even ones that are streamed, run so much faster than SL is because the content in them is made by professionals who are conscientious enough to optimize for performance.  SL content, on the other hand, is made primarily by amateurs, who have no idea what they're doing.  Ignoramuses read the tag line, "my world, my imagination", and interpret it to mean the are no governing principles whatsoever, and everything should just work, no mater what.  Then they get mad at the system when their own misguided actions bring it to its knees.

To summarize, keep your textures as small as possible, whether they're for signage or anything else.  Also, repeat textures as much as possible within any scene, to cut down on the amount of individual assets that are present.  Encourage everyone around you to do the same, as loudly and as frequently as you can.  If they don't want to hear it, tell them again..  and again, and again, and again, until they get it.  It's for their benefit as much as for your own.

[Charolotte Caxton]

---

Chosen Few wrote:

---

Charolotte Caxton wrote:

Now, the two quotes in the middle of your article? I think you mistakenly attributed the quotes to me when you meant the op.

---

 

D'oh!  Sorry about that, Charolotte.  I'll correct that now.

---

No problem, Chosen, it was just throwing me off  

Again, excellent tutorial, and thanks for the link!!

[Shelby Silverspar]

---

Chosen Few wrote:

---

Charolotte Caxton wrote:

Why hopefully an 8 or 24 bit and not a 32?

---

I'm not sure why 8-bit was mentioned, since SL cannot utilize 8-bit imagery.  Everything is 24-bit (RGB) or 32-bit (RGBA).  If you try to upload an 8-bit image, it will trigger an "Unable to read image" error.

---

No longer true - 8-bit jpgs do work in SL now.

[Chosen Few]

---

Shelby Silverspar wrote:

No longer true - 8-bit jpgs do work in SL now.

---

Interesting.  Any idea when they added that? 

I find it strange that they would go the trouble to incorporate support for 8-bit JPG's, but not also add support for 8-bit TGA's or BMP's, when JPG is so lousy at handling the types of images that grayscale is so ften used for while TGA and BMP work so much better.

[Shelby Silverspar]

I want to say at least a year, but I really don't remember exactly when it was added. 8-bit png files and bmp files work also, but not 8-bit tga files.

[Rufus Darkfold]

---

Peggy Paperdoll wrote:

…

So I guess you're asking if there's any other way...........the answer is no.  Well, if you want pay for a hosting service I suppose  you could put it there as HTML and stream it back into SL for a media on a prim type display.  That's pretty complicated and expensive for a simple sign.

---

You could use a data: url and embed the text in the URL itself, or host the text on a Secondlife object using llRequestURL().

I use xyzzytext as others have suggested to avoid depending on media-on-a-prim.   Though I run with it enabled,  many do not.

Has xyxxytext been upgraded to take advantage of the 8 faces available with mesh?  They should be able to get 16 characters per prim now instead of just 10.