Monat: November 2010

Web on a Prim continued: Einstellungen, Features und Umwege

Nun habe ich doch einmal die Sicherheitseinstellungen getestet, also den Zugriff auf bestimmte URL-Muster zu begrenzen. Und ich hatte Recht: Irgendeine Einstellung in Second Life (oder in der Sandbox, die ich nutzte, um das Ganze auszuprobieren) verhinderte, dass ich die erlaubten URL-Muster auf wolfsbone.de einschränkte. In OSgrid funktioniert es: *wolfsbone.de* als Filter eingetragen sorgt dafür, dass ich als User in der Adresszeile eintragen kann was ich will, der Browser Zeit immer nur Seiten an, die sich auf der Domain wolfsbone.de befinden. Ist natürlich nachteilig bei externen Links, macht also im Blog nicht so wirklich Sinn. Das Ganze ist ja aber auch dazu gedacht, den Zugriff auf andere Seiten zu unterbinden, wenn man nur bestimmte Seiten anzeigen will. Will man nun verhindern, dass jemand wie wild durch alles Mögliche surft, lässt sich das bis zu einem gewissen Grade auch erreichen, indem man einfach die Adresszeile des Browsers ausblendet (also die Mini-Toolbar statt der Standard-Toolbar einblendet).

Ein sehr gutes und interessantes Feature habe ich noch entdeckt bei meinen Experimenten. Und zwar zeigt die Toolbar eine Lupe an. Zunächst dachte ich, diese Lupe würde den Inhalt des Browsers heranzoomen, was ich nur für begrenzt sinnvoll hielt. Dahinter aber steckt eine wirklich sinnvolle Funktion: Die Kamera zoomt genau auf das Prim, so das ich den Inhalt bestmöglich betrachten kann (wie das aussieht, siehe Screenshot weiter unten).

Ja, und dann war noch die Frage, wie man Nutzern anderer Viewer klar macht, dass in dem gerade verwendeten Prim mehr steckt, als man auf Anhieb vermuten könnte. Die Lösung ist denkbar einfach: Neben der Media-Option lässt sich auch eine ganz normale Textur auf der Fläche laden. Sind die Medien deaktiviert, wird die normale Textur angezeigt. Und die kann man dann ja nutzen, um weitere Informationen zu transportieren:

Dann noch ein ärgerlicher Punkt im Zusammenspiel von Viewer 2 und OSgrid: Offenbar kommt der Viewer nicht ganz mit den Dingen, die unter Aussehen definiert wurden, klar. Zunächst konnte ich mich nur als Wolke sehen, und nachdem ich neue Outfits angelegt hatte, wurden diese immer dann teilweise überschrieben, wenn ich mich wieder mit einem anderen Viewer einloggte. Teilweise trug mein Avatar einzelene Teile doppelt, was dann zu unschönen Effekten führte.

Web on a prim – was funktioniert, was nicht

Voller Begeisterung über die Web-on-a-Prim-Funktionalität des Viewer 2 habe ich mich mal zu ein paar Tests hinreißen lassen – sowohl in OSGrid als auch im Vergleich dazu in Second Life (in der Sandbox). Wie Bert ja schon andeutete, schafft dieses Feature wahrlich neue Möglichkeiten Inworld, lässt es doch alle Beschränkungen hinter sich (oder sagen wir mal: viele), die kreatives Arbeiten jenseits der Bautätigkeit behindern.

Also zunächst einmal das, was der Browser kann: sehr, sehr viel. Alleine schon dass man mit der jeweiligen Webseite auf dem Prim interagieren kann wie in jedem anderen Browser, ist revolutionär. Man kann scrollen, Text markieren, auf Links klicken und Formularfelder ausfüllen. Aber der Browser kann offenbar noch mehr: Javascript & Co. scheinen für ihn ebenfalls kein Problem zu sein. Mir gelang es nicht nur mühelos, dieses Blog auf einem Prim aufzurufen. Ich konnte mich in den Administrationsbereich einloggen. Ich konnte den Editor aufrufen – für sich genommen relativ profane Dinge, an denen aber schon die meisten Handy-Browser scheitern. Noch mehr: Ich konnte sogar die Mediengalerie aufrufen und (vorhandene) Bilder einfügen. Was ich nicht konnte, war neue Medien hochzuladen, aber das scheint auch naheliegend. Ich nehme mal an, dass berechtigungen im Dateisystem verhindern, dass ich darauf zugreifen kann (er müsste ja auf das Dateisystem des Grids zugreifen, logisch, dass das nicht geht). Ich vermute, dass ein solcher Aufruf (Zugriff auf das Dateisystem) schon Viewerseitig untersagt ist.

Hier jedenfalls mal ein paar Screenshots, wie ich mich auf dem Blog (mit markiertem Text) und im Admin-Bereich des Blogs bewege:

