|
La carte du viewer de Second Life, tout le monde l'utilise : pour se déplacer, pour surveiller sa région, pour voir l'impact d'une nouvelle construction, pour surveiller le peuplement des alentours et ne serait-ce que pour se faire une idée de l'étendue de ce monde virtuel. Mais il y a un élément lié à cette carte de Second Life qui tarabuste tous ceux qui ont eu à vérifier que leur oeuvre apparaît bien sur la carte : quand diable cette carte a été mise à jour pour la dernière fois? Dans le temps cette question était d'autant plus importante que le délai de mise à jour de la carte était n'importe quoi ; par beau temps, on avait droit à deux mises à jour par semaine - le dimanche et le mardi - alors qu'au pire, la mise à jour était négligée pendant des semaines.
Depuis quelques mois une équipe, menée par le fameux Philip Rosedale aka Philip Linden, travaille à l'amélioration de la carte, ce qui s'est déjà traduit par une meilleure qualité de la définition. Mais aussi, on perçoit très nettement une rationalisation de la mise à jour qui est maintenant quotidienne, avec un affichage au bout d'environ 48 heures pour la carte qui se trouve incluse dans le viewer et d'environ 72 heures pour les textures cartes que l'on peut récupérer par le web. C'est là un mieux substantiel mais nous n'avons toujours pas la notion de l'instant précis auquel la carte est fixée. Une solution consisterait à maintenir un affichage de la date et de l'heure sur la région qui nous interresse. Cet affichage devrait être assez grand pour être lisible sur la carte. Il existe une technique qui permet d'avoir l'affichage d'un texte sur la carte, pour mieux comprendre observons déjà comment l'image d'une région est reproduite sur la carte. On comprend vite à l'analyse d'une région, que son image contient les notions de terrain (la découpe terre/mer, la présence de relief et la couleur du sol apparent). On voit ensuite les constructions au sol mais tout aussi bien des objets qui sont au-dessus du sol mais pas tous ; en fait le problème vient des différentes altitudes du sol dans les régions. L'altitude dans le viewer de Second Life est différente de celle que nous connaissons dans la vie réelle où l'altitude du relief ou d'un objet est déterminée par rapport au niveau de la mer. L'altitude de la mer dans le monde virtuel n'est pas la même partout (quelquefois à 70m quelquefois à 25m) ; en fait l'altitude de la mer est un paramètre de la région. Le point 0 est un point arbitraire qui correspond à un élément du render appelé "ground" ce qui se traduit par sol d'une manière générale, mais qui ici signifie le fond. Comme, théoriquement, on peut fixer pour certains points d'une région une altitude assez grande (256 mètres au-dessus du fond est plutôt rare mais possible) et comme certains bâtiments posés au sol pourraient être assez hauts, l'image de la région incorpore des éléments jusqu'à 400 mètres d'altitude. Donc en plaçant un texte à, disons, 350 mètres ce texte apparaîtrait sur la carte. Reste plus qu'à déterminer comment fabriquer ce texte. 1ère solution possible : utiliser une texture avec le texte et l'appliquer sur un objet. Cette solution serait idéale si l'image de la sim était une photo prise en altitude. Mais faire une photo ne rend pas l'image de la région avec les objets au sol et en altitude à la bonne place. En plus du fait que les objets en hauteur paraîtraient beaucoup plus gros que ceux au sol, il y a l'erreur de parallaxe. Cette erreur fait paraître les objets en hauteur déplacés vers l'extérieur de l'image.
Exemple de photo avec erreur de parallaxe : le texte qui est dans la sim Furvata paraît être placé à l'extérieur de la région (frontière symbolisée par la ligne verte), le bâtiment rose en bas à gauche montre sa façade.

En réalité l'image est fabriquée en projetant verticalement le décor sur une surface plane parallèle au sol. Les éléments d'appréciations des hauteurs sont perdus, mais l'image est un plan exact. Et voici le même texte et le même bâtiment vus dans la carte Donc cette solution paraît acceptable. Eh bien, non! Les textures des surfaces reproduites sur la carte ne sont pas détaillées. Voyez cette photo d'un montage fait sur le toit du Musée de Furvata :
 et sa représentations sur la carte :
 En fait ce n'est pas la texture que nous trouvons sur la carte mais une couleur qui paraît être un mélange des couleurs de la texture - ici un gris mélange du noir et du blanc. Donc : première solution abandonnée. 2ème solution possible : utiliser des objets obtenus à partir de textures pour sculpture et représentant chiffres et lettres. L'expérimentation va nous montrer si c'est possible. Voici la photo de lettres de couleur en sculpt, toujours sur le toit du musée.
 et sa représentation sur la carte :
 Et non! c'est toujours pas bon ; les sculpts ne sont pas représentés par leur forme sculptées mais par la prim de base ayant servi à leur création - ici des cylindres. Donc : deuxième solution abandonnée. 3ème solution : builder caractère par caractère. Ça paraît évident, on construit des objets en forme de caractères, objets qui eux apparaîtront sur la carte sans problèmes. Pour afficher la date et l'heure, il nous faut 10 caractères (en fait les chiffres de 0 à 9). Là où c'est un peu plus compliqué, c'est qu'il faut soit rezzer le bon chiffre au bon moment, soit avoir les 10 chiffres empilés à chaque emplacement et faire jouer la transparence. Donc : troisième solution trop lourde, mais faisable. 4ème solution : utiliser un code couleur. La carte du viewer rend bien les couleurs, surtout les couleurs fondamentales. L'idée est d'attribuer à chaque chiffre une couleur, l'affichage se faisant en modifiant la couleur d'une prim de taille suffisante pour être vue. Dans l'exemple monté à Furvata, j'ai utilisé des prims d'une taille de 8 mètres, cylindres pour la date et boîtes pour les heures, le tout placé à 330 mètres. Chacune des prims est à l'écoute sur un canal unique et lorsque le script inclus reconnaît le nom de la prim, il décode le numéro de couleur et l'affiche sur la prim. La mise à jour se fait une fois par minute. Voici le code couleur retenu :
| 0 = Noir | 5 = Magenta | | 1 = Bleu | 6 = Jaune | | 2 = Vert | 7 = Blanc | | 3 = Cyan | 8 = Orange | | 4 = Rouge | 9 = Violet | Ainsi à l'heure où j'écris cet article, le système affiche : Noir, Orange, Noir, Rouge pour la date et Bleu, Magenta, Bleu, Magenta pour les heures soit 8 avril pour la date et 15 h 15 pour l'heure - l'heure est calée sur le fuseau GMT. Pour synchroniser le tout, une commande scriptée, placée ailleurs sur la sim envoie les signaux à chaque prim. Le résultat est excellent et d'un coup d'oeil, il est possible de décripter la date et l'heure de la mise à jour de la carte de la région de Furvata. ce système a été baptisé ColoCode. En vous rendant à cette adresse - http://slurl.com/secondlife/Furvata/105/180/361 - vous pourrez voir le code couleur et le nom Fuvata composé avec des prims - penchez-vous vers le bas, sans tomber pour autant!  Photo prise le 8 avril (0804) à 15h49 GMT Confortable le poste d'observation, n'est-ce pas? Voilà une manière amusante mais instructive de réfléchir à la carte du viewer de Second Life. Garmin Kawaguichi, planeur temporel
|