Decals!

The last time this was mentioned was 2003, it would seem, so I'd like to bring it back up for discussion.

Between video card and bandwidth limitations, it's in every texturer's interest to be as economical as possible. Through economy, however, it's easy to end up with sterility. Breaking up otherwise repetitious tiling textures requires adding variant textures to your build, and you quickly end up with a build that takes 6 to 12 textures rather than 2 or 3.

I've heard of overlays/decals being considered as an addition to skin tattoo functionality. How hard would it be to introduce a secondary texture layer for primitives, to allow for the quick addition of an alpha-channeled texture atop a prim's current texture? Would there be performance costs I'm not considering?

The savings here seems like it could be worthwhile. Also better for creators, who could apply a base look to an object and then quickly adorn it with damage or other detail goodies without having to transfer extra, slightly modified versions of the same texture to the client.

edit: yes, you can do this by adding another prim, but that's kludgy and can interfere with other transparency operations

Uhhm.... well. On paper, this isn't too hard. In practice, though:

1. This would mean seriously revamping the way prims function, as well as affect LSL calls like llGetPrimitiveParams([PRIM_TEXTURE,face]), llGetTexture(face), and others. You would also have to multiply the texture data sent out, per prim, by two.

2. Alpha on alpha does not function/render very well under the existing system on prims, either. Usually I suffer some erksome rendering issues with .TGA textures layered three or more deep, so this is another thing to think about. Methinks that will be fixed under the new render engine, though.

3. Finally, why? While I would *love* to see multitexturing-by-prim work, frankly doubling prims has a lower rendering impact than, say, doing that with a 3D mesh. I don't see the immediate necessity, though for the long haul this is a good idea.

i could see this being a good thing if you want to add marks on walls, grafitti, bullet holes, foot prints etc but if you just want to use it to make some variety in your building textures.......well a 32 bit "decal" texture over a 24 bit base texture is worse than just having two 24 bit textures that look slightly different to begin with isn't it?

in the meantime between now and the new rendering engine that might have something like this you might want to try instead of one 512x512 texture make two 256x256 textures that are slightly different in the details. for most things they will look just fine even on 10x10 prims but the 2 textures will take up half the space of the one larger one. heck you could make 4 textures with different details and still use as much memory (roughly) as one boring old 512x512. kinda does the job of decals until we have real decals. hitting them with a 50% unsharp mask in photoshop before you upload makes them look a lil bit better too.

if you're already using 256x256 textures then you rule. try four slightly different 128x128 textures and see how they treat you. depending on what and how big the thing you're building is sometimes 32x32 is all you need.

Thanks for the tips, Zuzi. I remember awhile back when I discovered how well 256x256 works for most all textures. I felt like such a good citizen.

Jeffrey, those are the very impacts I was curious to learn about. Given that, I can understand if this isn't something that's implemented for a very long time.

btw, by overlaying an alpha-channeled decal atop a prim's existing texture, I was imagining that the two would be composited and mapped as a single texture, which would avoid the alpha-on-alpha weirdness. But the compositing operation would probably introduce more server overhead than really necessary so we may as well distribute the task to individual creators' copies of Photoshop, as we already do.