Using Transparency to reduce Lag

It was recently mentioned to me that when using lots of prims, (for example covering a plot of land in prims) The sides that cannot be seen should be transparent.

My first question

By applying this method will it help to reduce lag?

if yes, should more of us be using this method to make builds more user friendly?

Actually, it will increase lag. Every surface with transparency has to be rendered twice.

I'm not sure why some people think making the unseen faces transparent is a good thing to do, but here's my best guess. It probably has to do with the fact that many people don't know that they're supposed to assign profiles for programs like SL in their video card driver settings, profiles which instruct the card to use anti-aliasing to make the edges of objects appear smooth instead of jagged. It's very likely that without anti-aliasing turned on, the spaces between the jags could expose little pieces of faces that are supposed to be completely obscured. Turning those faces transparent would make them less noticeable.

I'm not a mind reader, of course, but I'd be willing to bet that's where the transparency suggestion got started. I wouldn't recommend it myself.

My advice, configure your video card properly, and don't use transparency where it's not needed. If you turn 5 sides of a cube transparent, you're looking at 11 render passes to draw that cube instead of 6. That's a huge difference. Use transparency only when absolutely necessary.

Thanks for that Chosen, my question was more about being user friendly and if it would help other users that have lower end Cards.

So with your answer other than leaving the prim blank or with a 24 bit texture it will make absolutley no difference on lag.

Perhaps you could stick that somewhere on your sticky, as I have seen a number of places in world that use transparency to that effect.

Regards the GC, no probs my end profile assigned etc, but hopefully that will help other readers viewing your reply.

Ooooo, very interesting. I often have this problem with little pieces of edge faces showing in between perfectly aligned prims.

I have never even heard of assigning profiles in the video card driver settings. Is this just a Windows thing, or can it be done on a Mac too? Also, does the profile only affect appearance when in full-screen mode, or also in a window?

ETA: Just checked, and I definitely don't have anti-aliasing turned on for the SL client.

Subject to Chosen's answer if and when it comes, the little edges you see between 2 joined prims was another issue and not to do with Anti Aliasing, correct me If I am wrong, but I am sure I read another post about this sometime ago and there was not a great deal you could do other than change the colours of the edges on the prim to lighter or darker, but this also varies when in different daytime modes.

But I await another answer to be corrected if I am wrong.

here's a fun question... does the use of 100% alpha in the texture, vs 100% alpha in the prim properties make a difference to a vid card rendering an object? also does the "invisibility prim texture" (the one that doesn't show up on ctrl+alt+t) make any difference? also, shouldn't object/object occlusion keep the card from rending those hidden faces?

I tend to make the hidden faces of things I make (especially LARGE things) 100% alpha, just because I realize cameras (or avs) can sometimes end up inside them, and it can be very confusing... there is also the problem that if some of my prim faces are alpha, they dissappear behind the "invisibility prim texture" but solid textures dont, and that can cause interior faces to show in an ugly way. in the past I've used 100% alpha in prim properties, and also small textures with 100% alpha, and the "invisible prim texture"... so additional info would be nice

the only time I don't bother with alphas for hidden faces is when using "prim paper" (sphere dimple .49 & .51 convert to cube set z size = .01), I figure if it is rendering, then the default wood texture (or whatever texture I'm using on other faces) is less of a load... but thinking about it that could be wrong too

Not sure I understand what you're asking, Larrie. Can you clarify?


As I understand it, the answer is no. Assigning transparency to the prim has the same effect as putting transparency in the texture.


That's a tough one. My understanding of how the invisiprim texture works is it reverses the order in which things are drawn, causing objects that should appear behind the texture to appear in front of it. The texture itself is not actually transparent.

This, I assume, is why invisiprims can be shiny. It's all about crazy drawing order. While the colors of the texture end up drawn behind everything else, the shine effector does not. It remains in front, where it's supposed to be.

It's important to remember, the invisiprim effect originally was (and arguably still is) a bug. It just happened to be a useful bug that a lot of people started to depend on, so they chose not to fix it. It's possible that might change one day, either on purpose or by accident as other bugs that might relate to it get fixed. (not saying it will or won't happen, only that it's possible)


If SL worked better, it would. I'm pretty sure though that occlusion culling in SL does not have the sophistication required to operate on a per face or per polygon level. As far as I know, it works just on a per object basis, meaning if you can see any part of an object, the whole thing is drawn.

I'd love to hear I'm wrong about that, so if anyone knows different, please speak up. I don't think I'm wrong though.


Good example of where functionality is more important than saving a few processing cycles, I'd say. I'd think whether each instance of this technique is really necessary though. In some areas, I'm sure it is, but in others, it's probably not. It would probably be a good idea to limit it if you can.


The way it could be "less of a load" would be if the thin edges had the same texture on them as the front and back. If the edges have their own texturing, that's just one more load and one more to render. Chances are most people will already have the default plywood cached, so loading it in most cases won't be a huge deal, but still, why have it present if it doesn't need to be? There's no real benefit.

