Right now we use the spacial system texture to make invisible prims. We see it as transparent but the property is Opaque. They there should be something that could be made.

If we were starting from scratch I would recommend making "100% alpha" unrendered and making special hidden prims "almost 100%", but there's too much content that would be broken by just making 100% alpha unrendered.

This way touches still work with existing content AND the renderer doesn't get bogged down processing things that can't be seen anyway. An additional flag therefore would only be required to facilitate the creation of non-clickable items, which would be a new, separate feature.

Anyway, what I'm assuming is;

• Detection of touches is independent of the rendering of object (no evidence here)
• Objects are passed in for rendering (judging by occlusion culling as only objects that are definately visible are passed in)

Thus the fix in this circumstance is simple. In the code where objects/primitives are passed into the renderer, all that is need is a simple if statement (pseudo-code):
if (highlight_transparent || (faceAlpha > 0.0)) then render(currentFace);

ie; the above additionally assumes that individual faces are passed in (e.g along with texture data), if this is not the case then objects will need to have their average alpha value calculated as they download (or are updated) so that it can be easily queried.
This however will simply result in any object or object face which is fully transparent from ever being rendered unless highlight_transparent is enabled (in which case it's going to have a red highlight to it anyway).
Of course this hinges on touches not using rendering information to determine what has been clicked, I'm assuming atm that touches are calculated by working out a line perpendicular to the user's camera at the position they click and seeing what the first object that line collides with is.

I have no idea of the structure of the SL code though, so all this is probably easier said than donet could lend itself to greatly improved performance in well constructed areas (ie areas that use transparency on sides people can't see).

1. IF statement run against every object rendered. This is dealt with by the slow processor in the PC, and has to be checked for each object.
2. render the prim. This is handled by the FAST GPU in your graphics card, and generates very little slowdown, but adds up the more prims you have.

The problem you run into is the fact that there are FAR more renderable objects than completely alphaed ones, so the check gets run needlessly at least 80% of the time, which increases processor load. Would it balance out? who knows, but just wanted to point out that every function call (IF statement) has it's cost. No matter how small that cost may seem, when run thousands of times per frame (one for each object in view. Could fluctuate), this could get very costly. Now, factor in FACES, and you've multiplied the checks by a magnitude of 1 to 6.

I'm not 100% sure how SL handles it's geometry, but, if we assume that when an object enters a scene a geometry object is created somewhere in memory (which can then easily be passed in for rendering, and be processed for LOD), then all we need to do is remove invisible faces from that geometry when it is created/updated. Assuming 1 in 20 prims update every second, that's a ton of prims left over that are only processed once.
Add to this the fact that the checks don't even need to use floating-point arithmetic, as the floating-point checks can be done as objects download/update and stored as a boolean somewhere.

Considering this we can assume that for every 30 frames, maybe 1000 boolean checks are likely to occur on average, and that might be a pretty high guess, as many scenes don't change that frequently. Even if your avatar is turning around as fast possible, how many new objects are going to appear per frame? I'm thinking not enough to result in any significant number of checks being required.
The end result is that the cost of culling a prim doesn't need to be very high at all, compared with the cost of rendering however many hundreds of triangles it may be composed of (all which need to be lit etc.)

However, the client CAN distinguish "transparent" from "transparent with a touch event" and use that to decide whether to render the face. Going forward, though, I think a special texture is much more practical. If that texture (as well as a common "100% transparent but not invisible" texture, and the invisiprim textures) are added to the Linden library it's also just as easy, and more efficient for the client to simply compare the texture ID to that list.

I'd also like to see Coadey Concord's free alignment texture added to the Linden library.

So in other words; I don't know either way, but I'm still fairly confident that any data used would only be pulled out as needed and ray-traced then, meaning touches would still be distinctly different to rendering the scene, as it seems impractical to use the entire scene's data for touches when they only come every few frames.

• Zeph Wiefel

I think the idea of a "do not render" prim property would be good. Script settable, of course. And with some way in the client to see objects marked as such, just in case.