Tag Archives: viewer

Second Life Clients für Android: Mobile Grid Client vs. Lumiya

Heute möchte ich mal ein wenig über Second Life Clients unter Android schreiben. Es gibt im Grunde drei Clients heutzutage, nämlich den alten Mobile Grid Client von Kurt Schlager aus Österreich, den Lumiya von Alina Lyvette sowie den LittleSight von Balistoid. Da ich den LittleSight (der auch In-App-Käufe hat) nicht kenne, beschränke ich mich auf die anderen beiden Clients.

Vorweg: gut benutzen kann man beide, es gibt aber auch deutliche Unterschiede zwischen Beiden. Je nachdem, was man benötigt, ist der MGC oder Lumiya eben besser.

Mobile Grid Client
Den Mobile Grid Client gibt es kostenlos im Play Store. Allerdings erhält man damit nur eine Testversion von 14 Tagen, danach ist eine monatliche Gebühr in Form von L$ fällig, die man über den benutzten Avatar zu entrichten hat. Die Standardversion kostet 250 L$/Monat, Premium kostet 450 L$/Monat.

Der Grund dafür ist einfach: der MGC baut keine direkte Verbindung zu Linden Lab und Second Life auf, sondern zu einem Server des Autors vom Client. Dieser Server managed dann den kompletten Datenfluss zu Second Life und zum Client. Die laufenden Kosten werden eben durch diese Gebühren finanziert.

Nun ist die berechtigte Frage: wozu das? Mir sind da zwei Gründe aufgefallen: erstens kommuniziert der MGC bei einer schmalen Datenrate deutlich flotter als der Lumiya, was darauf schließen lässt, dass der Datentransfer hoch optimiert und komprimiert statt findet. Zweitens steckt der MGC es auch locker weg, wenn mal beim Übertritt von einer Funkzelle in die andere die Verbindung nicht wieder sofort da ist, er liefert die fehlenden Daten dann einfach nach.

Dazu beherrscht er die üblichen Funktionen wie Darstellung der Map, Teleport des Avatars, IMs und Gruppen-IMs, Profile anzeigen etc.pp. Es handelt sich bei allem aber um einen reinen Textviewer, mehr kann er also nicht.

Lumiya
Der Lumiya kostet einmalig im Playstore 2,46 € und verursacht danach keine weiteren, laufenden Kosten.

Im Gegensatz zu MGC baut er eine direkte Verbindung zu Second Life auf und damit verhält er sich bei schmalbandigen Datenraten deutlich langsamer. Auch steckt er gelegentliche Aussetzer der Verbindung schlechter weg als der MGC.

Wer also viel in Bewegung ist und wert darauf legt, ständig eine stabile Verbindung zu haben, der ist mit dem MGC ziemlich sicher besser bedient.

Dafür kann der Lumiya eine Sache, die sonst kein Client unter Android kann, nämlich die 3D-Darstellung der jeweiligen Sim. Das benötigt natürlich deutlich Daten und sollte man am Besten nur dort machen, wo WLAN verfügbar ist, ansonsten ist die Datenflatrate des Mobilfunkanbieters sehr schnell aufgebraucht.

Man kann dabei keine Bildwiederholfrequenzen wie bei einem stationärem Computer erwarten, aber die Darstellung ist dennoch recht gut und man kann den Avatar zusätzlich auch noch bewegen.

Damit ist der Lumiya ein recht brauchbarer Client für Couch Potatoes mit einem Tablet auf dem Sofa.

Die üblichen Grundfunktionen, also Teleport, Map, IMs, Gruppen IMs, Bezahlfunktionen usw. sind auch alle vorhanden.

CDN und was es bedeutet

Second Life bekommt aktuell Unterstützung für CDNs, also Content Delivery Networks, eingebaut. Aktuell gibt es einen Projektviewer dazu und rund 28 Regionen auf dem Mainland, die das unterstützen.

Das Problem daran ist nur: viele können sich unter einem CDN absolut nichts vorstellen, aber sie benutzen es täglich. Was also ist ein CDN und warum ist es gut?

