Nulling Backfaces

Hi everyone!

I have a question about performance, and I was wondering if someone might have an answer.

I typically 'NULL' out backfaces on my builds, and by that I mean I apply an 8x8 completely transparent texture to them to make it easier to see through, and so that only 'visible' faces are properly textured.

The alternative way to do this of course would be to set the face to have 100% transparency, and make it just a blank texture. I guess that might save on texture loading and such.

I guess my question has two parts: Do either of these techniques cause the face to stop being rendered, and does anyone have any thoughts on which of the two methods work best?

Thanks!

Actually, odd as it may seem, making "hidden" faces transparent (any 32-bit texture, or transparency via sliders or scripts) actually *increases* rendering cost! Transparent faces require more calculation than a plain 24-bit texture. So if the face can't be seen, just make it either the defailt "Plywood" texture, or "Blank", or any 24-bit texture that you wish to use. I usually use the same texture as is most visible on an adjacent face, so the seams show less. As long as it is a texture that is already visible, it adds nothing to the rendering cost.

I think the true rendering cost of 100% transparency (texture or prim property) IS null... It still gets calculated in ARC by default simply because it is transparency. But an actual affect on framerate due to any rendering costs doesn't exist. (^_^)

As an example, I have an avatar with huge sculpted wings that are scripted to appear only when flying. While they're at 0% transparency, I get a sub-1FPS to 2FPS hit. At 50% transparency, I get about a 4FPS hit. At 100% I get no hit at all. But, between 50% and 100% transparency my ARC value is identical. It's one of the most general flaws of the ARC calculating method. (=_=)

The rendering lag in transparency comes from the image layering required to tint and overlay the semi-transparent object to what ever is behind it. For 100% transparency, none of that blending work is needed, so the graphics engine has an easier time drawing the frames while completely neglecting the fully clear face. (^_^)y

Okay, so in effect a 32 bit alpha texture is just a visual benefit, but a blank texture with 100% transparency would be better since it stops the texture having to be calculated? :)

Client side, the rendering load is identical... No gain or loss there. Overall lag-wise (net-lag & sim-lag specifically), I'd sooner prefer an untextured face with 100% transparency. Simply because it's one less thing for your visitor's client to download, decode, and cache while the object is rezzing. (^_^)y

Thanks for the advise! *changes to the transparency method!*

There's no such thing as an "untextured face" in SL.

Just because it's transparent doesn't mean the texture isn't downloaded.

Actually... "Blank" texture is technically a texture client-side, but, there isn't a texture asset to download to support it, so the network & server traffic required to support is is merely a stream of properties for color, transparency, glow, fullbright, and shiny. This can be proven by creating an entire "Blank" prim build, clearing cache, and relogging. You'll quickly discover that these prims won't have a gray-state while rezzing since there's nothing to download. (^_^)y

You might want to look into how occlusion culling is handled in SL http://secondlife.com/app/help/new/culling.php

That's pretty valid... The one thing not mentioned is if all faces are required to be opaque. I'm guessing that as long as all the faces in front of an avatar's camera make up a full-screen opaque surface, culling applies. (^_^)

The fun part, is that it seems to be easily tested::

It's on a per object basis. Objects in a group are considered one object. So if a tiny corner of a prim in a 100 object group is visible, all objects in that group are considered "visible" and not culled. The texture pass generally occurs after the geometry is established, so the geometry is there even if it isn't visible on screen due to the shader or texture information making it transparent.

AFAIKT The only per face operation that SL performs is the usual backface culling. What the OP is inquiring about is technically called hidden surface removal, which SL doesn't have. HSR is usually only available to off-line renderers like Mental Ray or RenderMan, or realtime engines that can tag surfaces with nodraw flags and compile their levels in preparation for realtime use, such as Quake or Unreal.

As far as I can tell, a prim with a 32-bit texture on it and a prim that has a 24-bit texture and a slider setting for transparency that is anything other than zero are both reated identically, as 32-bit textures. Simple experiment: Rez a plywood box in front of an alpha-mapped window, and it doesn't show the alpha-sorting glitch. Set the transparency slider for that box to 10%, and it does show the alpha sorting glitch. As far as the client is concerned, it is a 32-bit texture.

That's just two different ways available in SL of making a transparency shader that ultimately gets handled the same way in regards to Z sorting.

One sets it in the alpha via the 32 bit texture map, the other sets the transparency levels in the shader instructions via the interface. Both types of transparency must eventually be processed by the engine with the results having the usual sorting issues.

I don't think anyone mentioned it so: the best solution for faces that aren't going to be visible is to leave them with the same texture as the rest of the prim (or in the case of multiples a texture that is on a adjoining and visible face) and leave it bland as far as face properties go (no shiny, no glow, etc).

Realistically invisible faces are often visible due to prim drift, what we think (or what looks like) a perfect join but isn't, etc so since you can't get rid of the face and you can rarely guarantee that it won't ever become visible the goal should be to minimize the overhead in case it ever does become visible if only by 1mm.

Putting a different texture on the face will guarantee an extra texture swap and an extra render batch, having the same texture on it doesn't guarantee it won't happen but it's at least possible that it'll end up in the same batch as the rest that shares the same texture.

Since the goal is to minimize the overhead when the face is visible, alpha/transparency is a poor choice for obvious reasons.

---

Regardless of the above a good or bad choice isn't likely to ever make a difference so it's really not something you should be worrying about or spending time on when there's so much else that would/does make a difference.

I aksed a similar question here in the forums last November and this was the link with responses.
My understanding from the replies was using a 32 bit or transparent texture actually increase the lag issues and not reduce them.

/109/70/214665/1.html