|
Dans un article récent, nous faisions état de nouvelles avancées en matière de textures utilisées par le viewer de Second Life. L'un de ses changements - il semble que ce ne soit pas pour tout de suite - est la possibilité d'importer et d'afficher des textures sans passer par le chargement interne payé 10 l$ l'image.
Le viewer de Second Life propose déjà la posibilité de placer sur une face de prim, une image provenant d'une adresse web, mais il s'agit du même mécanisme que d'y placer une vidéo. Cette technique est très restrictive et, donc, inutile quand on veut assurer toute la décoration d'un build par ce moyen.
Les développeurs officiels et les développeurs alternatifs travaillent à réaliser l'un des vieux rêves de tout buildeur : la possibilté d'utiliser des textures non chargées par le processus habituel - gratuites - et rangées à l'extérieur de Second Life. Ce projet est très avancé et porte le nom de HTTP-Texture. Comme l'explique le wiki, l'idée de départ est de permettre au viewer de désigner n'importe quelle image de n'importe quel format n'importe où dans internet, de la charger en utilisant le protocol HTTP et de l'utiliser comme une texture normale à n'importe quel endroit où les textures sont utilisées.
Pour le moment, cette possibilité est réduite aux images JPG. Les codes sources ont été mélangés aux codes du viewer depuis les premiers jours de mai 2009 et HTTP_Texture constitue une nouvelle branche du viewer. D'après les développeurs consultés, cette possibilité n'aura pas d'impact avec le build, si ce n'est qu'un fournisseur de viewer alternatif s'y penche et trouve une solution viable. La fonctionnalité HTTP_Texture ne pourrait être accessible que par un script LSL. Une première fonctions LSL chargerait l'image et retournerait une clé unique (UUID) ; cette clé pourrait ensuite être utilisée dans les nombreuses fonction du LSL ayant trait au traitement des textures. Bien que je n'aie aucune confirmation officielle et que je n'aie pu en trouver trace dans un source accessible (LSL et Mono sont du côté serveur), j'ai vu passer une note qui donnait un exemple du genre :
key llRequestWebTexture(string url); (ceci est donné sans aucune garantie) L'un des gros problèmes est l'utilisation d'un cache pour une telle texture ; comment articuler le chargement d'une HTTP_texture avec la gestion du flux de textures fait justement pour des images que nous ne pouvons mettre à jour. Dans le cas habituel toute modification d'une image revient à créer une nouvelle texture alors que dans le cas de HTTP_Texture, l'un des intérêts essentiels repose sur la mise à jour à volonté de l'image qui se trouve à l'autre bout de l'url. Question complémentaire : que se passera-t'il si l'url est erronée ou si l'image n'est pas compatible? Attendons, nous y verrons plus clair un jour ou l'autre. Garmin Kawaguichi
in the texture
Remarque ultérieure : une fois cet article rédigé, j'apprends que l'utilisation première de la fonctionnalité HTTP_texture sera pour l'affichage de la Carte du viewer de Second Life ; actuellement la carte interne au viewer utilise des textures de régions qui sont dans le serveur d'assets alors que SLUrl utilise des images JPeg. HTTP_Texture sera un moyen d'unifier les 2 types de cartes, le but étant d'accélérer l'affichage de la carte interne, améliorer la qualité des images 256x256 utilisées par la carte et qui souffrent du JPEG2000, éviter la dupplication et ses coût et de réduire la charge des serveurs. (Notez que cette tâche est dévolue à l'équipe de Philip Linden). (Notez que la carte interne est appelée Map UI, la Carte de l'Interface Utilisateur). Quant à un accès par les utilisateurs (LSL), aucune date n'a été donnée.
|
- -
Team building