Zunächst wunderte ich mich, dass die Webseiten-Darstellung beim Relog nicht mehr vorhanden war und ich den Home-Button in der eingeblendeten Leiste klicken musste, damit die Seite aufgerufen wird. Nach ein bisschen Googeln stellte ich aber fest, dass man lediglich die automatische Wiedergabe von Medien einstellen muss, damit auch die Seite direkt (also ohne zusätzliche Interaktion des Nutzers) angezeigt wird.

Etwas hakelig scheinen noch die Berechtigungseinstellungen zu sein. So wurde mir beispielsweise – wenn ich als Besitzer des Prims untersagte, dass jeder die Steuerungsleiste nutzen darf – auch als Besitzer die Steuerungsleiste nicht mehr angezeigt, obwohl das Häkchen „Eigentümer darf Steuerungsleiste nutzen“ gesetzt war.

Was leider auch nicht angeboten wird (im Viewer 2) ist die Möglichkeit, beim anklicken des Prims die Medien wiederzugeben. D.h., ich muss entweder die Steuerungsleiste sehen oder die Parzellenmedien automatisch wiedergeben.

Was in Secondlife nicht so recht zu funktioniert hat, war die Whitelist (welche Seiten dürfen aufgerufen werden). Google.com als Eintrag wurde akzeptiert. Wolfsbone.de/simworlds nicht. Ich vermute, dass das eine Einstellung in Second Life ist, habe es aber in OSGrid noch nicht getestet.

Äußerst schade ist natürlich auch, dass das Feature (noch) nicht von anderen Viewern unterstützt wird. Das liegt aber wohl daran, dass es eher ein Viewer-Feature als ein Inworld-Feature ist. Mit meinem eher bescheidenen technischen Verstand würde ich vermuten, dass die einzige Erweiterung Inworld darin besteht, dass im Prim eine URL hinterlegt wird (und die Anweisung, auf welcher Seite des Prims diese dargestellt werden soll sowie diverse Berechtigungen), alles andere macht der Viewer.

Media on a Prim mit OpenSim

Wunderbar, das klappt 🙂
Und schafft somit ganz neue Möglichkeiten.
Insbesondere Bilderausstellungen oder inworld-Dokumentationen sind somit jetzt möglich, Web3D nähert sich mit großen Schritten.

Bedauerlicherweise ist – nicht nur für das Anlegen – sondern auch für die Darstellung der SL-Viewer2 notwendig. Das wird den Kreis der Nutzer natürlich stark einschränken und unsereiner wird sich möglicherweise damit abfinden müssen, sich um das sehr gewöhnungsbedürftige Design des SL-Viewers zu kümmern um damit die mit anderen erreichte Effizienz beim Bauen zu erreichen. Aber die Vorteile scheinen im Moment zu überwiegen, schauen wir mal was die Performance sagt.

Web on a Prim mit dem Viewer 2

„Web on a Prim“ scheint mittlerweile Problemlos möglich zu sein. Und zwar nicht so, wie man es bisher machte (kompliziert mit Media-Textur über die Landeinstellungen), sondern pro Prim und einfach über die Textureinstllungen. Das ist aber nicht das einzig neue: Hat man eine URL für eine Adresse definiert, wird aus dem Prim sogar ein vollwertiger Browser, über dem eine Adressbar eingeblendet wird. Allerdings (und hier kommt ein kleiner Haken): Das Ganze funktioniert nur mit dem Viewer 2 (von Linden). Ich habe es in SL selbst ausprobiert. Ältere (oder andere aktuelle Viewer wie der Hippo) scheinen das Feature nicht zu unterstützen. Dass es aber grundsätzlich auch in OpenSim läuft, demonstriert folgendes Video (via Grid-Gazette):

Ninja Number Two

Im Laufe des Tages konnte ich heute beobachten, dass die Load der Maschine recht erheblich war. Der sonst übliche Neustart wegen aufgeblähtem Mono brachte nichts, ohne Betrieb auf den SIMs blieb die Last bei einer nahezu ausgelasteten CPU (von zweien). Also dann mal rein ins Grid und schauen was da so los ist. Der erste Eindruck: Das übliche wenn etwas viel Power nimmt: Bewegen war kaum möglich. Mittels Ctrl-Shift-1 war denn auch klar wo es herkam: 200ms und mehr Physics-Time je Frame, wo das verursacht werden mag? ;). Ein Sichten der vorhandenen Objekte brachte denn auch Klarheit, und zunächst dachte ich wir hätten Besuch gehabt von jemandem der ein wenig „aufgeräumt“ hat: Nahezu alle physischen Objekte lagen wild zuckend auf dem Boden rum statt locker zu pendeln wie es die Absicht war. Ob das jetzt am Neustart lag oder sich die Dinger einfach im Laufe der Zeit verselbständigen bleibt zunächst unklar. Klar ist auf jeden Fall eines: So geht’s nicht, weil dass sich während der Abwesenheit ein beliebiges Chaos einstellt ist nicht akzeptabel. Also war es das zunächst mit der Ninja-Physics, ich gehe wieder zurück auf die althergebrachte Steuerung von Objekten und konstruiere die „Gelenke“ selbst. Zwar wesentlich aufwändiger, aber dafür auch sicher. Außerdem brauche ich keinerlei Hilfsobjekte die die Bewegungen zwangs-initiieren. 🙂

