NO RENDERING texture!!

if there is so;ething who can really help to speed up the game, its a non render texture, so the prim face with this texture applied will NOT be rendered. many people use transparent texture to hide objects but these invisible faces are still calculated by the 3d engine i think,

another example is about wals and structures, on a good part of the prims, only 3 or 4 faces are visible on a cube prim, this mean that the rest of the faces are rendered for nothing.

give us a NO RENDERIING texture ^_^

No, the invisible texture as it is now only leads to griefing and has no real value in the game world other then to annoy. The only exception I can see would have to be avatars.

Ryen, I dont think you get Kyrah's point. I think he's saying that prim faces that are 100% transparent (aka, invisible, but not camouflaging) can instead have a texture applied to them that 'opts them out' of the rendering process.

If 100% invisible prims are available now, why is this a problem?

There's a ton of uses for the invisible texture beyond griefing and annoyance. Invisible light objects for greater control over lighting for example...

As for the original post.. I think its a good idea.

I once had to use a tiny invisible object to make a llSetText (I think is the name of the function) tag show up a small distance away from an object I was trying to "name", because setting the text on the object was causing the text to display partially "in" the wall it was next to. There's definitely good uses for it.

As the SL engine is now, it renders everything in the direction you're looking within x amount of meters that you set in prefs. So, regardless of if you have a huge wall blocking your view or not, it still renders everything on the other side.

Most modern FPS games use occlusion I think it is, to calculate if an object is visible or not, and if it's not, it isn't rendered. If LL could implement this it would have a HUGE performance impact in prim intense areas.

One problem that comes to mind off the top of my head is walls that use alpha maps for windows.. it would be hard to make the engine figure out whether you can see through it or not.

FPS games can do polygon-level occlusion testing because they know whether or not any polys with alpha textures are involved. SL can't -- because textures are user-created, it needs to assume any poly can have an alpha texture. In consequence, it does fragment-level occlusion testing.

Heh, I think everyone's talking about something different here.

Kyrah's talking about having a special face property as in Quake's no_draw texture that just eliminated it --geometry and all-- from the rendering engine completely.

Ryen's talking about the horrible "smoke" hack that eliminates alpha textures and avatars on the opposite side, and that has only one valid use: making avatars look cool. He's correct, it should be removed... BUT, we should have the ability to make our actual avatars transparent. The default skin is great and everything, but I'd like to be able to turn it off.

Devyn and Garoad are talking about the existing 100% alpha texture -- this still causes the faces to be processed by the renderer, it's just invisible.

And now to add my 2 cents, I'd like to see some kind of occlusion mechanism built into SL, but user-specified. I want to be able to place a couple objects in my build, or set a property on the walls, thereby disallowing the client from rendering objects outside it. This sort of thing would be very convenient for stores, games, clubs and the like, particularly if it went both ways.

This would be great for the polygons between two prims of a wall - Especially transparant walls, such as ones made of glass.

Edit: Catherine: I concur completely, I just wonder if such a system could be implimented in SL.

I use it in one of my vehicles for a legitimate purpose (no, it's not a "cloaking device". Just because you haven't thought of a valid use for it doesn't mean it should be removed, and doesn't make it a hack. It's a nice feature that could lead to some intriguing special effects.

Almost anything can be abused, and in the case of a transparent texture the advantages outweigh the disadvantages. Also it's already possible and the suggestion only referred to speeding an existing feature up by removing redundancy.

I endorse the original idea and Catherine's, both would be usefull and help take some load off (me thinks).

lol, this can't be true, sl is smart enough to know whether or not to bump map a texture based on whether it's alpha'd or not. so it does know somewhere in there, even if the alpha is in the texture rather than applied later.

Does it know about true alpha, or does it just apply this rule to every image that was uploaded as a four-channel TGA?

texture containing alpha data is considered as transparent , non alpaha are considered solid

eve a full alpha is considered trsnpqrent, so the polygon is still drawn :/

i am bumping my topic because i really think it could increase strongly the client fps to have this norender texture implemented in the game, think about all these wasted polygons,
- alpha wings, 2 cube prims, 4 faces used, 8 wasted
- in some haircuts, 243 cutted torus, 486 end caps wasted
- in a 40 by 40 meter wall, 16 cube prims, 96 faces , 48 wasted

and there is ton of examples, in a high load buuilding, judicious use of this no render textures can lead to less client load

I endorse this product and/or service

They might not do it if there would be enough overhead incurred to negate the benefits. Otherwise I think it's a pretty cool idea. They should allow unlit textures as well.

The interface is already there for this feature, see the (NONE) button on the texture selection box, but it's disabled. Much like the Undo button

so what are they waiting for?

Why not separate out the various effects instead in ways that reflect their purpose? It would avoid confusion if we had, separately:

1. "Unrendered" texture, as is being discussed here. Note that since its purpose is to reduce rendering, you cannot expect any enhanced graphic properties from it, like transparency. Making it represent a genuine absence of a polygon in the mesh would increase rendering load, not decrease it, since the containing object would then become concave. Use the other special types below for fancy properties. (Exactly what "Unrendered" would do is debateable -- probably detesselate itself into its parent.)
   
   
2. "Hole" (or "Portal" texture, ie. a traditional graphics portal of specified depth, equivalent to the absence of an object --- the side of the prim carrying the texture becomes a hole in space. A portal would give you access to the inside of a hollow box, for example.
   
   It's not processed as a texture though (doesn't reach the graphics card), but instead it adds a portal to the scenegraph. There are many ways of implementing it: the most flexible would be to allow the extent of the portal to be determined by a region of zero alpha within an ordinary texture, triggered by something as simple as a recognized name for this special texture, detected at the time the texture is applied. (You need a distinguishing property of some kind otherwise all zero-alpha textures would create portals. Just picking a particular value of alpha for this would not be backwards compatible.)
   
   
3. "Invisibility" texture: cover one side of a prim with it and no part of the parent composite object is visible when viewed through that side. Cover the whole composite object with it and the whole thing disappears from sight from all angles (still detectable by sensing etc though).
   
   This in effect takes the projection from the 1st-person eye of the viewer through the side of the prim holding the texture and right the way through the composite object to its rear side, and makes that entire volume of the composite object a portal. The geometric shape of that projected portal space does not vary if you use a 3rd person camera to view it, although obviously you get a change in perspective.
   

Unrendered texture wouldnt add load, no extra calculs, just telling the engine, just forget to draw this polygon and dont care about it, consider it do not exist

can do strage things but not as strange as pure alpha textures

But that's not a full description. What about whatever is underneath that missing polygon? If the view that was obscured by the polygon is now displayed because it's no longer covered up then the absent polygon is actually a portal, and things get a lot harder for the engine than if one simply draws the polygon with a constant colour.

So, if one isn't going to allow the absence of the polygon to increase rendering load then clearly the underlying view must not be displayed, but that implies that you have to cover it up. So, how does one cover it up without actually drawing this polygon?

Well as I suggested earlier, one approach is to detesselate the mesh at this location so that the polygon is no longer there, but merged into the adjacent polygons.

Or, did you have something else in mind?