In den letzten Jahren hat sich immer wieder herausgestellt, dass in schwierigen Phasen in denen andere vielleicht eine Art autogenes Training absolvieren mir es ungeheuer gut tut, bis dahin noch unbehandeltes Terrain abzugehen und zu bereinigen. Dieser etwas seltsam sinnlose Vorgang analytisch betrachtet hat einen sehr beruhigenden Einfluß auf mich und ich kann während dieser Zeit sehr gut innerlich aufräumen. Dass das nicht unbedingt nur mir so geht beweisen die vielen „Planierraupen“ die gebaut wurden, die ich allerdings nicht nutze sondern ich tue es auf klassische Art, sowie die Tatsache dass „mann“ es im allgemeinen als angenehm ansieht mit einem (möglichst fahrbaren) Mäher große Flächen zu „behandeln“, ja ich hatte mal in einer dieser unsäglichen Sendungen in denen Menschen sich gegenseitig irgendwelche Lebensträume erfüllen können die dann publizistisch ausgeschlachtet werden gesehen dass es „die Erfüllung des Lebens“ für jemanden bedeutete einen Fußballrasen mähen zu dürfen. Da haben wir es auf dem Grid doch wesentlich einfacher. 🙂 Hinterher hab ich immer das Gefühl einiges „geglättet“ und bereinigt zu haben. Nun, wie so oft zitiert: Wer heilt hat Recht, oder in diesem Fall leicht abgewandelt: Womit geheilt wird ist richtig. 😉
Monat: Dezember 2010
Wann kommt der browserbasierte Viewer?
Wann kommt ein nutzbarer browserbasierter Viewer für Second Life und Open Sim? Die Grid Gazette berichtete Ende November, dass die Firma Tipodean Technologies am 6. Dezember einen „ordentlichen browserbasierten Viewer“ auf Grundlage der 3D-Engine Unity herausbringe. Seitdem habe ich immer mal wieder auf der Canvas-Seite (Canvas heißt der browserbasierte Viewer) nachgeschaut.
Dort ist in der Tat der 6. Dezember als Release-Date angegeben, allerdings finden sich dort keine Möglichkeiten, das Ding zu nutzen. Nur Screenshots und eine Telefonnummer bzw. E-Mail-Adresse, die man kontaktieren soll, wenn man Interesse daran hat.
Dabei sind die Screenshots durchaus vielversprechend, denn sie zeigen zugleich, was „Canvas“ nicht kann: Man wird den Viewer offenbar zur Kommunikation und Interaktion nutzen können, nicht aber, soweit ich es sehe, zur Erstellungen von Inhalten. Nun, den meisten wird das auch ausreichen, und für den schnellen Besuch zwischendurch könnte solch ein Tool ideal sein.
Beeindruckende Ansichten/Aussichten aus einem anderen Universum
Heute habe ich mir auf meinem Desktop-Rechner zusätzlich zu meinem Windows XP (über das ich (fast) keinen Grund zur Klage habe) Ubuntu installiert. Einmal abgesehen davon, dass diese Prozedur so geschmeidig lief wie’s Katzenmachen – kein Vergleich zu früheren Jahren, wo diverse Hand- und Kopfstände nötig waren, um ein funktionsfähiges Linux auf den eigenen Rechner zu bekommen – wollte ich natürlich auch wissen, ob und wie OpenSim unter Linux läuft. Also flugs den Hippo Viewer für Linux heruntergeladen. Die Installation funktionierte so, wie man es von Windows auch kennt. Er legte den Viewer in einem Unterverzeichnis meines Home-Ordners ab und startete dann anstandslos. Lediglich bei einem zweiten Start musste ich in dem Ordner erst das richtige Script suchen, um den Viewer zu starten – hier könnte Hippo an der Verständlichkeit noch etwas nachbessern (das Startscript könnte ja z.B. „Start-Hippo-Here“ heißen).
Ansonsten bin ich schwer beeindruckt. Mir präsentierte sich auf unserer Sim eine flüssig laufende und schnell aufbauenende Umgebung. Das einzig Störende ist, dass das Antialiasing nicht zu funktionieren scheint. So sehen manche Sachen (z.B. die Fahnenmasten) aus der Ferne ziemlich eckig und kantig aus. Dafür aber läuft die Darstellung gefühlt dreimal so geschmeidig wie unter Windows.
Als nächstes werde ich mal ausprobieren, ob der Hippo-Viewer unter Ubuntu auch in Second Life funktioniert.
Hier ein paar Screenshots, die einen kleinen Eindruck vermitteln, wie sich OpenSim/OSgrid unter Ubuntu anfühlt:
leichtes Chaos (AssetService & Co Pt 2)
Also da ist Vorsicht geboten, wenn an den diversen Services geschraubt wird. Mittlerweile scheint klar zu sein, dass die Client-Abstürze daher rühren, dass ich zwischenzeitlich auf einen lokalen AssetService umgeschaltet hatte und es Unverträglichkeiten gibt nach dem Wiederaufsetzen des GridService. Zwar ist es mir gelungen die Grid.ini so zu erweitern, dass alle Regionen wieder starten konnten (lokaler Asset- und InventoryService, konfiguriert auch in der Grid.ini und nicht nur in der GridCommon.ini) was jedoch dann gegeben war, war eben dieses leichte Chaos: Es war nicht mehr möglich im Inventar Kleiderstücke oder Shapes / Skins anzulegen. Also wieder zurückrudern, alte Config wiederherstellen und hoffen, dass das entstandene Chaos sich auf meine eigenen Dinge beschränkt, was leichter zu ertragen ist 😉
AssetService & Co
Nun, das Bauen schreitet voran. Erste Wege werden angelegt mit schlicht produzierten Fotografien die jedoch schon ganz beachtlich wirken. Gut zu lernen dabei, dass man bei Übergängen gerne mal 1cm die Objekte heben oder senken sollte, damit es nicht zu dem üblichen unangenehmen Flackern kommt.
Etwas weniger Angenehmes ist aber, dass es nach einiger Arbeit stets zum Absturz des Clients kam wenn die Textur gewechselt werden sollte. Vier Versuche reichten aus mit demselben Ergebnis um für jetzt zu sagen: Es reicht ;). Anschließende Kurztests die AssetDB und die InventoryDB lokal zu erzeugen (was ich eh vorhatte, da es mir lieber ist wenn die Dinge auf der eigenen Maschine gespeichert werden; schließlich möchte man auch den GridServer ja nicht überfrachten – was auch genau das Problem gewesen sein könnte) scheiterten, es fehlt wohl etwas, das schlichte Verweisen auf den lokalen Server beim AssetService reicht nicht. Eigentlich klar, denn irgendwo muss ja auch noch der DB-Connector konfiguriert werden. Wo und wie das bei einer OSGrid-Anbindung zu tun ist und ob das überhaupt möglich ist werden wir noch ermitteln. 🙂