Hello, Avatar!

Second Life et Programmation Créative

Aller au contenu | Aller au menu | Aller à la recherche

Mono, concrètement

mono_logo.png

Depuis quelque temps, la main grid autorise les scripts LSL à être compilés en utilisant la technologie Mono.

Super ! On nous promet une vitesse d'exécution multipliée par 200, et c'est tout à fait pertinent. Mais avant de crier au miracle, il faut bien comprendre en quoi consiste Mono, pour se faire une idée plus précise de la sauce à laquelle nos scripts LSL vont être mangés.

C'est quoi Mono ?

Mono n'est pas un nom de code inventé par Linden Labs.
Mono, c'est le confrère libre et open source de la plateforme de développement .NET conçue par... Microsoft, dans le but de concurrencer Java sur le terrain des applications d'entreprises. C'est un peu ce qu'OpenSim est à ce qui tourne sur les serveurs de Second Life. .NET est une technologie fiable et éprouvée qui fait tourner des centaines de milliers d'applications dans le monde, et Mono le devient de plus en plus.

Concrètement, Mono, ça marche comment sur la grille ?

Sans Mono

Les scripts sont éxécutés par une machine virtuelle. Une sorte de gros programme qui analyse les scripts, et déroulent leur éxécution. C'est très lourd, et relativement lent, surtout lorsqu'il y'a beaucoup de scripts. En cas de grosse montée en charge, ajouter plusieurs machines virtuelles et les faire tourner en même temps ne fait que reculer le problème. Les premières générations de programmes en Java tournaient de cette manière.

Imaginons, dans la vie réelle, une sorte de gros androïde chargé de traiter des dossiers dans un bureau. Imaginons que l'androide est une machine virtuelle, que les dossiers à traiter sont des scripts, et le bureau est le serveur. Plus il y'a de dossiers, plus l'androïde aura du mal a les traiter rapidement. Si on rajoute des antroïdes pour répartir le travail, ils risquent de se trouver à l'étroit dans le bureau...

Avec Mono

Les scripts utilisent la technologie Mono, et sont convertis très rapidement dans un langage directement compréhensible par la machine. Plutôt que d'avoir une machine virtuelle monstrueuse, chaque script devient un "vrai" petit programme qui bénéficie directement des possibilités de la machine, sans être en quelque sorte bridés par la machine virtuelle.

Imaginons, dans la vie réelle, le même bureau et les mêmes dossiers. Le gros androïde a été remplacé par un machiniste chargé de piloter une machine de marque Mono. Les dossiers qui arrivent pour être traités, passent dans cette machine, et se transforment alors en tout petits androïdes très légers, taillés et calibrés juste assez pour faire le travail demandé.

A noter que sur OpenSim (écrit en Mono...), il se passe à peu la même chose ! Sauf que les androïdes sont pour le moment un peu plus gros, un poil plus lourds, et surtout, bien moins disciplinés... ;-)

Alors ça va lagger beaucoup moins ?

Pas sûr... Comme expliqué sur SecondWorld, ce n'est pas parce que la vitesse d'execution des scripts est grandement accrue que les informations vont circuler plus vite entre nos viewers et les serveurs de Second Life. Il convient que rappeler que chaque changements d'états in world se traduit par une avalanche de données transmises à chacun des viewers actuellement connectés sur la région. Un changement d'état, c'est un avatar qui bouge, qui parle, un prim qui change de couleur, se déplace, un son, une nouvelle texture... Et à ça, Mono ne pourra rien changer.

En revanche, les avantages de Mono sont immédiatement perceptibles pour :

  • De gros calculs IntraWorld
  • Les listeners, détecteurs, les outils de communications (Requêtes HTTP, XMLRPC...)
  • Une grande quantité de scripts tournant en même temps

Voilà. Bien sûr, dans la réalité, c'est toujours un peu plus compliqué que ça, mais j'espère vous avoir aidé à démystifier Mono sur SL, et à relativiser un peu les promesses faites par les Linden.

Si vous connaissez des ressources par rapport à mono sur SL (optimisations des scripts, limites techniques... etc...), les commentaires sont à vous !

Le Journal Metaverse3D

Merci, Jean-Marie ! ^^

Une belle expérience

thefly.jpgUn test réalisé entre la grille des Linden et un serveur OpenSim fait pas mal de bruit en ce moment dans la blogosphère SL : il se trouve que Zha Ewry a réussi à téléporter deux Lindens sur un serveur OpenSim, les deux parties ayant "bricolé quelque chose" dans le code de leur infrastructures respectives.

