New Prim: 10 sided Cube

Feature Request: A new 10 sided prim cube.

huh?

Basically I want a cube that has on one 'face' 5 faces, in a row. A cube which can have 5 different textures in a row on one side.

Actually I would rather have a 15 sided one (10 sides on one face) but that may be greedy.

Why??

Nice marquees / dynamic displays are expensive, because you need 1 prim per letter. Well actually, I have a working board with 1 prim per 2 letters, and I just made a prim that will let me show 3 letters but its not really flat.

A 'billboard' or 'marque' prim would really, really help cut costs (by a factor of 5!) on displays. Which would make them more common and I think they have a great potential to look a lot better than llSetText. To look more 'real' at least.

There are of course other solutions - a more general approach of a script call to place a texture on only part of the face of a prim for example. A new prim just seems easiest though, the methods are already there for marquees that change the texture on a face, and they could be easily adapted to a new prim like this.

Allow me to tie this into a pet idea of mine, which is the addition of a very basic built-in image editor which would allow us some minor editing features on textures, such as concatening different textures into one, for use on the inner side of a hollow cube, which is mysteriously counted as a single surface even though it clearly has several sides.
If we were allowed to control these very basic image editing functions through scripting, we could concatenate characters into a single texture prior to setting them on a single prim screen.
It might be a little bit of a load on the server side, though it could very well run on the client, and even if it would cost 10 bucks per upload as usual, it would still be very handy.

How about just letting us write characters to a "texture"? SL already comes with one or two fonts. I've seen some of these displays, they cost upwards of four thousand L$ just to rez a medium-sized one. Bleh.

Write an interface similar to Java's font metrics and let us write characters to surfaces of primitives in that way. You get a texture handle, tell it to be so many rows by so many columns with font X, and there you go. One-prim TTY.

If you want to get fancy, let people use uploaded TTFs or whatever.

I like that idea, Huns!

--H2o

Hmm I dont know much about TTFs but I take it they are monochrome in nature... with my idea you could have any tile-based game in SL that you wanted, which is my real goal in using such displays.

The basis of my idea was a solution that fit in the existing system.

A system to write fonts to a side would be great, but is an extreme departure from what already exists. And it seems like a lot of work.

Procedural editing of textures (eggys idea) would also be great, and I have seen it mentioned before. To me, a casual bystander, it seems like a lot of work though.

The system we currently have is parametrically defined primitives. So making a new one that has multiple textures to a face seems to fit into the system.

Or here is a different one, how about 2 new parameters - cells X and cells Y that would let us set how many texture cells were on the forward face. If it could be changed via script that would rock.

I know displays cost a lot, thats why I suggested something like this. I currently have 2 'cheap' displays - a score screen for my memory game displays 60 characters on 30 primitives ($300 to rez $30 tax), and a 12 char marquee on 4 primitives ($40 to rez $4 tax). But they are relatively small. With a primitive that is 5 or 10 texture cells on one side I can make much bigger displays. If it is 5 or 10 cells on every side I can make a 1 prim 15 or 30 character marquee. If it is customizable in both X and Y the options are limitless.

The easier the solution to develop, usually the quicker it is developed. I like both your ideas, what I have seen of the system leads me to believe a new prim or new parameter on a prim would be easier to implement in the existing system. And not that hard of a work around to create a font system from there.

- Ama

TrueType fonts are vector-based. What color is rendered is up to the rendering library.

next you'll want a 20-sided die

Now that you mention it .....

Huns I know they are vector based but "any color I want" is still monochrome as in one color per letter or symbol.
What I would really love would be the ability to generate graphics with client side functions, framebuffer style, and upload them to SL as a texture that could be instamagically displayed on a prim but for ama's purposes simple concatenation would suffice.
And Ama, the prims arent made by the Lindens so I dont think new prim requests will go a long way. They are the basic shapes that already come with OpenGL plus some other shapes that are built upon those by adding preset values, like a 50% cut sphere.