Ein CDN ist, wie der Name schon sagt, ein Netzwerk, das Inhalte verteilt. Nehmen wir mal an, ín meiner Gegend gibt es zwei ALDI-Filialen, die eine ist drei Kilometer von mir entfernt und die andere zehn. Nehmen wir weiter an, ich als ökonomisch handelnder Mensch kaufe immer dasselbe Toilettenpapier bei ALDI, das es in jeder Filiale als Eigenmarke vorrätig gibt. Wohin werde ich natürlich fahren? Richtig: zu der Filiale, die näher an meinem Wohnort ist, denn das Angebot in dem Fall ist ja in allen ALDI-Filialen gleich und es gibt für mich absolut keinen vernünftigen Grund, in die weiter entfernte Filiale zu fahren.

Und genau das ist das Prinzip eines CDNs, nämlich die Inhalte eines Diensteanbieters geographisch (!) gesehen wirklich so nahe als möglich an den Abrufer zu bringen. Das geschieht dabei völlig automatisch, transparent und der Benutzer kriegt davon nichts mit. Der CDN-Anbieter muss dafür eine globale Infrastruktur betreiben.

Wie funktioniert das? Nun, in Second Life wird es für Meshes und Texturen freigeschaltet werden. Bekannte Anbieter von CDNs sind beispielsweise Akamai oder Amazon. Wenn ich also in Zukunft als Deutscher eine Textur runter laden will, dann geht diese Anfrage auf CDN-aktiven Regionen nicht mehr direkt an die Rechenzentren von Linden Lab in den USA, sondern an einen Server des CDN-Anbieters, der irgendwo in Europa steht. Der prüft dann zunächst, ob diese Textur schon lokal vorhanden ist, und wenn ja, dann schickt er mir diese direkt, was in einer deutlich besseren Ladezeit resultiert (das ist einfacher Physik und der Übertragungsgeschwindigkeit geschuldet, sprich man hat eine bessere Pingzeit). Wenn die Textur bisher nicht vorhanden ist, dann fordert er diese beim Stammserver an und hält sie danach für weitere Deutsche für eine gewisse Zeit vor.

Das ist alles. Dadurch haben wir dann in Zukunft eine Entkoppelung des Ladens von Texturen und Meshes von der Infrastruktur Linden Labs in den USA, weil das hauptsächlich über das CDN passieren wird. Als Ergebnis wird man eine spürbare Beschleunigung der Ladezeit von oft bzw. oft wiederholt besuchten Sims feststellen können. Wie hoch, das wird sich zeigen .

Zu beachten dabei ist allerdings, dass nach wie vor die Regionserver in den USA stehen und damit die Avatarpositionsberechnung, Physik usw. ausschließlich über dort geschehen wird.

The new kid on the block

Es gibt mal wieder einen neuen Second Life Viewer, mit dem keiner rechnete, namens Replex. Dahinter steckt Latif Khalifa, seinerseits absolut kein Unbekannter, sondern der Autor vom Radegast-Client und einigen anderen Sachen.

Replex kommt einem dabei von Anhieb seltsam bekannt vor, und das ist kein Wunder, handelt es sich doch schließlich bei diesem 1er-Viewer um einen Fork vom Singularity Viewer. Replex basiert dabei auf dem letzten Alphacode von Singularity, enthält aber einen Haufen an Verbesserungen im Vergleich zu Singularity 1.8.5. Allerdings stammt die Mehrheit davon vom Singularity-Team selber, der bisherige Beitrag von Latif Khalifa liest sich dann doch recht bescheiden:

  • Added Replex skin (Latif)
  • Bundle Replex, Gemini and Silver skins (Latif)
  • Windows 64 viewer now supports parcel media (QuickTime) (Latif)
  • gtp chatbar command now allows omitting height. (Latif)

Im Grunde ist also Replex eine leicht veränderte Version des aktuellen Singularity-Alpha-Codes plus einigen, wenigen Änderungen von Latif Khalifa.

Da stellt sich dann die Frage: warum hat der Kerle das gemacht? Einer der Singularity-Entwickler beschreibt das so:

