Text Rendering to a Prim Face

Extend LSL to support direct drawing of text to a prim face.

Right now, the only way to do dynamic text is with XyText which is, while a wonderful technological achievement, a very slow and wasteful solution.

Something like ...

llDrawText(DEFAULT_FONT, 10, <0,0,0>, "Hello World!", ALL_SIDES);

+10. Though XyText is cool, it is a horrible, inefficient hack.

This has been suggested ad nauseum. I would love to have something like this, but since the lindens havent added it yet, i suspect they wont add it any time soon.

Just in general, if the users request something frequently, maybe it's your customers saying they want it? Maybe, just maybe?

Lindens? We haven't heard a peep from you concerning lots of things. Anybody there?

*crickets*

Eggy the Pessimist

(or as we like to call him, Ol' Grumpyhead.)

They might add this... Eventually. I'm sure it's not high on the list right now. While everyone wants this, I don't think anyone has come up with a complete proposal as to how it would work. At least not one that will do what everyone will want/expect it to do. So many questions to answer...


How much text can you fit on one face?

Does it wrap?

How do you format it?

Does it become a texture, or is it client generated, like particles?

Does it support colors? User-provided fonts? (Will there need to be font objects and uploads?)

Is it ASCII? HTML? ANSI?

Will it support international character sets?


LOTS of questions still unanswered on this. It's a big can of worms, and one that will take a lot of time and discussion to come up with a viable solution that does what everyone needs it to do. Getting the design of something as big as this wrong at the start can cause huge headaches down the road. If it's going to be done, it needs to be done RIGHT.

Discuss.

Heh if Active Worlds and There can handle this, surely the clever SL devs can do it. I think it's just a matter of handling higher priorities right now =)

Kex, AW and There are client-heavy.
That's why.
Having a script command rendering textures on the client and streaming them to the servers is anathema to the SL architecture.
In beta, all textures were easily copyable because LL wanted to cut down on the uploads. Since their primary bandwidth use is them uploading to us, I would guess that doing the opposite is more costly in terms of how much their ISP charges them.
So they are probably not very keen on anything that lets us automagically generate and upload a lot of content tat costs them a lot of bandwidth and disk space...

No, Eggy, the whole reason for this is to reduce the amount of bandwidth SL uses. Client-side texture baking uses far less bandwith.

I haven't heard anything from the Lindens that indicates they're against client-side texture rendering. I think it far more likely that this is something they'd like to implement but just haven't had the time to do properly yet.

My idea of text textures is for the texture bitmap to be generated client-side upon reciept of a command from the server.

No actual rasterized texture data is transferred, just the text itself. The rasterized texture is not uploaded to the server. The server just has to send all clients the command to draw text on one or more sides of a prim.

This isn't really "client-heavy" compared to some of the other things that are done in the SL client.

Techniques like this are already in place in the client, such as when you have display shadows turned on. I highly doubt the server streams new ground textures becuase a shadow needs (re)drawn =)

As long as we're talking client-side texture baking, give us a simple 2D graphics API, too. You know, fills and lines and such. If you want to really go for broke, make it support sprites based on server-side textures. Haha, that'd be great; we could write video games.

Yes, that's really what I'd like to see, Chromal. If you're going to do something, do it properly.

If we DID have some basic markup for manipulating fonts and 2D shapes on a face, we'd be able to do some pretty cool stuff. Games could be a lot faster, and stuff like signs would be simple and practical.

i'd settle right now for being able to float text in front of a prim rather than over it. with that option, i can talk to a script, have it format a string with returns et cetera, then float the white text in front of a black board.

floating text is already generated clientside and only needs options to 1) position it on a specific side of a prim and 2) orient it to a single direction so that it's not spinning on it's axis following the sightline.

it wouldn't be "on" the prim; but it would lend the same effect.

That's an excellent temporary solution, Khamon!!!

(Feature Request It)

I think there's basicaly 2 ways they coudl do it. They could make a render-to-texture kind of thing where you can just render text to a texture and its a bitmap...


Or a 'text' primitive, that is 3d.

The former would only work on some video cards, and might be very slow (due to hardware)


The latter would work on all video cards, but is quite a technical thing to do (Code-wise), although it would cost a really tiny amount of bandiwdth to send such a 'text object' to someone.

Not that I'm an expert, but i think this floating couldn't be made to "orient" itself. it only appears to spin because it is always head on to make displaying it really a 2d thing, no 3d at all.

Exactly.

I'm a RL software designer/developer. I can tell you from experience that rendering graphics on-the-fly is no picnic. Not even 2D graphics are "simple." 2D text is worlds more complicated than that. 3D is getting out of hand, and 3D text is an absolute nightmare.

Me personally, I'd forget about 3D text alltogether. What I think would be nice is that ability to create a 2D text-based, anti-aliased, 32-bit bitmap on-the-fly and have it sit on the face of a prim as a decal.