klein aber fein

Die Aufgabenstellung lautete: Wie erzeuge ich ein wechselndes Hintergrund-Bild für eine Seite?
Die Lösung war – dank der umfassenden Möglichkeiten der bash, schnell gebastelt:

[code lang="bash"]
#!/bin/sh
range=`ls *.jpg | grep -v background | wc -l`
number=$RANDOM
let "number %= $range"
if [ $number -eq 0 ]; then let "number++"; fi
name=`ls | tail -$number | head -1`
cp $name background.jpg
[/code]

Das „Programm“ geht davon aus, dass es ein Verzeichnis gibt in dem die zu wählenden Bilder lagern (so ne Art „<body background=’background/background.jpg‘>“. Dort erzeugt es die Menge der vorhandenen Bilder abzüglich des einen das später der aktuelle Background wird (range). Es wird mittels $RANDOM und dem sich anschließenden Modulo (Rest einer ganzzahligen Division) eine Zufallszahl ermittelt die innerhalb dieser Menge liegt (number). Dann wird diese Zufallszahl-Menge an Dateien angelistet und davon nehmen wir uns die erste (head -1). Das wiederum kopieren wir auf background.jpg, welches in der Seite fest verdrahtet als Hintergrund genommen wird. Und schon haben wir – vielleicht noch mit einem reload im Meta-Bereich der index.html oder index.php oder wie auch immer einen wechselnden Hintergrund. Wird natürlich angesteuert über die cron – wie sonst ;), zum Beispiel mit einem „*/15       * * * * (cd theSite/background && ./generate.sh)“, wenn das kleine Ding von oben in „generate.sh“ gespeichert wurde, womit also dann alle 15 Minuten ein anderer Hintergrund der vorliegenden Bilder erzeugt würde.

(K)(l)eine Arena

Ausstellungshalle
Ausstellungshalle

Wer sich fragt, was ich da gerade auf dem Bild mache, ob dort vielleicht das neue OSGrid-Fußball-Stadion entsteht oder eine Art virtuelles Guggenheim… Mit Letzterem liegt man gar nicht so schlecht. Es ist der Versuch, eine Ausstellungshalle zu bauen, um Bilder und Fotos zu zeigen, und zwar nicht der übliche viereckige Kasten, sondern mal was Ausgefalleneres.

Allerdings sind das nur Vorentwürfe bzw. Tests, die gerade dort entstehen. Bauen werde ich das Ding wohl auf einem lokal laufenden Grid, um es dann vielseitig einsetzen zu können.

Ninja Number One

Die Ninja Physics Erweiterung der ODE ist vom Resultat her eine feine Sache. Endlich sind Gelenke möglich, zur Zeit sind lediglich zwei Arten realisiert: Ein Kugelgelenk (balljoint) und ein Scharnier (hingejoint). Die Ergebnisse sind wunderbar anzuschauen, Videos dazu auf Youtube geben nur sehr unpräzise wieder was möglich ist, daher spare ich mir hier die Einbindung.

Was die Implementation angeht, muss ich aber sagen, dass ich von den Machern enttäuscht bin, denn die Verknüpfung der Prims mittels eines Joint-Prims über Namen und Beschreibung halte ich für sehr unprofessionell. Wo bleibt die weltweit eindeutige UUID mit der man hätte arbeiten können? Sicherlich ist somit eine Konstruktion ohne Scripting möglich, aber was für ein Aufwand den man betreiben muss um erstellte Objekte funktionsfähig zu erhalten. Und das ist wirklich ein grosser Nachteil: Bastelt man an einem neuen Objekt herum und passt nicht auf mit den Namen, geschieht es leicht dass man schon existierende zerstört, was niemals sein darf.

Okay, ich gebe zu, meine recht schlampige Arbeitsweise wird hier zwangs-diszipliniert, was auch angenehm sein kann. 🙂

Ein recht mühseliger weiterer Punkt ist, dass man Gelenke die sich nicht an der Oberfläche ansiedeln sollen, auf irgendeine Art in der Luft halten muss. Auch Fortbewegungen der gebauten Figuren müssen zwangsinitiiert werden. Aber hier liegen die scheinbaren Begrenzungen sicherlich noch daran dass ich mich nicht genügend mit der Materie beschäftigt habe.

Das Resumé lautet: Wunderbar in der Wirkung, gewöhnungsbedürftig in der Anwendung. Scripting und Velocity-Einbau wird sich noch zeigen in wieweit das machbar ist.