Blogs als RP-Verhinderungsmaschinen

Bei mir ist heute das Blog „ganzweisserschwan“ aus der Blogroll rausgeflogen. Nicht, weil es nicht mehr gepflegt werden würde und es damit keine aktuellen Inhalte mehr gibt, im Gegenteil, sondern gerade wegen der aktuellen Inhalte und wegen der Art und Weise der Präsentation! Es gibt gewisse Sachen, auf die ich persönlich nicht weiter verlinken will noch verlinken muss, dieses Blog gehört für mich ab sofort mit dazu.

Der Grund liegt im Posting „Wirtshaussklavin vs. Exotin“, und da dort auch weiterhin in Zukunft ähnliche Kracher auf teilweise derbstem Gossenniveau zu erwarten sind, in dem Rollenspieler aufs übelste beleidigt und samt Namen an den Pranger gestellt werden, weigere ich mich, noch weiterhin nach dort zu verlinken und somit für zusätzliche Awareness betreffs dieses Blogs zu sorgen.

Das Blog ist für mich ab sofort Geschichte und wird hier nach diesem Post von mir hier nicht mehr erwähnt werden.

WTF: die Latexburka!

Geneigter Leser, diese wundervolle Geschmacksverirrung kann zum Schleuderpreis von 850 L$ DIR gehören!

Da spaziere ich gut gelaunt über eine Clubsim, auf einmal packt mich da das kalte Entsetzen, denn was müssen da meine entzündeten Augen sehen? Eine schlampig aussehend gearbeitete Burka aus Latex, erhältlich in Schwarz und Rot! Dieses Juwel des handwerklichen Nähens mit der viel zu heißen Nadel kann für nur lumpige 850 Lindendollar dir gehören, ja genau, DIR!

Also Leute, kauft es und rennt damit herum, dass die Schwarte kracht, denn eine Demo gibt es leider nicht, aber dieses wunderschön gearbeitete Foto alleine ist doch sicherlich für uns alle mehr als Anreiz genug, das haben zu wollen! Vielleicht kann man es ja noch für Rollenspiele zweckentfremden, aber – besser nicht!

Meshupload mit Drittviewern

Meshes sind ja nun langsam dabei, sich im Grid auszubreiten und werden mehr und mehr Standard werden, einfach weil sie massive Vorteile haben, auch wenn sie sicherlich noch mit einigen Problemchen behaftet sind. Wer mit veralteten Viewern wie Phoenix sich Meshes am Avatar anschaut, der sieht beispielsweise statt einer Hose nur einen Mann ohne Unterleib mit einer komischen Kugel. Aber ich bin mir sicher, da der Druck nun vorhanden ist, wird eine Vielzahl an Benutzern sehr schnell Viewer bei sich installieren wollen, die Meshes darstellen können.

Bisher gibt es folgende Viewer, die Meshes darstellen können:

Weiterhin wird die nächste Version des Firestorm-Viewers Mesh offiziell unterstützen, dazu kommt noch bereits angekündigt der Singularity Viewer. Alles in allem sieht es gar nicht so schlecht aus, die Vielfalt des Viewerzoos wird erhalten bleiben und läuft Mesh in einem der 1.xer-Viewer erstmal gut genug, werden sicherlich auch andere bereitwillig den Code bei sich einbauen und übernehmen.

Nun ist die Darstellung von Mesh eine Sache, das Uploaden von Meshes aber leider eine andere. Wer selber Meshes erstellen will, der ist auf den Viewer der Lindens oder Kirstens Viewer angewiesen. Alle anderen Viewer können zwar Mesh bisher darstellen, aber noch nicht wirklich erstellen.

Woher kommt das? Nun, ein Mesh ist ja zuerst einmal ein sichtbares 3D-Polygonnetz. Damit es aber in SL auch vernünftig einsetzbar ist, gehört dazu auch eine entsprechende, unsichtbare Hülle für die Physik, schließlich will man ein Haus zwar betreten können, aber nicht durch die Wände hindurchlaufen. Die Physik-Hülle nun kann man entweder im Tool seiner Wahl mehr oder minder selber generieren oder den Viewer die Arbeit übernehmen lassen. Dazu hat Linden Lab eine neue Programmbibliothek mit dem schönen Namen llconvexdecomposition erschaffen, die nichts anderes als ein sog. Wrapper um die Havok-Library ist. Havok selber ist aber kein Opensource, sondern kostet richtig Geld. Für Linden Lab ist das kein Problem, da sie ja Havok einsetzen, für Linden Lab funktioniert diese Bibliothek, aber da man zum Bauen von llconvexdecomposition Havok braucht, funktioniert sie für die Mehrheit der externen Entwickler eben nicht. llconvexdecomposition selber ist Open Source, aber da es nichts anderes als eine Zwischenschicht zu Havok ist, braucht man für einen alternativen Viewer eigentlich auch dann Havok, damit da Meshupload funktioniert.