You still have all of the problems of calculating text size, how many decals to allow on a prim face, whether implementation of this would involve allowing the use of normal uploaded bitmaps as decals (PLEASE!!!!!!) And if you allow multiple decals, there has to be a way to specify z-order, so that if they overlap, they overlap correctly.

Then, of course, there's the issue of fonts. What fonts to use? How many styles? How many different fonts within each style? Do you restrict the text to a single color, or do you define the text as a 2D vector, and allow it to be "filled" with any color/colors/bitmap?

Coding with a system that's already in place for text-to-bitmap is a pain in the butt. Coding the system itself... A nightmare.

I, myself, have been on the bandwagon for a feature like this since last summer. (And bitmap decals, PLEASE!!!) But I realize that it's a tall order to fill.

I think that the number of people that have expressed a want/need/desire for decals and/or surface text is relatively small, compared to the number of people that complained about the economy, or wanted custom animations, for instance.

It's probably just way down the list because there are other requests/issues that have more squeaky wheels. But even if/when they get to it, it ain't gonna happen overnight.


*** Edit ***
A viable alternative may be to simply implement some sort of decal mechanism, without worrying about the text problem for the time being. Especially if multiple decals were allowed per face. Paying L$10 per character/symbol to upload the decals is nowhere near as big a deal as the prim usage issue is now.

Let's all rez hundreds of XyText boards in every sim, bring SL to it's knees. You'll see this feature implemented in a heartbeat

Making the llSetText lock to an object's orientation instead of locking to the camera's would not be very hard.

I, too, am a game programmer, with the interface as my main speciality. In most games, th e"2D" user interface is actually 3D, just with zero thickness and snapped separately from the rest of the scene (so objects in the world don't stick through it and it's lighting is different).

But since the llSetText is locked in space to a 3D object and can be hidden by objects, it's actually IN the 3D space. I've done something very similar before for debugging (floating infor over NPC's heads, for instance) and I had to write code to MAKE the text face the camera all the time. Take that code out, and the text would turn with the NPC.

I'm all for doing something like that in SL as a temporary measure. It can be very hard to see llSetText messages when they are half sticking through walls and things.

This is really silly. It doesn't need to be anywhere near this complex. Do the simplest thing that solves the problem; if it's insufficient to cause enough people to want more, then implement more. Trying to raise all these theoretical issues is just going to put off implementation of something that WORKS for most use cases. "optimize for the common case", etc. Trying to do what everybody *says* they need is a futile endeavor, as anybody who has worked on a large software library or framework can tell you. Besides, LSL is *full* of compromises with developer-time; I'm glad that I have a language that's fairly general purpose instead of a language that can format text WONDERFULLY and sucks at everything else because they couldn't spend any time on the other stuff.

Ok. End development philosophy, begin practical suggestions.

Simple text. Maybe optional automatic wrapping; that's really easy to implement, but if LL doesn't feel like it, it can be implemented in LSL. Format it as a plain old string with newlines embedded. No HTML. No ANSI. Too much work. Personally, I don't care about custom fonts, and it would take a lot more work to implement, but I think setting the size of the text is probably a pretty important feature.

The biggest problem is probably going to be international charsets, and as anybody who has delved into the world of unicode knows, that's really annoying. But I don't think it's so bad if they just require a particular encoding of the text. Does llSetText support international charsets? Again, personally I don't give a hoot about international charsets, but that may be something that a lot of others want. (?) I would suggest going with a simple latin charset until someone pipes up that they want other stuff.

This is where XMLRPC will come in handy. It will be easy enough to have a processor running on a server that can handle one-time transactions of incoming text, and outgoing graphics file. a moderately well equiped apache/php server can generate text graphics using GD and true type fonts on the fly. Heck, even I've got one of those servers running at home.


In fact, you could do this so many ridiculously cool ways. One option could be to split the texture 1:1 ratio, or wide 2:1 or 3:1 or however many squares you want to render out to. It may not be ideal or totally in-game, but.. when I'm done, I'll only charge you L$10 per 1x1 ratio square you render to. I think I can even glean your SL IM email and IM you a link to your graphic or something.

yes yes, all in my spare time. haha.

The problem is you can't import an image via XML-RPC.

1) XML-RPC data packets are limited to one integer and one string maxlength 255.

2) There's no way to convert script data to a texture within SL.

3) Even if you could automate it somehow using macros on your PC, it would still cost L$10 per texture.

jeesh,

I didn't mean to imply XMLRPC would import the graphic for you. I actually did say "IM you a link to your graphic" which I thought was clear enough to imply that you'd have to import it yourself manually. Sorry for the lack of clarity.

Ideally you wouldn't need to render text to graphics and import it into the game maually, it would just be built in.

So, if that's any help to Linden Labs, look into open source scripts out there that will render text to graphics. It'd be worth L$10 to be able to generate text textures without having to launch photoshop, that's for sure.

Sorry for the confusion, I once remember someone suggesting using XML-RPC to transfer images not too long ago, and I guess I just assumed it was the same idea =)

Now that I understand, I think what you're suggesting could save people a bunch of work =)