Pues no me había enterado de la pregunta. La respuesta no es tan fácil. Las texturas suben de nuestro ordenador a SL a través del cliente. El cliente tiene que realizar los siguientes trabajos: cargar la textura, decodificarla, comprimirla en formato jpeg2000 que es el que maneja el sim para cargarla a nuestro inventario. El peso de la textura no infliye prácticamente nada en el conjunto. El tener que descomprimirlo primero, para decodificarlo y subirlo, si. Mejor sin comprimir. Importante y mucho que el formtao sea compatible con OpenGL,(GPL), que es como lee los graficos SL.
A continuación publico resúmenes técnicos de algunos correos intercambiados al respecto y de algunos foro. En resumen es mejor usar formato TGA:
------------------------------------------------------------
I think I missed the bit about "the destructive effect of JPEG2000" on the list. Currently lossy compression is only used when the source is a JPEG and lossless for BMP and TGA. The point of using a format like JPEG2000 is that it achieves high compression ratios superior to other formats for the same image quality. For modern codecs to achieves high compression ratios they sacrifice CPU time. The reason for the push for higher ratios is to reduce the amount of storage and bandwidth required for transmission. If SL moves away from using JPEG2000 and towards a less CPU intensive, lower compression ratio codec, the asset servers will be serving more data per asset request. This seems like a step backwards and not forwards. As an intermediate format to save CPU time to avert the costly re-decoding of an image, it makes sense to pick a faster format though it will be costly in diskspace; and as long as the disk is not horibly fragmented it has the potential to be faster then decoding. A format needs to fit these criteria to be considered for this task:
1. Lossless
2. Support a variable number of channels.
3. Fast to encode, fast to decode
4. Preferably GPL compatible.
This excludes: GIF & JPEG. This may also exclude PNG because most implementations treat anything that is fully transparent as rgba(0,0,0,0); white images develop black outlines at low resolutions (not lossless). Strife Onizuka 21:08, 24 March 2007 (PDT)
---------------------------------------------------------------------
http://en.wikipedia.org/wiki/Huffman_coding may be worth a look. It may work well with 'jpeg artifacts' Paula Innis 13:03, 25 March 2007 (PDT)
Take a look at
http://en.wikipedia.org/wiki/Huffman_coding#Applications. See DEFLATE there? That's what .zip uses. You can get it with zlib. Dale Glass 13:19, 25 March 2007 (PDT)
And as
http://www.zlib.net says; 'Note that zlib is an integral part of libpng'. There is also .DXT to consider. Paula Innis 14:21, 25 March 2007 (PDT)
Right. I said that because I don't get why you're mentioning Huffman then. It's been implicitly brought up by Tofu ("I'd now use trusty old zlib") and Seg Baphomet and Strife Onizuka (who mentioned PNG) before you added that. DXT, if you refer to S3 Texture Compression, is lossy, and patented, which almost certainly makes it unacceptable.
-------------------------------------------------------------------
Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..
1. Are they talking about on-disk texture cache or the subset of textures that resides in video memory? The page topic suggests the former, the discussion seems to be about the latter.--Dreamer Miquel 03:51, 31 August 2007 (PDT)
Contribution from Steve Linden from email discussion:
2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:
a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)
b. Once a frame, reduce the current pixel coverage of all textures by 10%. This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code "assume that all textures are no longer visible" and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.
1. Doesn't this reduce the pixel coverage of all textures to zero after - at most - a few minutes, if they aren't rendered? Let's say a computer does 50fps. In 5 minutes, it does 15000 frames ( 50fps * 300 seconds). In this time, the pixel coverage degrades by the factor 0.9^15000 = 4,34E-687, which is beyond float and double precission. Hence, after this time, the coverage of all these textures would be rounded to zero. If I'm correct, this means, that ALL texture that are not used for 5 minutes would be discarded as soon as a sweep is performed. --Dreamer Miquel 03:33, 31 August 2007 (PDT)
3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.
do that mean that, even if we have a lot of VRAM available, the texture will be removed from cache if we don't see the texture for 30s ? and then, moving our avatar in the sim will make the client redecoding the texture from cache to load it in VRAM again ? Why not discarding the texture only when we're out of memory ? (please delete/replace this comment by the answer) Kerunix Flan 08:18, 24 March 2007 (PDT)
4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client > Rendering > Run Multiple Threads, the decoding will be done on the second CPU and go much faster.
I can't believe loading a texture from a remote cache isn't much slower than loading a texture from a local cache. And if you add the usual packet loss and high ping (for non-us user) it's *certainly* much slower. Kerunix Flan 08:18, 24 March 2007 (PDT)
He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:
https://lists.secondlife.com/piperm...rch/001133.html
Iron Perth 02:44, 24 March 2007 (PDT)
=======================================================
Espero que esta rápida explicación os aclare algo el tema.
____________
Lo importante del otro avatar, no es su shape, es su mente.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GTW d+ d- s: C++ (wife) UL P L++ vi W++ N+ o+ FSM (http://www.venganza.org/) w
O-- PS+ PE Y++ PGP+ t+ 5 X- R tv- b++ DI++ D
G e++ h--- r+++ y+
------END GEEK CODE BLOCK------
Foro 