Replex is by no means the successor, it's just something done because someone has no confidence that we can get our alpha build system up.

Also in seinen Augen ist der Grund, dass Latif einfach kein Vertrauen darin habe, dass das Singularity-Team seine neue Build-Infrastruktur zum Laufen bekommen würde und daher selber was gebaut und nichts anderes.

Latif Khalifa selber schreibt zu seiner Motivation auf seiner Seite nichts dazu. Es bleibt also abzuwarten, ob er wirklich die Energie hat, Replex weiter zu entwickeln oder Replex bald wieder, wie viele andere Viewer vorher auch schon, von der Bildfläche verschwinden wird.

Leap Motion in Aktion

Bei all dem Gerede über Oculus Rift ist mir bisher eine Technologie weniger aufgefallen, die einfacher einzusetzen ist und auch die Handhabung eines Rechners ordentlich auf den Kopf stellt, nämlich Leap Motion.

Nun, was ist das? Einige mögen vielleicht Kinect von der Xbox kennen, eine Sensorphalanx, mit der man seine Xbox einfach per Körperbewegungen steuern kann. Nun stellen wir uns mal diese Sensoren ordentlich verkleinert und in einer Computertastatur eingebaut, dann haben wir Leap Motion. Es ist im Grunde der Computersteuerung sehr ähnlich, die manche im Scifi-Film "Minority Report" sahen, nur mit dem Unterschied, dass man dazu keine Handschuhe anziehen muss und die Technik bereits heute verfügbar ist und gerade damit angefangen wird, sie in manchen Notebooks serienmäßig einzubauen.

Ein Video sagt mehr als tausend Worte, und es gibt schon seit über einem Jahr im Second Life Viewer von Linden Lab eine eingebaute Unterstützung für Leap Motion. So sieht das dann eben aus:

Ich kann mir vorstellen, dies ist für Leute, die hauptsächlich gerne per Voice unterwegs sind, sehr praktisch.

Man kann den Controller auch einzeln kaufen, er wird dann per USB an den Rechner gesteckt und ist in etwa so groß wie ein Feuerzeug. Windows steuern kann man damit übrigens auch:

Die Beschleunigung des Viewer-Caches

Eines der Nadelöhre in der Architektur jedes Second Life Viewers ist sein Cache auf der Festplatte. In dem Cache legt der Viewer sowohl die dargestellten Texturen als auch der Objekte einer Sim ab. Klingt erst einmal nicht dramatisch, aber das hat seine Konsequenzen, die in der Natur der Festplatte liegen.

Nun ist es so, dass die meisten Texturen abgelegt auf der Festplatte für sich alleine nicht viel Speicherplatz benötigen. Ein typischer Cache-Ordner besteht aus 10000-30000 Dateien. Es sind eben pro Sim schon sehr viele Texturen, die ihren Weg auf die Festplatte finden, und damit greift dann letzten Endes die Festplatte als Nadelöhr.

Jedes moderne Betriebssystem ist sich der Tatsache, dass der Zugriff auf die Festplatte um Längen langsamer als auf den Hauptspeicher ist, bewusst. Deswegen nutzt jedes Betriebssystem automatisch den nicht durch Programme genutzten Teil des Hauptspeichers als Schreib-Lese-Cache. Das bedeutet, dass Schreibzugriffe auf die Festplatte zeitverzögert stattfinden und vorher noch vom System optimiert werden, sowie oft benötigte Dateien möglichst lange im Hauptspeicher gehalten werden. Fordert ein Programm eine solche Datei an, dann wird erst geschaut, ob sie im Cache vorliegt und wenn ja (das nennt man dann einen Hit), wird sie direkt aus dem Cache geliefert und nicht von der Festplatte gelesen. So weit, so gut.

Was aber passiert, wenn wir den Rechner gerade erst gestartet haben, dabei noch nicht in Second Life waren und einen recht gut gefüllten Viewercache haben? Dann bleibt dem System nichts anderes übrig, als alle diese Texturen nacheinander von der Festplatte zu lesen. Und da dies schon auf einer normalen Sim, auf der man sich bewegt und ein normales Blickfeld hat, durchaus mehrere Hundert Stück sein können, dauert das dann eine Weile.

