Opensim kann bisher keine multiplen Attachments

Und noch einen aus der OS-Mailingliste, jemand fragte nach, ob Opensimulator multiple Attachments beherrschen würde, da das für vielerlei Zwecke wie RP sehr nützlich wäre.

Justin Clark-Casey antwortete selber darauf:

Not yet.  More detail at [1].

Implementing multiple attachments on a single attachment point looks perfectly doable though unfortunately it means navigating and maybe cleaning up some foolishness in the way attachments are stored (e.g. at the moment there are two duplicate data structures that store attachment information).

[1] http://opensimulator.org/wiki/Feature_Matrix#Users

Auf Deutsch: nein, bisher kann Opensimulator das nicht, aber es sei wohl nicht weiter schwer das Opensim beizubringen, aber man müsse dafür wohl einigen grottigen Code aufräumen sowie die Datenbankstruktur anpassen.

Mesh Deformer v0.3 erschienen

Nachdem es einige Zeit lang um das Projekt sehr ruhig geworden war, hat nun Qarl Fizz Version 0.3 des parametrischen Mesh-Deformers veröffentlicht. Die Hauptänderungen sind die folgenden:

  1. der Patch funktioniert nun sauber mit dem aktuellen Code der Lindenviewer, was ja ein erklärtes Ziel gewesen ist und
  2. die Deformationstabellen werden nun in einem extra Thread im Hintergrund berechnet, so dass es zu keinen Einbrüchen bei den FPS mehr kommen soll.

Es ist zu erwarten, dass die üblichen Verdächtigen (Nirans Viewer, aber auch Cool Viewer usw.) den Patch bald bei sich eingebaut haben werden.

Second Life und die höhere Mathematik

Second Life selber ist schön bunt anzusehen, ein netter Zeitvertreib und macht vielen einfach Spaß. Wer sich in Second Life begibt und dort bewegt, der hat sicherlich alles andere am Hut, als sich mit Mathematik zu beschäftigen, und doch ist höhere Mathematik in Second Life allgegenwärtig, man muss nur einmal genauer hinschauen, um es zu begreifen. Mehr noch: ohne Mathematik wäre eine Welt wie Second Life gar nicht möglich!

Geometrie allüberall
Das beginnt schon mit den Prims: diese sind nichts anderes als einfache, geometrische Formen. Damit man sich in Second Life bewegen kann, wird jedem Punkt in einer Sim eine eindeutige Koordinate zugeteilt, das ist nichts anderes als ein dreidimensionales, kartesisches Koordinatensystem.

Nun bewegt man sich aber auch in Second Life oder gewisse Objekte bewegen sich, und damit kommt schon höhere Mathematik ins Spiel, denn um genau solche Effekte zu beschreiben, benötigt man Vektoren. Vektoren selber sind Bestandteil der sog. linearen Algebra, und mit diesen kann allerhand angestellt werden.

Wer also irgendwann mal mit Rotationen arbeitet oder Objekte skriptgesteuert irgendwelche Bewegungen vollführen lassen will, der kommt nicht wirklich darum herum. Gleiches gilt für das Partikelsystem und vieles, vieles mehr…

Das Geburtstagsparadoxon
Eine weitere Sache, die in Second Life täglich Anwendung findet, ist die Wahrscheinlichkeitsrechnung. Genauer gesagt geht es dabei um das sog. Geburtstagsparadoxon, welches ein altbekanntes und gut diskutiertes Problem der Mathematik darstellt.

Angenommen, in einem Raum befinden sich 23 Personen. Wie hoch ist dann die Wahrscheinlichkeit, dass mindestens zwei von ihnen ohne Berücksichtigung des Jahrgangs am selben Tag Geburtstag haben?

Die Antwort selber ist überraschend: die Wahrscheinlichkeit liegt höher als 50%, bei 36 Personen ist sie sogar bei 83%. (Eine genauere, mathematische Erklärung befindet sich hier in diesem PDF).

Nun möchte man aber fragen: was bitte hat das Geburtstagsparadoxon denn mit Second Life zu tun? Sehr viel, sogar sehr sehr viel, man nutzt es ständig, und die Form der Anwendung ist zum Beispiel solch eine Zahl: 5fe9759e-03e2-4268-8af0-ed165a158df1.