Chosen, with reference to Ava's post re the perfectly aligned prims.



I also have this problem on some prims/walls and the lines can be seen where the joins are. If I change the colour to slightly darker I can almost eliminate them, but then if I Force sun to a different time they sometimes comeback.

What can this be?

My GC is set at its highest with Anti Aliasing x16 amongst other settings so surely can't be that.

Larrie unless you can ensure mathematically that your edges are perfectly aligned you'll always see weirdness because the faces are rasterized seperately. Even if you get them 0.0001 meters together, there's still a gap that might show up at a certain angle, especially when the sun is angled so that it hits the inner wall and makes it brighter.

Keep in mind that prims do not block sunlight from other prims, so even though you've got an teeny weeny gap, it will still receive full sunlight at times, making the gap more noticeable.

It seems that with every SL release I have to re-set the anti-aliasing in the nvidia control panel. Also, I'm just guessing on which setting to use. I once took the time to figure out what each looks like and made the best choice based on the information I dug up, only to have my choice lost on the next version. Since I don't remember and don't have the patience to research it again, I'm now just guessing.

Also, there's a transparency anti-aliasing setting that either I didn't notice before or have forgotten about. Guessing I didn't turn that on before, so won't turn it on now.

Maybe I'll fret about this when I do photography, but for now, "wtf, why does this have to be so hard?" rules the day. Guessing that the low-numbered option offers the least performance hit, and seem to recall seeing little or no difference in SL between the settings.

I was mistaken Still, I'm now using "4x" rather than "8xS" only because I'm guessing the former is less demanding than the latter and that the former is "good enough". Wish I didn't have to make these kinds of decisions, or that there was more SL-specific guidance. And that these decisions only had to be made once.

the disadvantage to using a texture is the whole texture part of it

100,000 people, 80,000 different alpha textures

and thats more to ask for, find, transfer (progressively as the rest of it is found), save, render

versus

1 tiny flag assigned to the prim properties

You shouldn't have to do that. As long as you're installing each new version of SecondLife.exe to the same folder you had installed the first one, the nVidia profile should never know the difference. I've never had to assign a profile more than once for any program.