Nun hat Linden Lab, damit externe Viewer auch Meshs irgendwann mal uploaden können, eine Bibliothek namens llconvexdecompositionstub im Programm. Diese enthält dieselben Funktionen wie llconvexdecomposition, aber ein Stub ist nur ein Platzhalter. Sprich, die Funktionsaufrufe laufen alle erfolgreich ab, aber diese Bibliothek leistet gar keine Arbeit. Der einzige Sinn und Zweck ist es, den Programmierern das Interface an die Hand geben zu können, mit dem sie dann selber einen Ersatz für Havok bauen können. Ob das kommt oder nicht, wird die Zeit zeigen. Es kann ja sein, dass die größeren Viewerhersteller wie Phoenix einfach Havok lizenzieren und dann auch entsprechend verteilen. Wenn man nämlich einen eigenen Ersatz für Havok da baut ist die Frage, wie gut oder schlecht die Ergebnisse im Vergleich zum Lindenviewer beim Upload sein werden.

Solange das aber noch Zukunftsmusik ist, solange funktioniert der Meshupload nur mit dem Lindenviewer wirklich zuverlässig. Wer Meshes erstellen will, der ist nur mit diesem wirklich auf der sicheren Seite.

Opensim: SQLite vs. MySQL

Eines der Themen, das bei der Benutzung von Opensimulator immer und immer wieder auftritt, ist die Frage nach der Datenbank: soll man nun SQLite oder MySQL für seine Installation nutzen? Die Gründe für die Wahl sind nicht immer für jeden verständlich, dabei ist es wenn man es aufdröselt recht simpel.

Zunächst einmal zur Grundlage: beides sind Datenbanken und damit fähig, die von Opensimulator benötigten Daten zu speichern und zur Verfügung zu stellen. Allerdings gibt es zwischen beiden Ansätzen einige Unterschiede. Beide Produkte sind stabil und reif genug für den Produktiveinsatz in ihren jeweiligen Einsatzgebieten, also man holt sich damit keine Bananensoftware ins Haus.

SQLite ist eine sog. embeddable Database Engine, das bedeutet es handelt sich dabei um eine kleine Programmbibliothek in C geschrieben, die man in Programme einbetten kann und dann da direkt Datenbankfunktionen zur Verfügung stellt. Da die Engine direkt im Programm abläuft, entfällt sehr viel an Overhead und SQLite ist da in seinen Anwendungsgebieten natürlich rasend schnell. Der Vorteil an SQLite ist, dass ein Programm es out of the box mitbringen kann und man muss wirklich Null administrieren, es funktioniert einfach. Aufgrund seiner Zielsetzung ist SQLite auf das schnelle Verarbeiten von Reads aus der Datenbank optimiert worden. Solange es darum geht, viel aus einer Datenbank zu lesen, ist es die erste Wahl. Ein Problem dagegen stellen die Writes dar, wenn man also etwas in die Datenbank schreiben will. Da kann nämlich SQLite nur einen zur selben Zeit bearbeiten und arbeitet zudem mit einem globalen Lock, sprich in der Zeit werden keine andere Transaktionen durchgeführt. Die Datenbank selber ist bei SQlite eine einzige Datei, die man problemlos kopieren kann.

MySQL dagegen ist ein ausgewachsenes Datenbanksystem, das viel mehr Funktionen als SQLite bietet. Es könnte zwar auch embedded laufen, aber in den meisten Programmen wird das wegen der Größe nicht so realisiert. Da es um einiges komplexer als SQLite ist, bedeutet es zunächst erst einmal einigen Aufwand das System so einzurichten, bis es läuft. Ist es aber erst einmal installiert und am Laufen, dann kann das System sehr gut skalieren und vor allem ist es bei der Abarbeitung der Writes dann SQLite überlegen. Wenn dann natürlich MySQL mal nicht laufen sollte, funktioniert die Sim sicher auch nicht mehr richtig.

Als Fazit kann man grob sagen: wer nur mal eben so eine Opensim für sich aufsetzen will, dem wird SQlite ziemlich sicher ausreichen und es funktioniert einfach. Fährt man aber dann ein größeres Setup wird es interessant, MySQL aufzusetzen. Läuft MySQL natürlich sowieso schon auf dem Rechner, spricht auch nichts dagegen, es gleich zu nutzen. Für Opensim-on-a-stick wiederum ist SQLite die erste Wahl. Wer seine Sim in ein bestehendes Grid reinhängt, dem reicht wiederum SQLite auch allemal aus, da sich die Writes dann doch stark in Grenzen halten (z.B. Terrainänderungen und dergleichen).