*Default Transparent Texture vs llSetAlpha to 0 ?

A recent reminder of the Library asset "*Default Transparent Texture" got me thinking about a thread from over a year ago, /109/70/214665/1.html ... I wonder if we know any more now than we did then about the rendering cost of all-alpha textures compared to textures set full-alpha with llSetAlpha().

We know that the viewer distinguishes between these two conditions of a surface when interpreting user interaction (right-clicks, specifically), but that's not very relevant to rendering.

It seems almost plausible that llSetAlpha-zeroed faces could go completely unrendered, and hence would cause less lag than transparent textures (each pixel of which would have to be tested for transparency to find that no rendering is necessary--unlikely--unless there's special magic applied to certain select textures).

Back at the time of the cited thread we thought the llSetAlpha approach would cut the image download lag, but that was before we got the one true transparent texture--which presumably will be cached perpetually on every viewer--so maybe it doesn't matter anymore.

On the other hand, since that thread we've also acquired llDetectedTouchFace(), so for viewers of modern vintage, a "make side transparent" script could be much easier to use than before, if it does still matter.

If they went completely unrendered, llSetAlpha zeroed sides would not cause the alpha sorting problem, would they? I haven't really tested it, but I think they do now, don't they?

This would be an interesting question for the SLdev list (which I don't read). Or, would Tofu know the right person to ask?
.

If they do, how could one tell? If they're alpha'd to zero, what's the difference whether they're (not) drawn in front or behind?

You're right: some Linden must know this. But I'm thinking a reader intimate with the right parts of the viewer source might have the answer, too.

I use the default transparent texture, and also llSetAlpha() to zero.

Wouldn't there be a difference in what ELSE becomes invisible? Right now, doesn't an alpha zero prim in "front" of a partially alpha surface cause that surface to become invisible too, at least from some angles? Isn't that why an avatar wearing invisiprims flying through clouds can be seen, like a sky-colored shadow? That wouldn't happen if it were completely unrendered.

To me, that's a big argument in favor of not rendering invisible surfaces, but from an implementation point of view I'm not sure how efficient detecting and removing transparencies from the rendering engine could be.

/bows out from the discussion, having given it the last bump she has time for this morning.

Invisiprims are a completely separate case from alpha textures.

In both cases the resulting 100% alpha face goes un-rendered. You won't find shuffling using either technique. The property based method is preferred from a data stream point of view since a 32x32 texture doesn't have to be downloaded and cached on the client. But, the end result during rendering is identical. (^_^)

Also, considering the asset is library. Consistent use of it makes any apparent gains from the property based method moot since it will practically be permanently cached on the users' clients anyway. (^_^)

Both methods are still preferred, depending on build convenience. In fact, I believe there's an XML setting you can change to allow for 100% transparency within the texture tab dialogue. (^_^)

In the end, I'm still going to promote the permanent deletion of all the myriads of "Full Transparent", "Totally Clear", "Alpha100", and any other iterations of the 'clear' texture collections since they all achieve the identical goal of the *Default Transparent Texture and llSetAlpha(). (^_^)y

On a side note: You can make a completely lag free +20K ARC avatar attachment using a few hundred 'clear' textures and cut+hollow cubes. It ~is~ an alpha texture afterall and games the ARC formula like crazy. (^_^)y

I am sure I tried this and it did not work. I will take another look at the XML file and let you know tomorrow ING.

Thanks Qie for reincarnating my original post, it is still unlcear for me though as to what the best method is. Default transparent, default (plywood) or one of the used textures in the actual build.

But then how do you deal with all the content that gets broken by that arbitrary decision to delete other 100% alpha textures? Aside from the fact that the "*Default Transparent Texture" is already in everyone's inventory now, and IF USED, would be in their cache, it's no different in actual implementation from the "100Alpha" texture that I created years ago for use in my building work. Your proposal breaks a lot of content, and gains very little in return.

You misunderstood me. (u.u)

I'm not suggesting a back-end purge of any currently-in-use assets by the Lindens or anything of the sort. If I wanted to accomplish something like that, this would have been posted in the Jira, not the forum. (>_<

I'm suggesting that we voluntarily retire and/or delete our own inventory copies in preference to the new *Default for any current future builds so that we can collectively rely on the single asset now and in the future. (^_^)y

Ah.... Yes, I had misunderstood you, Immy. Sorry if I came across rather harshly with my reply.

S'okay. Completely factual in all points. =^-^=

I still haven't tracked down a Linden likely to know the definitive answer here, and now that I think about it, I'd like their input in case it could be affected by planned changes to rendering (of which there are several, at least); I'll try to catch Nyx at Qarl's office hours later today (if I remember).

FWIW, I threw together a quick script that toggles the touched face's llSetAlpha() between 0.0 and the pre-existing alpha (or 1.0, if it started at 0.0). It requires a viewer that knows the llDetectedTouch*() functions. (Not sure anymore if that's in the standard viewer yet or only the RC; does anybody still use the standard release? But it will surely do nothing useful on the "vintage viewers" that some folks are still using. We really need an incompatible protocol change pretty soon!)

Probably pretty self-explanatory. Barely tested, so apologies in advance for bugs or obscurities--just let me know if problems. (To recover formatting, pretend to "Quote" this post and snarf the script from there.)

// Click to toggle full-alpha
// Hold to access script menu

// Released to public domain by Qie Niangao, February 20, 2009.


float HOLD_INTERVAL = 0.250;
integer MAX_SIDES = 16; // Overkill for future object types & ops.  Current limit is 9?
list saveSideAlphas;
integer chan;
integer held = FALSE;
string REVERT = "Revert Sides";
string RESET = "Set Default";  // At reset, current side alphas become new defaults
string STOP = "Stop Script";
string REMOVE = "DeleteScript";
list buttonList = [RESET, STOP, REMOVE, REVERT];
key owner;

default
{
    state_entry()
    {
        owner = llGetOwner();
        integer sideIdx;
        for (; sideIdx < MAX_SIDES; sideIdx++)
            saveSideAlphas += -1;   // Init to -1 to save pre-existing alphas 0s when encountered
        chan = -5000000 - (integer)llFrand(500000000.0);
        llListen(chan, "", owner, "");
    }
    on_rez(integer param)
    {
        llResetScript();
    }
    changed(integer change)
    {
        if (CHANGED_OWNER & change)
            llResetScript();
    }
    touch_start(integer total_number)
    {
        if (owner != llDetectedKey(0))
            return;
        llSetTimerEvent(HOLD_INTERVAL);
    }
    touch_end(integer total_number)
    {
        if (owner != llDetectedKey(0))
            return;
        llSetTimerEvent(0);
        if(held)
            held = FALSE;
        else
        {
            integer side = llDetectedTouchFace(0);
            float alpha = llGetAlpha(side);
            float oldAlpha = llList2Float(saveSideAlphas, side);
            if (0.0 > oldAlpha) // not yet stored
                saveSideAlphas = llListReplaceList(saveSideAlphas, (list)alpha, side, side);
            if (0.0 == alpha)
            {
                if (0.0 == oldAlpha)
                    llSetAlpha(1.0, side);
                else
                    llSetAlpha(oldAlpha, side);
            }
            else
                llSetAlpha(0.0, side);
        }
    }
    timer()
    {
        held = TRUE;
        llDialog(owner, "Choose operation:", buttonList, chan);
    }
    listen(integer channel, string name, key id, string message)
    {
        if (RESET == message)
        {
            llOwnerSay("Saving current alpha values for next \"Revert\"");
            llResetScript();
        }
        else
        if (REVERT == message)
        {
            integer sideIdx;
            for (; sideIdx < MAX_SIDES; sideIdx++)
            {
                float origAlpha = llList2Float(saveSideAlphas,sideIdx);
                if (origAlpha >= 0.0)
                    llSetAlpha(origAlpha, sideIdx);
            }
        }
        else
        if (STOP == message)
        {
            llOwnerSay("To re-activate script, select prim and choose \"Tools\" / \"Set Scripts to Running in Selection\"");
            llSetScriptState(llGetScriptName(), FALSE);
        }
        else
        if (REMOVE == message)
            llRemoveInventory(llGetScriptName());
    }
}

[11:47] Qie Niangao: ... So, a completely unrelated, kind of basic question about how the viewer renders (or doesn't) fully transparent faces: we think we know that a texture with all pixels full alpha causes multiple rendering passes, just like all textures with alpha channels... but we're wondering if by any chance a surface that's llSetAlpha()'d to 0.0 might just not be rendered at all. (Where "we"== some forums posters)
[11:47] Qarl Linden: that might be true, yes.
[11:48] Feynt Mistral: I actually wonder about that one myself, so "we" == those forum posters + me.
[11:48] Qarl Linden: in fact, i'd bet on it.
[11:48] Qie Niangao: thanks... that could make some lag difference in builds.
[11:48] Qarl Linden: but not much.
[11:48] Feynt Mistral: It's your job to check after this meeting, Qarl. >D

+++

So... if anybody is owed a favor by a viewer dev who braves the rendering code... it might be possible to confirm this.

Or we could find an empty sim, rez a gazillion transparent-textured prims, and see what viewer lag we get with and without 0.0 alpha, which is really why this matters at all anyway.

As to retiring old 100% transparent textures, I'm all for it. I still have a number of them that I was given when I was new. They're 1024x1024, of course.

1024x1024 I have never seen those before, I have some 512x512 but the one I always used was 128x128 and it never needed to be repeated or offset (LOL), but 1024x1024 perhaps the creator thought it would be clearer.

Edit: the Default Transparent Texture is 32x32 if I remember rightly.

Why on earth would *anyone* make a 1024 x 1024 full-alpha texture? The one I made, and use all the time, is only 8 x 8!

And yes, the "*Default Transparent Texture" in the Library is 32 x 32.