the mystery of primitives (bis)

reposted since it's an important question and nobody dare to answer it

I wanted to write a little essay on building optimisation in sl and i came to something very curious:

according to my knowledge of 3D and game design, you need 6 polygons(12 triangles) to make a cube. now iknow sl use a dynamic lod but its highest level is wasting tons of resource

i noticed sl use not 6 but 24 of them to dram a cube!!!! (each face is splited in 4, multiplying the number of faces by 4) (4times)

the same thing happend on prisms, 34 triangles instead of 8 (more than 4 times)

on cylinders, tubes and rings it seems even when NOT twisted, the primitive is divided in half in its length;
on cylinders, 144 triangles instead of 96 almost twice what is needed
on tube, 336 tri instad of 192
on rings, 288 instead of 144

could we have an explanation? it would mean that basically, most if not any sl builds eat twice more polygons as they should normally

client lag? look no further if peoples wear haircuts made of 92000 triangles (80 torii)

Because SL is based on solid geometry I'm not sure the rules apply, but I'll ask someone who knows more about this!

Lighting.

Light values are calculated per vertex. For better lighting, you need more vertices. Suppose a cube 10m to a side has a light with a range of 4m placed near the center of one of its faces. Unless the cube's faces are subdivided, the light will not affect any of its vertices, and the center fo the face will be dark. If just one vertex is placed in the center of the cube, appearances are much better, but if the light is very small and only has a 2m range, moving it across the surface of the cube would appear to make it flicker.

Per pixel lighting can help, which involves using pixel shaders to calculate the lighting value for each pixel, however distance calculations are very costly as they require a square root, and many lighting calculations such as angular attenuation and specular highlights tend to require normalization of vectors, which is also costly, even after low-precision optimizations like the use of a normalization cubemap. For this reason, most per pixel lighting algorithms tend to calculate distance attenuation per vertex, which means even when pixel shaders and per-pixel lighting is in play, large surfaces must still be subdivided in order to be appropriately lit by dynamic lights.

The only lighting algorithm for point lights that does not require subdivision of large surfaces is lightmapping, where light and shadow contributions are stored in a second texture that is applied to the base texture. This technique is used in virtually every major graphics engine. Light maps are always generated as a post-process when a scene is complete (finished), and are generally ray traced, or "baked" (see global illumination, photon mapping, et al). Due to the complex nature of scenes in Second Life, generating light maps for a region would take an inordinately long amount of time, and light maps would have to be regenerated every time the static geometry in the region changes. Since every object in the world can contain a script that may or may not make it move, determining what is static and what is not is not trivial, and partial solutions that only include unscripted objects create garish artifacts. Since the generation of light maps would have to be done as part of an automated maintenance process, it might be hours or even days before a new build is "finally" lit. For this reason, we have been unable to apply light maps to Second Life.