Voilà qui semble très prometteur. Non pas techniquement, parce que RealXtend l'a déja fait, mais parce que certains Linden se prêtent volontiers au jeu, on pourrait croire que l'ouverture de la grille promise il y'a des lustres pourrait enfin faire partie des objectifs prochains...

Or, comme le précise Zha Ewry, il est inutile de s'emballer de la sorte : c'est juste un "bricolage". Si des discussions sont déja en cours dans la mailing list d'OpenSim pour interconnecter des grids entre elles, on est encore loin de les relier à la grille des Linden. Sachant d'expérience qu'il est à peu près dix fois plus difficile de faire bouger les personnes que de changer du code, il va falloir une certaine pression de la part de grilles OpenSims déja interconnectées pour qu'elle soient rejointes par celle des Lindens, pour qu'ils ne fassent pas figure d'outsiders comme évoqué dans un billet précédent.

Pourquoi le doute m'habite ? Parce que contrairement à OpenSim ou les discussions sont ouvertes et partagées, il n'y a aucune communication quant à l'avancement des "promesses" faites par les Linden. A moins que quelqu'un dans le "secret des dieux" puisse nous éclairer ?

LiteSim : des morceaux de Python

Comme le disait ici Gareth Nelson, LiteSim, véritable fork du projet OpenSim contient un maximum de code en Python. Un bout de code du Region Server (qui semble être l'équivalent de la partie simulateur d'OpenSim) est disponible au téléchargement, ainsi que quelques patches pour OpenSim et du Viewer SL.

image

Alors ne me demandez pas comment ça marche... Je n'y connaît fichtre rien en Python, mais les (nombreux) amateurs de ce langage devraient apprécier.

Les enfants de Second Life

La première fois que j'ai bricolé avec OpenSim, c'était l'an dernier. Au début de cette année, je prédisais avec enthousiasme que 2008 sera l'année OpenSim. Ou en est on en ce mois d'avril ?

De plus en plus d'alternatives libres et compatibles fleurissent, aussi bien côté client que côté serveur. On est bien au delà de ce que j'espérait :-)

C'est pourquoi j'ai essayé de dresser un panorama de ces alternatives : il n'a pas la prétention d'être exhaustif, mais j'espère qu'il est assez complet.

Ces alternatives n'ont pas pour but de vouloir dérober quoi que ce soit à Linden Labs. Bien au contraire : elles permettent d'asseoir la technologie et les protocoles SL et d'attester leur viabilité dans des environnements aussi divers qu'une machine de bureau ou qu'un serveur, connecté ou non à une grille, sous Linux, sous Windows ou Mac OS.

Et ça, l'ami Rosedale l'a très bien compris :-)

Sans plus attendre, donc, le panorama (cliquez pour agrandir)...

Grilles et Viewers

...et la description : on commence par les Serveurs, ensuite viendront les Clients, puis ce que j'appelerais les Pseudo-Clients (sans aucune connotation péjorative), pour finir par les Bibliothèques.

Les Serveurs

  • Second Life
    Second Life est un ensemble de grilles fournies par Linden Labs. Si le code source du Viewer est disponible, le code des serveurs ne s'ouvre en revanche que petit bout par petit bout. Ceci pour plusieurs raisons (je ne retrouve plus les liens) : "il n'est pas encore prêt", et "il utilise des technologies propriétaires". Mes dernières lectures ne me laissent pas présager un avenir optimiste quant à ce point : il se pourrait bien que certaines portions du code restent propriétaire, mais quelle importance si les protocoles d'échange, eux, sont ouverts ?.
  • OpenSim
    OpenSim, diminutif d'OpenSimulator est la toute première initiative de portage libre de l'infrastructure d'une grille Second Life. Son succès est venu de sa particularité à pouvoir fonctionner en mode "solo". C'est à dire faire tourner un simulateur "hors connexion" sur son PC. Ce qui est bien pratique pour s'entrainer à builder.
    OpenSim est un terrain d'expérimentation encore au stade alpha. Son mode de fonctionnement en mode "grille" n'est pas encore finalisé. Les protocoles sont en évolutions constante, et on n'a pas fini de les décortiquer... C'est donc avec un casque qu'il faudra encore l'employer. Si Second Life est le Web3D, alors OpenSim en sera l'Apache.
  • LiteSim
    LiteSim est un véritable fork d'OpenSim. On en entend pas beaucoup parler car le projet se fait attendre. Il devrait sortir en même temps qu'une offre de grille payante. Son auteur, Gareth Nelson est interviewe ici. Si les promesses de LiteSim sont tenues, ça devrait être énorme.
  • OpenUGAI
    Comme expliqué dans un billet précédent, UGAI est un acronyme désignant tous les types de services nécessaires au bon fonctionnement d'une grille. OpenUGAI est donc un fork un peu spécial vu qu'il ne gère que les services d'une grille, Utilisateurs, Grille, Assets, Inventaire, et pas du tout la partie simulateur. Ecrit en PERL, il peut être hébergé sur un serveur Web (par exemple Apache) pour bénéficier de sa stabilité et de ses possibilités de répartition de charge.