Wieso kommt dies so? Ganz einfach daher, weil hier nun die mechanischen Beschränkungen einer Festplatte greifen. Die Leistungsfähigkeit einer modernen Festplatte wird an zwei Kennziffern gemessen, nämlich der maximale Schreib-/Lesedurchsatz sowie die Zugriffszeit. Die Zugriffszeit ist dabei der Zeitraum, den die Festplatte im Schnitt benötigt, um den Schreib-Lese-Kopf auf den Anfang der gewünschten Datei zu positionieren. Diesen Vorgang nennt man übrigens auch Seek. Typischerweise wird diese Zeit in Millisekunden gemessen, und eine moderne Festplatte hat eine Zugriffszeit im Bereich von irgendwo 5-10 ms. Dabei gilt natürlich die Devise: je niedriger die Zugriffszeit, desto besser. Eine gewisse Zugriffszeit aber wird man mit Festplatten niemals unterschreiten können.

So. Was bedeutet das? Wenn wir neu einloggen auf irgendeine Sim, dann will der Viewer aus einem gut gefüllten Cache einen Haufen an Texturen von der Festplatte lesen. Das bedeutet, dass es innerhalb kurzer Zeit zu einem Haufen an Seeks kommt, die die Festplatte abarbeiten muss.

Und hier nun eine einfache Rechnung: wieviel Seeks pro Sekunde schafft eine Festplatte maximal? 1 Sekunde sind 1000 Millisekunden, also meinetwegen 1000 ms / 8 ms = 125 Seeks/Sekunde. A-ha, damit kommen wir der Sache dann nämlich schon näher. Und sollte die Festplatte meinetwegen 6 ms Zugriffszeit haben, dann kommen wir da auf 1000 ms / 6 ms = 167 Seeks/Sekunde, was auch nicht wirklich besser ist.

Wenn wir uns dann noch klar machen, dass die Festplatte meist nicht nur von Second Life alleine benutzt wird, sondern zeitgleich auch andere Programme sie benutzen, dann wird einem klar, dass der Viewer längst nicht immer die theoretisch maximal mögliche Anzahl an Seeks pro Sekunde für sich alleine zur Verfügung haben wird.

Mit anderen Worten: die Festplatte ist in der Regel für den Anwendungsfall gut gefüllter Cache, neu gestartetes System und man loggt mit dem Viewer gerade ein, das Nadelöhr. Der Prozessor könnte mehr leisten, aber er kann es eben nicht, weil er auf die Festplatte warten muss und das ist schlecht.

Wenn man den Viewer-Cache für den obigen Fallo also beschleunigen will, dann muss man dafür sorgen, dass die Anzahl an Seeks pro Sekunde erhöht wird. Klingt einfach und ist es auch eigentlich, denn man könnte ja anstelle einer Festplatte eine billige Solid State Disk (SSD) im Rechner einbauen und den Viewercache darauf speichern. SSDs sind für solche Anwendungsfälle, also Ordnerstrukturen mit tausenden, kleinen Dateien, gerade zu ideal. Eine SSD hat keinerlei bewegliche Teile und ihre Zugriffszeit ist in der Regel um den Faktor 100 besser als einer Festplatte.

Die Zugriffszeit einer SSD beim Lesen liegt so im Bereich von 0,05 bis 0,08 Millisekunden. Einfache Rechnung also: 1000 ms / 0,07 ms = 14285 Seeks/Sekunden. Und selbst günstige SSDs sind nur unwesentlich langsamer. Das bedeutet klar, dass eine SSD ganz einfach das Speichermedium der Wahl für solche Anwendungsfälle ist.

Wenn man aber keine SSD hat oder erwerben will, dann kann man dennoch seinen Rechner beschleunigen. Voraussetzung dafür ist, dass man mindestens zwei Festplatten im Rechner installiert hat. Moderne Betriebssyssteme haben die Möglichkeit, zwei Festplatten oder zwei gleich große Partitionen auf zwei verschiedenen Festplatten zu einem sog. Stripe-Set  zusammenzufassen. Die Anwendung sieht nur ein Laufwerk in der Größe der beiden Partitionen zusammengerechnet, in Wirklichkeit aber handelt es sich dabei um diese beiden Festplatten, die das Betriebssystem als eine ansteuert.

