Ab Mittwoch den 8. September 2010, 19:00 Uhr unserer Zeit, wird Linden Lab den Zugriff aller Emerald-Viewer auf das Second Life Grid sperren. Dies war bereits seit einiger Zeit absehbar und ist kein Beinbruch, da für alle Emerald-Liebhaber mit dem Phoenix Viewer ein würdiger Nachfolger bereit steht, der sogar im TPVD gelistet ist.
Linden Lab ließ es sich nicht nehmen, jeden Benutzer davon sogar per Email in Kenntnis zu setzen. Naja, es ist das Ende eines Projekts, das durchaus seine Spuren hinterlassen hat, aber von Leuten betrieben wurde, die ihrer Verantwortung teilweise nur bedingt dauerhaft gerecht wurden.
Eines der Hauptgesprächsthemen und Hauptärgernisse in Second Life überhaupt ist der mehr oder minder ständig anwesende Lag. Es gibt kaum ein Thema, um das sich so viele Mythen und Legenden ranken wie dieses, wo es selbst technisch versierten Mitmenschen schwer fällt, alleine die Fakten zu betrachten und viele regelmäßig stolz mit ihrem Halbwissen meinen glänzen zu müssen. Also stellen wir uns die scheinbar einfache Frage: was ist Lag genau und was kann man dagegen machen?
Lag wortwörtlich betrachtet
Lag kommt aus dem Englischen und bedeutet wörtlich ins Deutsche übersetzt so viel wie Verzögerung, Rückstand oder Nachhinken. Es geht also darum, dass etwas nicht so schnell verarbeitet wird, wie es verarbeitet werden sollte und sich daher spürbar langsamer als normal anfühlt. Der Begriff „Lag“ kommt dabei ursprünglich aus dem Bereich der Netzwerke und bezeichnet dort eine besonders hohe Latenzzeit, streng genommen kann er auch nur da entstehen. In Second Life wird er aber auch häufig für Effekte gebraucht, für die alleine der Viewer verantwortlich ist. Pedanten klamüsern diese Begrifflichkeiten dann gerne auseinander, im Rahmen dieses Artikels aber verwenden wir der Einfachheit halber und weil es sich bereits so eingebürgert hat den Begriff „Lag“ für Beides.
Lag zuerst rein physikalisch auf der Netzwerkebene betrachtet
Schauen wir uns zuerst einmal die Netzwerkebene und deren physikalische Grundlagen an. Die Physik spielt dabei eine wichtigere Rolle, als man zuerst annehmen mag.
Die wichtigste physikalische Konstante für alle Verbindungen zu Second Life ist dabei die Lichtgeschwindigkeit c, die vereinfacht ausgedrückt bei ca. 300.000 km/s liegt. Angenommen, es sitzt nun jemand in Frankfurt/Main, er baut eine Verbindung zu Second Life auf und landet im Rechenzentrum in San Franzisco. Die Entfernung Luftlinie nach San Francisco beträgt dabei etwa 9140 km, gehen wir mal von 10.000 km aus, da die Kabel sicher länger sein dürften als die reine Luftlinie.
Wie lange braucht es nun, bis eine Eingabe im günstigsten Fall von Hamburg nach San Francisco gelangt ist? Einfach, man rechne: 10.000 km / 300.000 km/s = 0,033 s. So weit der Wert der Theorie, da auf dem Weg noch mehrere Router liegen, die dem Ganzen zusätzliche Latenz hinzufügen, dürfte ein realistischer Wert irgendwo bei 0,04 bis 0,05 Sekunden liegen. Damit ist also die Information angekommen, wird im Simulator verarbeitet und geht danach wieder auf den Rückweg. Das bedeutet, in der Praxis haben wir bestenfalls irgendwelche um die 0,1 Sekunden oder 100 Millisekunden.
Diese Zeit misst man mit Hilfe des Befehlesping. Wenn es auf dem Weg zu Second Life irgendwo im Netzwerk einen Stau geben sollte, dann macht sich das folgerichtig in höheren Zeiten als normalerweise erwartet bemerkbar.
Auftritt: Server Side Lag und Client Side Lag
Soweit der kleine, netzwerktechnische Exkurs und was Lag im eigentlichen Sinne ist. In Second Life selber wird zwischen zwei Arten von Lag unterschieden, nämlich dem
Server Side Lag sowie dem
Client Side Lag.
Also einerseits der Lag der aus diversen Gründen auf dem Server entsteht und dem Lag, der sich alleine auf dem eigenen Computer bemerkbar macht. Gegen Server Side Lag kann man dabei nur bedingt etwas tun, während man den Client Side Lag natürlich weitgehend in den Griff bekommen kann. Schauen wir uns also mal beide Bereiche genauer an!
Es ist mal wieder die Zeit des Jahres, in der alle namhaften Designer in Second Life ihre neuesten Haarkreationen auf über vier Sims ausstellen. Das bedeutet auf vier Sims ständig mindestens je Sim 40 Avatare und Laghölle pur. Das ist dabei auch wieder einmal die Zeit des Jahres, in der man sich stark der technischen Grenzen von Second Life bewusst wird und die Mythen von Second Life wiederkehren, wodurch alles Lag entsteht.
Wieder mal typisch dabei ist auch die Bitte, alles Mögliche an Prims und HUDs vom Avatar abzunehmen und nur quasi „nackt“ zu erscheinen. Es zeigt immer noch, dass da viele nicht verstanden haben, was Lag ist und was nicht, wodurch er entsteht und wodurch nicht. Obwohl ich sagen muss, ich war vorhin auf den Sims gewesen, diese sind bereits so weit als möglich optimal gegen Lag gebaut worden.
Auch immer und immer wieder kommen dabei die Leute auf, die geradezu zwanghaft die ARC eines Avatars betrachten und einen dann anpampen, wenn diese in deren Augen viel zu hoch ist. Was soll man denen sagen? Es ihnen jedes Mal erklären, dass die ARC ein Maß für die clientseitige Last der Grafikkarte ist? Meist kommt diese Botschaft bei diesen Leuten erst gar nicht an, ebenso wenig wie die Erkenntnis, dass sie das selber in der Hand haben – kauft euch einfach eine bessere Grafikkarte und fertig, die kosten auch längst nicht mehr die Welt!
Denn was ist der Sinn in einem Modeevent, wenn man da nicht zeigen darf, wie modisch der eigene Avatar aussehen kann?
Aber so gilt: the same procedure as last year? The same procedure as every year!
Der Phoenix-Viewer nutzt wegen der Auflagen von Linden Lab keine Emkdu.DLL mehr und kommt mit OpenJPEG 1.3.0 als dafür zuständige Bibliothek daher. Das macht sich im Vergleich zum alten Emerald in einem langsameren Rezzen der Texturen bemerkbar.
Nun ist Phoenix dergestalt umgebaut worden, dass er das Rezzen nur noch mittels OpenJPEG vornimmt, auch wenn LLkdu vorliegen sollte, und sonst gar nicht. Das war eine der alten Forderungen von Seiten Linden Labs an die Emerald Entwickler, ich habe es mit allen möglichen LLkdus probiert, es funktioniert nicht.
Nun kann man mit einem kleinen Trick Phoenix dennoch zu schnelleren Rezzingzeiten überreden. Die Version 1.3.0 von OpenJPEG nämlich ist nicht mehr aktuell und Imprudence kommt mit der deutlich schneller arbeitenden Version 1.4.0.565 daher.
Also lädt man unter Windows sich einfach zuerst Imprudence herunter (z.B. die 1.3.0 RC2) und installiert diesen. Aus dem Programmverzeichnis von Imprudence kopiert man dann die Datei OPENJPEG.DLL in das Programmverzeichnis vom Phoenix-Viewer und startet diesen danach.
Wenn alles geklappt hat, dann sieht man im Menü „Hilfe“ unter „Über Phoenix Viewer“ folgendes, wichtig ist dabei der farbig eingekastete Bereich:
In dem muss als Runtime „1.4.0.565“ stehen, damit nutzt nun Phoenix Viewer die neuere Bibliothek und sollte schneller arbeiten.
Das Hauptziel des Emerald-Viewers ist die Weiterentwicklung der bereits vorhandenen Codebasis vom alten Emerald unter Einhaltung von hundertprozentiger Transparenz. Jeder Arbeitsschritt soll von außen kontrollierbar sein, es gibt bereits jetzt einen IRC-Channel der Entwickler, ein öffenliches Quellcoderepository, und und und… Zudem hat man bereits die Aufnahme im Third Party Viewer Directory beantragt und rechnet damit, dass dies eine rein Formsache sei, da keine historisch belasteten Entwickler mehr mit an Bord seien.
Unter den Entwicklern ist der bekannte LordGregGreg Back zurück und Kitty Barnett, von der die RLV(a)-Implementierung stammt. Auch ansonsten ist man personell sehr gut bestückt, man darf gespannt sein, welches Leben diesem Projekt in der Zukunft beschert sein wird, es liest sich wie all die guten Sachen von Emerald minus dem unnötigen Drama.
Hoffentlich haben die Entwickler dabei ihre Lektionen gelernt!