Les Clients

  • Le Client Officiel Second Life
    Appelé également "le Viewer", le client officiel Second Life est disponible en open source et est en constante 'évolution. Ces évolutions sont souvent accompagnées de mises a jour du code serveur et posent beaucoup de problèmes... Ecrit en C++, il est disponible pour Windows, MacOSX et Linux, cette dernière étant en version Beta.
  • RealXtend Viewer
    Il s'agit sans aucun doute du plus impressionnant travail de reprise du Viewer officiel. Destiné à se connecter à un serveur éponyme, RealXtend Viewer offre des possibilités impressionnantes comme des terminaux VNC sur des prims, les primitives à bases de meshes, et la navigation Web sur des prims.
  • OpenViewer
    C'est la première tentative de réécriture "from scratch" du Viewer officiel. Il peut tourner sous Windows, MacOSX et Linux grâce à Mono, qui anime à présent les scripts LSL sur les simulateurs de la grille Second Life. Ecrit à l'aide des mêmes "patterns" qu'OpenSim, son architecture accueille des plug-ins permettant de Switcher sur d'autres moteurs de rendus à la manière de RealXtend.
  • Second Viewer
    On ne sait pas grand chose à propos de cette idée de SecondViewer. Seulement que le projet est monté par des férus des technologies Microsoft, et qu'il est prévu que la version Web de ce dernier serait développé en Silverlight, sinon que la version desktop utiliserait le WPF et le WCF du .NET Framework 3.5.
  • Aether
    A part le site sur google code. Il y'a très peu d'informations sur Aether qui ne semble pour le moment n'être qu'une idée, à l'instar de Second Viewer. En résumé, il s'agirait d'un genre d'AjaxLife, mais qui prendrait en charge la 3D à l'aide d'un plugin dans un navigateur.

Les Pseudos-Clients

Appelés ainsi parce qu'ils n'offrent que des opérations élémentaires comme chatter, et qu'il n'y a aucune visualisation en 3D.

  • AjaxLife
    AjaxLife est un avant goût de ce qu'on peut faire de SL à partir d'un simple navigateur. Une petite merveille écrite par Katarine Berry. On espère qu'AjaxLife intègrera un jour de la 3D, ou bénéficie des avantages d'un plugin RIA comme Flash ou Silverlight.
  • Sleek
    Sleek ressemble à un client chat traditionnel comme mIRC ou HydraIRC, sauf qu'il se permet de se connecter à une grille Second Life pour chatter avec des résidents. Il affiche la friend list, les profils, l'inventaire... et offre d'autres surprises ! SLeek est écrit en C#, il est open source et il utilise LibSL. Tout comme AjaxLife, c'est un client ultraléger, mais il n'est pas hébergé sur un site Web et doit être installé sur votre poste. Ecrit par Delta Czukor, SLeek réserve pas mal d'autres surprises !
  • MovableLife
    Movable Life est un client Web analogue à AjaxLife, en version Alpha.

Librairies et divers

  • LibSL
    C'est de là que tout est parti. Un groupe de développeurs s'est amusé à analyser les échanges de données entre un viewer et un simulateur, et a mis au point une bibliothèque écrite en C# destinée à être employée par des applications souhaitant utiliser Second Life. LibSL est né. OpenSim, LiteSim, AjaxLife et Sleek utilisent LibSL.
  • AfterLife
    Ce projet assez curieux est un proxy permettant à plusieurs clients à la fois d'être représentés par un seul avatar sur un sim. Une tentative pour accroitre le nombre d'assistants à une conférence sur un sim, en utilisant la même technique qu'un serveur de stream dédié pour réduire le lag.

Voilà. Nombreux sont les moyens libres de se connecter ou d'héberger un petit monde compatible avec Second Life. Si vous en connaissez d'autres, les commentaires sont à vous :-)

- page 1 de 5