Dabei verteilt das Betriebssystem nun Schreib-/Lesezugriffe möglichst gleich zwischen beiden Festplatten, ebenso die Dateien. Dies hat den Vorteil, dass ein Stripeset umso schneller wird, auf je mehr Festplatten es angelegt ist, denn die Zahl der Seeks pro Festplatte addiert sich (d.h. ein Set auf zwei Platten erreicht theoretisch bei 8 ms Zugriffszeit je Platte eben maximal 125 * 2 = 250 Seeks/s, bei 3 Platten 125 * 3 = 375 Seeks/s usw.), allerdings bietet es absolut keine Sicherheit für die darauf befindlichen Dateien. Geht eine Platte kaputt, dann ist das komplette Set unbrauchbar.

Das aber macht im Falle des Viewercaches absolut nichts aus, da dies ohnehin nur ein temporärer Zwischenspeicher ist, der jederzeit erneuert werden kann. Sollte man also beispielsweise unter Windows mehr als eine Festplatte im Rechner verbaut haben, dann kann sich der Aufbau eines Stripesets für den Viewercache durchaus lohnen, denn es bringt einem ohne Mehrkosten einen spürbaren Leistungsgewinn.

Eine Anleitung, wie man unter Windows 7 solch eine Konfiguration aufbaut, findet sich hier. Dabei ist wie immer zu beachten, dass man besser weiß, was man tut, denn man arbeitet an der Festplattenpartitionierung und ein falscher Handgriff kann da schlimmstenfalls Datenverlust nach sich ziehen. Also Vorsicht.

Firestorm Viewer Private Build Nr. 4.5.2.39868 zum Download verfügbar

Mir ist gerade ein wenig langweilig und daher dachte ich mir, ich könnte ja mal der Community einen möglicherweise kleinen Dienst erweisen - und das mache ich nun.

Ohne weiteren Umschweife: ab sofort biete ich nun einen sog. aktuellen Nightly Build vom Firestorm für Windows (32 bit) zum Download an. Nun wo das raus ist, der Reihe nach.

F: Was ist ein Nightly Build?
A: Ein Nightly Build ist eine möglicherweise lauffähige Version des Firestorm Viewers, die auf dem aktuellen Sourcecoderepository des Entwicklersteams beruht.

F: Auf welchem Quellcode basiert dieser Viewer?
A: Er basiert auf dem unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ öffentlich verfügbaren Code. Er wurde mit Hilfe von Microsoft Visual C++ Express 2010 kompiliert und es handelt sich dabei um die 32bit-Variante des Viewers.

F: Gibt das Firestormteam nicht selber Nightly Builds heraus?
A: Nein, das haben sie noch nie.

F: Warum bietet das Firestormteam nicht selber einen Nightly Build zum Download an? Andere Viewer, wie beispielsweise Singularity, machen das doch auch!
A: Es ist keine Frage des Könnens, sondern des Wollens. Das Entwicklerteam vom Firestormteam will keine solchen Builds veröffentlichen. Wer es genau wissen will, der kann es unter http://modemworld.wordpress.com/2013/02/19/firestorm-meeting-13th-february-2013-video-and-transcript/7/ auf Englisch nachlesen. Jessica Lyon begründet es mit mangelnder Qualitätskontrolle. Nightly Builds sind das, was man auf Englisch als das Bleeding Edge bezeichnet. Es handelt sich dabei von der Qualität her nicht einmal um Alphaversionen. Ein Nightly Build kann funktionieren, muss aber nicht, und keiner wird garantieren, dass alle Funktionen richtig oder fehlerfrei funktionieren und man muss schlimmstenfalls auch mit Fehlern rechnen, die Datenverlust nach sich ziehen könnten.