Das ist nichts anderes als die altbekannte UUID (128 bit breit), also der fundamentale Bestandteil aller Assets. Die Sache bei der UUID ist diese, dass diese rein zufällig innerhalb eines gewissen Namensraumes vergeben wird und man mit Hilfe des Geburtstagsparadoxon abschätzen kann, wie hoch denn die Wahrscheinlichkeit einer Kollision (die Vergabe derselben UUID zweimal also) innerhalb dieses Namensraums ist.

Diese ist trotz der stetigen Vergabe von UUIDs so gering, dass sich das System noch auf lange Zeit halten wird.

Nirans Viewer – nicht tot!

Ist Nirans Viewer tot? Zumindest gerüchtet das gerade der selbsternannte „Secondlife Technologist“ JayR Cela.

Nach seinen Worten habe Nirans Viewer ins Gras gebissen, da Nirans Rechner einen Festplattenschaden erlitten habe und – wie leider so oft üblich – es kein Backup gäbe. Es sei kein großer Verlust, da ohnehin niemand den Trumm hätte laufen lassen können.

A-ha. Was daran wohl nun wahr ist? Keine Ahnung. In Nirans Blog steht nichts, in Sluniverse auch nichts weiter, im offiziellen Forum zum Viewer ist nichts zu finden und der Sourcecode ist nach wie vor auf Sourceforge.net verfügbar. Wenn, dann fehlen bestenfalls einige Tage an Neuerungen, das dürfte es gewesen sein und den Rest kann man sich wieder flott unter Windoof zusammenbasteln.

Dazu kommt – und das ist noch wichtiger – dass die letzten Commits am Code von Niran selber auf der Projektseite bei Bitbucket gerade mal 21 Stunden zurück liegen. 21 Stunden! Ein totes Projekt sieht für mich nun wirklich anders aus, ich halte die Meldung daher für substanzlosen Müll und Panikmache. Mehr dürfte da auch nicht dran sein!

Update: so, ich bin nun auf Sluniverse.com doch noch fündig geworden. Zuerst einmal kann man hier nachlesen, das NiranV tatsächlich folgendes schrieb und zwar bereits vor sechs Tagen:

HD suddenly crashed , first whole Windows began to freeze , then after restart HD was gone…nice 2 TB of Data gone , with it my compiling Windows , all my Snapshots , Videos , programs , sourcecode and everything else… i hate self destruction HD…. will probably take many days to get my Windows back up to the point at which it is able to compile…

Sprich: es gab einen Festplattenschaden und alles war weg. So. Aber das ist ja kein Problem, wenn man seinen Sourcecode wie NiranV es tat auch bei Sourceforge.net hostet, und so gab es dann schon nach einigen Stunden folgende Statusmeldung:

good news , everything went ok… downloaded my source and compiled instantly without any error

Was nichts anderes heißt als dass es weitergeht, und man kann auch schon die nächsten, kommenden Fixes dann im Thread lesen. Hätte JayR Cela da ein wenig weiter gelesen, dann wäre es zu seiner komischen Meldung da erst gar nicht gekommen.

Ich verabschiede mich von hier mit einem aktuellen Video von NiranV, das die neuen Voreinstellungen für die Kamera zeigt, bitte sehr:

HJXxXYkPBA4

Slurp

Ivy Sunkiller entwickelt seit einiger Zeit eine python-ähnliche Skriptsprache namens slurp, deren Ziel es ist, die Programmierung mit LSL zu vereinfachen. Slurp dabei selber ist in Second Life nicht lauffähig, sondern wird durch einen Übersetzer nach LSL konvertiert. Die Idee dahinter ist dabei dieselbe wie Coffeescript, welches nach Javascript umgewandelt wird: man kapselt Teile der Syntax von LSL sowie der Komplexität vom Benutzer ab, dadurch soll das reine Programmieren einfacher und schneller von der Hand gehen. So fehlen in Slurp zum Beispiel die Strichpunke am Ende jeder Zeile und die geschwungenen Klammern völlig, die in LSL ja überall Standard sind, und auch will Ivy einige fortgeschrittene Datentypen bereitstellen, die LSL von Haus aus nicht bietet – was nichts anderes bedeute, als dass sie diese in LSL selber programmieren werden muss.

Eine Demoimplementierung des Projektes ist hier zu finden, da sieht man auch den bisherigen Stand recht gut. Eigentlich wollte er schon längst eine lauffähige Beta veröffentlicht haben, warten wir einmal ab, wann diese kommen wird.

Die Hintergründe zu dem Projekt sind dabei im Post „Fixing LSL – one step at a time!“ zu finden. Alles in allem bin ich auf die Beta gespannt, wenn diese denn mal verfügbar ist.