A propos du cache texture de SecondLife - Partie 1

Pour ceux qui ont eu la patience de lire l'article precedent jusqu'au bout, il se seront peut etre demandé : "Ok, c'est bien joli tout ca, mais elle est ou la texture dans tout ca ?"

Et bien elle n'y est pas. Enfin, pas la en tout cas.
Ce fichier texture.entries est un fichier très simple, petit (assez petit pour etre stocké en permanence en memoire pendant l'execution de SL) et donc... rapide a utiliser.

Dans secondlife la vitesse d'execution est importante, ca rame deja assez comme ca non ?
Ce fichier est simplement un index qui est tenu a jour par le logiciel pour repondre rapidement a : "Est ce que la texture que je dois afficher sur ce prims est stocké dans mon cache, ou est ce que je dois la telecharger depuis les serveurs de secondlife ?".
Avoir un index des fichiers present dans le cache est donc tres utile et doit etre rapide.
Et avoir un fichier du type de celui du precedent article EST rapide, simple, leger, donc efficace :)


Mais au final ? Ou est la texture ?
C'est ... compliqué.
Linden Lab aurait put appliquer la methode suivante :
- un fichier qui indexe les textures cachées sur votre disque dur.
- un ou plusieurs repertoires contenant les dites textures.

Mais du coup les fichiers seront des textures directement lisible, editables avec photoshop et pouvant etre reuploader dans SL. Et ca va pas du tout du tout ! Parce que les fameuses textures qui sont stockées sur votre disque dur, dans le cache, ne sont pas forcements (et meme pratiquement jamais) des textures sur lequelles vous avez les droits de copie/modification/transfert. Hors, s'il y a un moyen de les recuperer puis les reuploader, vous vous retrouvez avec des textures full perm, a votre nom, dans votre inventaire. Horreur, scandale, abomination, vol de contenu, emeute et 5000eme mort annoncée de SL et son economie.

Vous connaissez la musique je suppose ? ;)
A propos de musique justement, Les majors de l'industrie du film et du disque depensent des millions, peut etre même des milliards afin de tenter de proteger les contenus. Sans succes, c'est peine perdue. Et bien c'est pareil dans secondlife. Quelle que soit la methode il y aura toujours moyen de "voler des textures", en utilisant le cache, ou par d'autres moyens (comme les recuprer dans la memoire video de la carte graphique par exemple).

Ce que font les majors, et ce que fait secondlife, c'est "la securité par l'obscurité". Autrement dit il font en sorte que le contenu a proteger soit stocké d'une facon qui rend compliqué le "vol". Par la cryptographie ou par d'autres moyens.

Linden Lab n'utilise pas la cryptographie car c'est lent et consommateur de precieuses ressources CPU. (on en a jamais trop avec SL).

A la place, ils stockent les textures d'une facon un peu bizzare... que je ne detaillerai bien evidemment pas.
Grosso modo il y a un fichier contenant les 600 premiers octets (a quelques details près ;) ) de toutes les textures stockées. Tous entassés les un derrieres les autres. (s'il y a 100 textures, ca fait un fichier de 600*100bytes (a quelques details pres, encore))

Une serie de fichier dont le nom est l'UUID de la texture, et qui contient la texture elle-meme *moins* les 600 premiers bytes (a quelques details près) qui sont, eux, stocké dans le gros fichier cité juste au dessus.

Un ficher permetant de savoir a quel endroit du gros fichier se trouvent les 600bytes qui interessent. Car il n'est pas possible de retrouver l'UUID de la texture directement dans le premier fichier, simplement parce que ca serait "trop simple" de les recuperer. Sans ce 3eme fichier, le 1er fichier est un gros tas de n*600bytes completement inutilisables.

C'est pour cela que quand on ouvre le ficher de texture directement dans photoshop, il n'arrive pas a l'ouvrir, car il manque (a quelques details pres) les 600 premiers bytes du fichier, qui se trouvent etres les plus importants car il contiennent les "entetes" qui permet a photoshop de decoder le format j2c puis de l'affichier.

Ce n'est pas si difficile que ca que d'assembler tout ca, et de finir avec une texture utilisable. Et d'avoir au final reussi a "voler" une texture. Ca demande de savoir programmer, de prendre le temps de defaire les sacs de noeuds que Linden Lab a mis en place pour rendre la chose plus difficile et de ... vouloir le faire.

Et, visiblement (et j'en suis heureux), ce qui peuvent le faire ne veulent pas perdre du temps a voler des textures.
Et ceux qui voudraient bien, n'en n'ont pas le talent (ca c'est pas une surprise) ;)

Au final, est ce que ce sac de noeud ne ralenti pas le systeme de cache ?
Un peu, tres peu, car la plus grosse partie du temps n'est pas dans la recherche/assemblage de la texture, mais dans le format de compression utilisé. Le format j2c est tres pratique, très bien, mais... lent a decompresser. Et c'est cette decompression qui prend la majorité du temps.
Aucun interet a rendre la recherche/assemblage du fichier 2x fois plus rapide si 99% du temps est passé dans la decompression du format j2c. Il faudrait plutot optimiser la decompression, mais la... C'est deja optimisé a mort.