Wer einen Nightly Build benutzt, der muss sich dieser Gefahr sicher sein, dass er auf eigenes Risiko handelt und keinerlei Support bekommen wird. Offensichtlich gehen die Firestormentwickler davon aus, dass die Benutzer dazu einfach in der Masse unfähig sind und daher veröffentlichen sie keine Nightly Builds.

F: Warum veröffentlichst du dann einen Nightly Build, wenn die Firestormentwickler selbst es nicht tun?
A: Weil ich es kann! Und weil das letzte Release von Firestorm von Oktober 2013 ist, und - seien wir da mal ehrlich - einfach nur schnarchlangsam rezzed. Ich persönlich benutze den Bleeding Edge selbst schon seit einiger Zeit und bin der Meinung, die bald vier Monate seit dem letzten Release machen sich durchaus bemerkbar.

Außerdem bin ich der Meinung, dass es ein Fehler des Firestormprojektes ist, bewusst keine Nightly Builds zur Verfügung zu stellen. Andere Viewer fahren sehr gut damit, und getreu dem Motto "Release early, release often" stelle ich nun diese Kompilate zur Nutzung auf eigene Gefahr hin der Allgemeinheit zur Verfügung, weil einfach nicht jeder fähig ist, sich selbest eine Buildumgebung zu bauen und es selbst zu kompilieren. Das füllt damit eine Lücke.

F: Darfst du das denn veröffentlichen? Und was ist, wenn es den Firestormentwicklern nicht gefällt?
A: Ja, sicher darf ich das veröffentlichen. Der Viewer unterliegt einer Opensourcelizenz, der Quellcode ist ebenfalls verfügbar und wenn ich daraus kompilierte Binaries verteilen will, dann kann, darf und werde ich das tun, solange nicht proprietäre Bibliotheken wie von Kakadu mit dabei sind. Und wenn es den Firestormentwicklern mißfällt, dann können sie nicht viel mehr dagegen tun, als ihre Mißbilligung auszudrücken. Denn es ist absolut nichts illegales.

F: Ich vertraue dir nicht!
A: Schön, das musst du auch nicht. Eine gesunde Paranoia ist sogar besser. Nur wenn du mir nicht vertraust, dann benutze auch besser das Programm erst gar nicht, sondern besorge es selber aus einer anderen Quelle oder baue es einfach selber.

F: Mit welchen Einstellungen ist das Programm kompiliert?
A: Es benutzt als Grafikbibliothek OpenJPEG und ist mit Opensimulatorunterstützung kompiliert. Dies entspricht der Autobuild-Konfiguration ReleaseFS_open.

F: Kannst du nicht noch X, Y oder Z ins Programm kompilieren? Kannst du nicht noch X, Y oder Z für mich machen?
A: Nein! Kein Support, keine Unterstützung für Sonderwünsche. Entweder das Programm ist so, wie es vorliegt, für dich brauchbar, oder eben nicht. Ich habe nicht die Zeit dazu, auf solche Wünsche eingehen zu können!

F: Was kann das Ding, was fehlt?
A: Das Ding kann alle Grundfunktionen, die Firestorm eben auch kann. Fehlen tun u.a. fortgeschrittene Baufunktionen, wie beispielsweise Havok. Erwartet alles, nur keinen stabilen Betrieb oder eine vollständige Funktionalität wie im offiziellen Lindenviewer! Dieser Viewer ist eine Baustelle, und das merkt man auch mitunter!

F: Ist es gefahrlos möglich, mit dem Ding auf dem Second Life Grid zu arbeiten?
A: Im Zweifelsfalle: nein. Es handelt sich hierbei um eine Version, die offiziell mit Opensimunterstützung arbeitet und für Opensim gedacht ist. Das bedeutet, dass höchstwahrscheinlich viewerseitige Einschränkungen, die Linden Lab von Second Life Viewern fordert, in dieser Version abgeschaltet sind. Daher rate ich von einer Benutzung des Programms auf dem Second Life Grid ab.

F: Ist das hier nicht dein eigenes Viewerprojekt?
A: Nein. Es wäre mein eigenes Viewerprojekt, wenn ich Änderungen am Code vornehmen würde oder bereits vorgenommen hätte. Das aber habe ich nicht getan. Ich habe einzig und alleine den öffentlich zugänglichen Viewerquellcode unverändert genommen und kompiliert.

