Hello, Avatar!

Second Life et Programmation Créative

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

Hypergrid : la revue de Justincc

Pour compléter le billet de LeoMaxx sur l'Hypergrid avec des informations plus techniques, voici tel quel une revue du fonctionnement de l'hypergrid, brut de décoffrage droit sortie de la mailing list des developpeurs d'OpenSim.

Cool, the patch in http://opensimulator.org/mantis/view.php?id=2640 now builds and passes tests (for what that's worth, currently) against r7391 right now.

Having read Cristina's wiki page and the code, I think the hypergrid is a neat architecture. Essentially, a hypergrid is a confederation of grids. Each user has their own home grid or standalone, which is where their user profile, inventory and assets are stored. When they travel to a different grid via a hyperlink (set up via some funky map and region handle manipulation), the new grid is told the address of that user's home asset and inventory services. Thus

1. If a user rezzes an object from their inventory, the assets for that object are fetched from the home asset service and permanently inserted into the foreign asset service. So when that user goes away or logs off, the assets are still available to be seen by everybody else.

2. If a user copies/takes an object from a foreign grid, then the relevant inventory and asset data gets sent to their own home services.

Please correct me if I'm wrong, Diva.

As I see it, on a conceptual level, some of the pros are:

  • Effectively distributes asset and inventory load over multiple services on multiple grids. This is a really good

alternative to scaling up a central service to internet scale.

  • Allows grids to seamlessly linked to others yet retain control over their own services.

And the cons:

  • Assets are liberally spread around grids. I don't think that this is much of an issue in view of the client hole, but

this is merely my own opinion.

  • Regions must be manually linked and appear in a grid's map. One can't just enter an address in a url bar to go to

another grid, the grid owner must set up the link. As far as I can see this is a limitation of what we have to work with in the client. There may be some arguments for restriction (you don't want someone coming to your pg grid from an adult grid and depositing god knows what).

  • Services need to be exposed to other grids. So malicious grids could possibly fetch and put things they shouldn't. I

think Diva already has some proposals for dealing with this. This may also be another good argument for controlling who can link to you, for now.

I've read the code but I don't intend to actually run it right now - I was more concerned about trying to identify any nasty architectural problems. As far as I can see there is nothing too significant. However, I do see some implementation weaknesses.

1. Assets associated with worn attachments and appearance are not uploaded to a foreign grid from the home grid on teleport in. For other users without cache copies, such avatars will always appear gray and I don't think that any attachments would appear. This is fixable.

2. Prim inventory inspection does not go deep enough. As far as I can see, in the 'asset mapper' you look for contained textures when rezzing an item, but not any other contained assets (including contained objects, clothing, notecards, scripts, etc.). This will result in an incomplete rez. However, this is fixable. Indeed, I've already written all the code required to do this for the OpenSim archiver. If this patch goes in then this should be reused.

3. Better class and method documentation. From what I've seen, what appears to be there at the moment is probably a result of initial copy and paste from existing code. I know this is the pot calling the kettle black to some extent, but I feel that proper class and method documentation is something that we ought to be working towards, to help prevent parts of the code from turning into the private fiefdom of whoever originally wrote it. Also, logging messages are not quite correctly formatted (colons are missing after the <log name> section and copyrights are missing or inconsistent.

4. The code exists in separate Hypergrid packages from all the existing OpenSim packages. This is very understandable due to its origin as a forge module. And I think we can take it as is, but these separate packages should probably go away over time.

Items 1, 2 and 4 could be fixed up after an initial patch goes in. However, I really would like to see more documentation, license fixes and log message uniformity (3). Please could you do this, Cristina?

If this is done then in my opinion the hypergrid facility would be a +1 addition to what is currently in the core. However, I'm not an expert on various areas (map, teleport) so would greatly appreciate another pair of eyes if anyone can spare them. Therefore, if we are to commit this patch I think we should hold off until Monday of next week to give anybody else a chance to look at it.

I'd also quite like to know who intends to support this in the future. It would be a shame if we took it in and then nobody was prepared to keep it going (which I think would mean eventual removal).

Sorry for the long post.



SLTris fonctionne sur OpenSim

C'est une bonne soirée : mon jeu fétiche, SLTris, écrit il y'a plus d'un an fonctionne (enfin) sur un OpenSim.


Il a été rebaptisé pour l'occasion "OSTris" :)

Dans la foulée, je travaille sur une version édulcorée de Bubble Breaker (27 prims...) qui exploitera une nouvelle fonction de LSL, llDetectedTouchFace, qui permet d'obtenir le numéro de la face sur un prim qui vient d'être touché... Malheureusement, cette dernière n'est pas encore implémentée dans les moteurs de scripts d'OpenSim, ce qui ne saurait tarder.

Le saut de l'Ange

Le scripteur Ange Zanetti lance sa propre activité relative aux univers virtuels, et rejoint Jean-Marie dans la grande confrérie des freelances :-)

Comme je le dis dans les commentaires, il y'a un âge ou on ne peut plus prendre de risque, et c'est également le thème d'un des billets de Jeff Atwood, mon idole absolue.


Au programme: formations, conseil, LSL, modélisation... Ange est un excellent technicien (voir le taf sur la biblio...) qui bosse beaucoup plus qu'il ne poste, et on apprécie les gens comme ça.

C'est maintenant qu'il faut se lancer ! Souhaitons à Ange "Xavier" Zanetti une très bonne réussite dans cette entreprise, et n'hésitez pas à aller l'encourager sur son blog !

Commentaires en blocs

Un truc souvent pénible avec LSL, c'est l'impossibilité de définir des blocs de commentaires, comme on le ferait dans à peu près n'importe quel langage traditionnel.

Par exemple, pour commenter un bloc de code, il faut se fader à taper "//" devant chaque ligne. LSLEditor le fait automatiquement, mais pas l'éditeur in-world, et c'est très pénible. On aimerait pouvoir écrire "/*" et "*/" à la fin comme en C#, par exemple, mais bon, on peut pas...

//    integer i = 0;
//    do
//    {
//        integer Idx = llListFindList(NewXYList, llList2List(OldXYList, i, i+1));
//        if (Idx % 2 > 0)
//        {
//            i += 2;
//        }
//        else
//        {
//            OldXYList = llDeleteSubList(OldXYList, i, i+1);
//            NewXYList = llDeleteSubList(NewXYList, Idx, Idx+1);
//            Count -= 2;
//        }
//    }
//    while(i < Count);
//    }

L'astuce que j'utilise est la suivante : j'ajoute "if (false) {" au début du bloc que je ne souhaite pas exécuter, puis "}" à la fin.

if(false) { //*
    integer i = 0;
        integer Idx = llListFindList(NewXYList, llList2List(OldXYList, i, i+1));
        if (Idx % 2 > 0)
            i += 2;
            OldXYList = llDeleteSubList(OldXYList, i, i+1);
            NewXYList = llDeleteSubList(NewXYList, Idx, Idx+1);
            Count -= 2;
    while(i < Count);
} // */

C'est plutôt dégueulasse, mais ça fait son boulot facilement et rapidement :-)

Mono, concrètement


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 !

- page 1 de 29