If you're using a recent version of the nVidia control panel, it will show you a written description of what each setting does when you click on it. At least, that's how it works on my desktop (GeForce 8800's), and my laptop (GeForce 8600). Maybe it's different with older cards.

If your (ud to date) nVida Control Panel does not have thedescriptions, download a program called nHancer. It's a free alternative to the nVCP and its descriptions are very informative.


Yeah, sampling 4 times per frame will certainly be less taxing than sampling 8 times per frame. It won't look as good though, obviously.

The best thing to do is take about 10 minutes and run through the full range of settings. Watch for where the slowdown point is. If 4x seems to run well, step up to 8x. If that's still good, try 8xQ. If things start to slow down at 8xQ, then you know 8x was your magic number. If things are still good though at 8xQ, step up through the 16's. You want to use as much AA as you can get away with, no more, no less.



When I said "same effect", I was referring just to video performance, as that was what the question I was answering was about. Asset management, obviously is a different subject, but also very important, so it's good that you brought it up.

I completely agree with you in principle. The fact that everybody's got their own unique transparency texture, from a technical standpoint, is really silly. Ideally, everyone should be using the same one. But obviously, there's no practical way to make that happen.

Also in principle, it makes perfect sense that using a script to turn faces transparent would be way more efficient than using a texture to do it, as long as the transparent faces do not themselves have unique textures on them. Ideally, you'd want the transparent faces of a prim to use the same texture as one of the visible faces. Assuming people would adhere to that, then the script would definitely be the best way to go.

Unfortunately though, practice is different from principle. I think a lot of people would probably end up putting all kinds of bizarre stuff on the transparent faces, which would defeat the purpose. Not everyone would do the wrong thing, so there would of course be some degree of savings. It's just not a complete solution, unfortunately.

Also, there are plenty of people, myself included, who really, really, really hate having to worry about which face number is which. I build all day long every day, and to me, tinkering with scripts and face numbers would be a big hassle. It would slow me down and annoy me tremendously. It's a lot faster and easier for me just to work visually. If I want to affect a face, I just select it, slap a texture on it, set any parameters I need to set in the editor, and move on.

It's really unfortunate that we can't set 100% transparency in the editor; it makes no sense that we can't. It would eliminate the need for scripting for this purpose altogether, and would go a long way toward eliminating the use of all those different transparent textures out there. Clearly (no pun intended), that would be a win-win for everyone.

Couple of little observations here.

First, it would be critically important that any "full alpha setting" scripts be removed or set not running, because every running script competes for a tiny slice of sim resources each frame. (The same is true for texture animation scripts, for example, which set a prim property years ago and are still hanging out in the prim, doing nothing, but getting a scheduler slice forevermore.)

Second, and just kinda FYI, there's a huge difference between full-alpha *textures* and textures rendered 100% transparent by a script *if* the object contains scripts that respond to touch. Only in the former case are the transparent faces touchable.

To the general topic: This is for me the most frustrating part of building, by far: getting seams to really disappear. Perfectly aligned prims are definitely not good enough to avoid seams altogether, with or without transparency of the mated faces--although I've found transparency to help in many cases. Tiny overlaps help if the prims are *identical*, but mating a cut face with a perfectly aligned uncut face is subject to floating point error (apparently), and anything with a curved face is hopeless at distances where LoD kicks in.

But the real *need* to use transparent hidden faces (whether they mate or not) was already pointed out by Void: it's really confusing to get one's cam caught inside a prim and see those hidden faces. If a build is just for pretty pictures, it doesn't matter, but for actual navigability, it's a big deal.

wait.... if I set full alpha via script, strip it out.... that face won't recieve touch events? or pass touch events if it's a child prim?

but if I use 100% alpha textures (or invisiprim textures) it will?

::me goes to play with this idea immediately::

EDIT: Just tried this.... doesn't seem to hold true unless I'm missing something?

Well, to my surprise, at least in the current viewer, scripted-alpha faces are indeed touchable, but one gets the arrow cursor instead of the hand. Here's the script I used to try it:

list TEXTURES = 
    [ "4c1ce202-4196-f1c1-0409-367b3a71543e"    // transparent
    , "89556747-24cb-43ed-920b-47caed15465f"    // default
    ];

integer alphap = FALSE;

cycleTexture()
{
    llSetTexture(llList2String(TEXTURES, alphap), ALL_SIDES);
    if (alphap)
    {
        llSetAlpha(1.0, ALL_SIDES);
        llSetText("Touch Me", <1,1,1>, 1);
    }
    else
    {
        llSetAlpha(0.0, ALL_SIDES);
        llSetText("Touch Me if you can", <1,1,1>, 1);
    }
    alphap = ! alphap;
}

default
{
    state_entry()
    {
        cycleTexture();
    }
    touch_start(integer total_number)
    {
        cycleTexture();
    }
}

I swear I just did this maybe a week ago and it worked, maybe when this viewer was a Release Candidate. Okay, well... never mind.

Ooopsy... faulty memory. It's backwards of how I'd recalled, and actually right-click behavior that's affected: This script demonstrates:

list TEXTURES = 
    [ "4c1ce202-4196-f1c1-0409-367b3a71543e"    // transparent
    , "89556747-24cb-43ed-920b-47caed15465f"    // default
    ];

integer alphap = FALSE;

cycleTexture()
{
    if (alphap)
    {
        llSetText("RightClick me", <1,1,1>, 1);
        llSetAlpha(0.0, ALL_SIDES);
    }
    else
    {
        llSetText("betcha can't RightClick me", <1,1,1>, 1);
        llSetAlpha(1.0, ALL_SIDES);
    }
    llSetTexture(llList2String(TEXTURES, alphap), ALL_SIDES);
    alphap = ! alphap;
}

default
{
    state_entry()
    {
        cycleTexture();
    }
    touch_start(integer total_number)
    {
        cycleTexture();
    }
}

Helpfully, the cursor stays an arrow, not a hand, for the case when right-click isn't available.

Sorry for the mistake.

Interesting. I never knew about the right click thing, probably because my editor window is open almost all the time. With the editor window open, you can right click anything, alpha or no alpha, script or no script.

so no effect on left click eh? =( and here I thought I ALMOST had a great use for this....

stupid alpha'd tail on my kitty av (LCC's Snow Leopard, Free Plug!) gets in the way when I want to use the mouse to control av turning while walking.... I got so annoyed with it one day I rewrote all the alpha switching scripts to shrink the offending prims out of the way... but it's choppy coming back sometimes

I'm sure there's a use for this..... just can't place it yet

eh I thought of one, but it's not nice

what if i met you half way, heres what i propose (aside from being able to just set 100% alpha in the edit window)

you make a prim, and "flag" the sides you want transparent with a "magic" color

i whip up a script that looks for the "magic" color, sets those faces to transparent, and deletes itself

now instead of dragging a random alpha texture to a prim face, your setting color and dragging a script file to the prim, which may keep the ease while also skipping the extra texture

^¿^
\__/

I like it.

To make it as quickly useful as possible, could you put the RGB value for the color right at the top of the script? That way I can change it easily without having to think.

well you have 16581375 to choose from but yea, changing a rgb value in a script for use in a particular project is not a big deal

okie

Actually if use llSetAlpha instead of a texture, it will still be 6.

Where are you getting that from, Bobby? I tend to doubt the renderer has any way of knowing the difference between a surface that was made transparent by a script, and one that was made transparent by a texture. I would think that all it could possibly know is this:

Pass 1 = Draw the polygons.

Pass 2 = check for transparency on each surface, and if it's present, draw whatever's "behind" each surface on top of it.

In order for llSetAlpha to have the effect you're claiming, it would have to interrupt that process, and substitute it with a different one. Do you have any evidence to show how it (allegedly) does this?

Anyone more knowledgeable than I am on how all this works at the programmatic level able to shed any light on this?