Rechtliche Hinweise
Ich biete keinerlei Support! Weder für den Firestormviewer an sich, noch für das kompilierte Programm oder beides. Ich stelle das Kompilat so zur Verfügung, wie es ist, nicht mehr und nicht weniger.. Weder bin ich ein Entwickler noch ein Mitarbeiter des Firestormentwicklerteams, sondern agiere von ihnen unabhängig und damit eigenständig!

Ich weise ausdrücklich darauf hin, dass es sich bei diesem Kompilat um eine Version handelt, deren Qualität noch vor Alpha ist. Das bedeutet, dass das Kompilat unvollständig sein kann, schwere Fehler enthalten kann und schlimmstenfalls Datenverlust nach sich ziehen kann. Ich gebe keinerlei Gewährleistung auf das Kompilat noch hafte ich für mögliche Schäden, die durch seine Nutzung entstehen könnten!

Ich erkläre, dass ich beim Kompilieren ausschließlich die öffentlichen Quellen unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ verwandt habe, und den Code in keinster Weise modifiziert habe. Ich erkläre, dass ich dem Setupprogramm weder Trojaner, Keylogger oder andere Schadprogramme beigefügt habe und es zum Zeitpunkt des Uploads vorher auf Virenbefall überprüft habe.

Weiterhin weise ich ausdrücklich darauf hin, dass es sich hierbei um eine Version handelt, die für Opensimulator gedacht ist! Die Benutzung dieser Version auf dem Second Life Grid kann schlimmstenfalls den Verlust des Zugangs nach sich ziehen!

Kurz und gut: ich übernehme keine Haftung - für gar nichts, weder für Datenverlust, möglichen Schäden an der Hardware noch den möglichen Verlust des Second Life Zugangs oder falls der Viewer deinen Kaffee verschüttet! Die Nutzung des Programms geschieht ausschließlich und ausdrücklich auf eigene Gefahr hin! Wer das Programm nutzt, der ist sich dieser Sache bewusst und erklärt sich damit einverstanden!

Nichts destotrotz freue ich mich natürlich über Kommentare. Und hier geht es zum Download: https://drive.google.com/file/d/0B_BpSLqaUY_dUlBPby0yYk5qVmM/edit?usp=sharing

Ich habe meinen Viewer fertig

Mein Firestorm ist inzwischen fertig und das Ergebnis schnurrt unter Windows so vor sich hin. Er läuft gefühlt um Längen schneller als das letzte Release, allerdings hat er ein übles Memory Leak und ist damit nach einer Weile absolut unbrauchbar, weil er sich wirklich allen Speicher krallen will.

Macht nichts - was nicht ist, das kann ja noch werden. Mal schauen, wie das normale Release mit OpenJPEG anstelle von KDU läuft, das ist als nächstes in der Pipeline.

Firestorm gone bad?

Fredi schreibt bei sich gerade, dass die Benutzung von Firestorm keinen Spaß mehr macht - zu langsam, zu instabil. Mir geht es momentan ähnlich, ich setze daher unter Windows lieber inzwischen den Cool Viewer ein.

Die Frage ist aber: woran liegt das? Dass die Macher von Firestorm durchaus fähig sind, einen flotten und schlanken Viewer zu bauen, sah man ja am alten Phoenix-Viewer. Friede seiner Asche.

Also ist ihnen entweder die Fähigkeit, einen gescheiten Viewer zu programmieren abhanden gekommen, was ich weniger vermute, oder es liegt an anderen Dingen. Wie beispielsweise den vielen, gleichzeitigen Baustellen, die Linden Lab momentan hat.

Diese sind teilweise voneinander abhängig und machen es den Entwicklern schwer, ihren eigenen Viewer auf den aktuellen Stand zu bringen, solange ein Projekt nicht abgeschlossen ist. Für die Lindens ist es natürlich kein Problem, da gute Viewer zu bauen, aber für Projekte mit begrenzter Manpower wird das dann schwierig. Abgesehen davon, man ist der Programmiergott Henri Beauchamp, denn der schafft das Unmögliche und Wunder ganz alleine.

Ich vermute daher, es liegt daher eher ganz einfach an der Vielzahl von Projects, die Linden Lab am Laufen hat, die es den Opensourcentwicklern schwer machen, ihre Viewer auf dem aktuellen Stand der Lindens zu halten. Einerseits schön, dass es sie gibt, andererseits rammt Linden Lab so dieses Ökosystem in den Boden. Ob mit Absicht oder nicht, darüber kann man sicher streiten.

SSA im Selbstversuch

Diese Woche Dienstag hat ja Linden Research endlich nach langer Wartezeit das neue Feature namens "Serverside Appearance" aus dem Projekt Sunshine gridweit ausgerollt. Wer damit nichts anfangen kann: das Aussehen der Haut eines Avatars wird fortan grundsätzlich auf Rechnern von Linden Lab berechnet und nicht mehr, wie bisher, auf dem Client des jeweiligen Benutzers. Wer noch mit einem veralteten Viewer unterwegs sein sollte, der diese Umstellung nicht beherrscht, der sieht nur noch graue Avatare in Second Life.

In der Theorie soll es dazu führen, dass man das Aussehen eines Avatars quasi sofort betrachten kann. Vorher dauerte es ja je nach Region durchaus eine Weile, bis der Avatar gerezzed war, manchmal blieb auch eine Hälfte gar grau, wenn der Upload vom Client nicht klappte. Hält aber diese Theorie der Praxis auch stand?

Um das herauszufinden hilft nur ein Selbstversuch. Also habe ich mir den neuesten Firestormviewer geschnappt und installiert, einen Clean Install gemacht und den Cache geleert. Eingeloggt habe ich dabei auf einer Wassersim und gewartet, bis mein Avatar normal geladen war und dann ging es ab auf äußerst belebte Sims, wo sich sehr viele Avatare gleichzeitig tummeln, denn da kann man nunmal eben genau den Unterschied am Besten begutachten.

Also führte mich mein Weg nach Tempura Island, Sweetheart's Jazz Club, Phatland und einen der Infohubs für Neulinge von Second Life. Und in der Tat hat Linden Research es geschafft, mit SSA genau das zu liefern, was man sich davon in der Theorie davon versprochen hat: das Aussehen eines Avatars ist nun gestochen scharf sofort da, da dauert es auf einmal länger, bis die Haartextur oder Textur der Schuhe geladen ist. Ungewohnt, aber eine deutliche Verbesserung der Second Life Erfahrung.

Genau das sollte es sein, wollte es sein und genau das ist es nun auch. Ich persönlich bin damit äußerst zufrieden. Texture Rebakes eines Avatars dürften damit nun endlich ein für allemal der Vergangenheit angehören. Ein ständiges Ärgernis weniger in Second Life also. Gut so!

Creeping featurism

Bei Linden Research ist die Featuritis ausgebrochen: momentan gibt es so viele unterschiedliche Projektviewer wie schon seit Ewigkeiten nicht mehr.

Einerseits ist das natürlich eine gute Sache, so zeigt es doch, dass man zu technischen Verbesserungen und Innovationen bereit ist und diese auch voran treiben will.

Andererseits aber ist es wiederum schlecht, wenn man zu viele Baustellen gleichzeitig hat und sich so verzettelt. Momentan scheint das bei Second Life der Fall zu sein. Und was noch schlimmer ist, es macht gerade die Arbeit von Entwicklern der alternativen Viewer nicht gerade unbedingt einfacher. Einerseits sollen sie die "shared experience" garantieren, aber wie sollen sie andererseits mit diesem Featuredschungel da noch gerade teilweise mithalten können?

So schön neue Features wie CHUI, SSA, das Materialsystem und weitere (wie der parametrische Meshdeformer) sein mögen, momentan scheint es doch ein wenig zu viel des Guten zu sein. Und so treten sich teilweise gerade alle Arbeiter gegenseitig auf den Füßen herum.