Ohne Hilfsmittel

Wie gesagt: Am Anfang war das ganz einfache Sitzen. Man kann Avatare auf so ziemlich alle Objekte setzen. Im allgemeinen starten sie dann die (bzw. mit Animation Override eventuell eine) Animation, die den Avatar in eine sitzende Position bringt.

Das ist in seiner Funktionsweise allerdings noch ausgelegt auf die guten alten Prim-Zeiten. Die Position des Avatars bestimmt sich aus dessen Shape und der Größe des Objekts, auf dem er sitzt, und die Ausrichtung des Avatars aus der des Objekts. Wer also Sitzmöbel aus mehreren Prims zusammenbaute, mußte aufpassen: Die Sitzfläche mußte korrekt ausgerichtet sein und beim Zusammensetzen des Möbels als letztes ausgewählt werden.

Animationen in Objekten

So startete der Avatar also immer die Standard-Sitzanimation oder eine der Sitzanimationen im gerade aktiven AO. Das war aber doof, wenn der Avatar im Sitzen irgendetwas Spezifisches tun sollte, z. B. Klavier spielen.

Hier kam nun erstmals Scripting zum Zuge: Es entstanden Skripte, die zusammen mit einer Animation in ein Objekt eingebaut wurden und die Kontrolle über den Avatar übernahmen, der sich auf das jeweilige Objekt setzte. Ein Skript, eine Animation, schon hatte man viel mehr Möglichkeiten. Ausgefuchstere Skripte haben in vorprogrammierten Abständen mehrere Skripte nacheinander durchgeschaltet.

Diese Vorgehensweise hatte noch einen weiteren Vorteil: Über das Skript konnte die Position des Avatars relativ zum Objekt eingestellt werden. Nun wurden auch Sculpt-Sitzmöbel als solche nutzbar, und auch dem Sitzen auf Mesh stand nichts mehr im Wege.

Soweit ich weiß, wurde dies erst mit OpenSim 0.7.3 möglich.

Line Dancing, Poseballs & Co.

Dieses Prinzip wurde alsbald noch weitergedacht. Wer sagte denn, daß Avatare damit nur tatsächlich im wahrsten Sinne des Wortes sitzen können sollten? Im Prinzip konnte man in solche Objekte doch jede x-beliebige Animation einbauen. Dann hätte man gleich noch mehr Möglichkeiten.

So entstanden immer neue Anwendungsgebiete. Beispielsweise konnten zum ersten Mal animierte Fahrstühle gebaut werden, die auch wirklich Avatare mitnehmen konnten bzw. zunächst natürlich nur jeweils einen: Er wurde einfach „auf“ die Fahrstuhlkabine „gesetzt“, nur eben mit einer Stehanimation, und bewegte sich dann mit der Kabine mit.

Die häufigste Verwendung dieser Sitzskripte war der Poseball. Im Prinzip ist das eine kleine Kugel, die man irgendwo verbaut, auf die sich ein Avatar setzen kann, um eine gewisse Animation oder eine ganze Reihe davon zu starten. Wenn ein Avatar auf einem Poseball sitzt – auch das ist Teil des Poseball-Skripts –, wird der Poseball unsichtbar, um nach Benutzung wieder sichtbar zu werden.

Die Anwendungsgebiete waren vielfältig: Hinter Tresen wurden Poseballs verbaut, damit ein Avatar sich als Barkeeper betätigen konnte. Hinter DJ-Pulten wurden Poseballs verbaut, damit man dem jeweiligen Party-DJ seine oder ihre Tätigkeit auch ansehen konnte. Poseballs wurden zum Posieren für Fotos oder zum Animieren von Avataren hinter Musikinstrumenten verwendet. Paaranimationen wurden mit jeweils einem blauen und einem rosa Poseball möglich, die entsprechend zueinander angeordnet wurden.

Auch Tanzen wurde einfacher. Bis dahin mußte man Tanzanimationen noch per Hand starten oder zumindest dafür ein Menü oder HUD starten. Nun konnte man Paartänze mit jeweils zwei Poseballs realisieren. Und ein naher Verwandter der Poseballs sind die Tanzpads: von der Funktionsweise her identisch, aber rund, flach und dutzendweise – je nach Platz natürlich – pro Tanzfläche verteilt. Außerdem bleiben sie dauerhaft sichtbar.

Multi-Love-Pose (MLP)

Poseballs hatten aber drei gravierende Nachteile. Erstens waren sie immer sichtbar und verschandelten einem damit optisch die Sim. Wer Fotos machen wollte, mußte immer erst vorher rumlaufen und die Poseballs entweder unsichtbar machen oder vorübergehend ganz rausschmeißen. Zweitens lagen sie immer an derselben Stelle, ob das jetzt paßte oder nicht. Verschieben konnte sie nur, wem sie gehörten, und auch das nur durch Bearbeiten. Und drittens konnten sie immer nur dieselben Animationen in derselben Reihenfolge, meist sogar nur eine einzige.

Irgendwann haben die Leute nämlich angefangen, mit Poseballs außer Tanzen auch noch andere Sachen darzustellen, die Paare miteinander machen konnten, vor allem im Bett. Es war besser als nichts, aber nicht wesentlich besser. Es gab meist nur zwei Poseballs, womöglich jeweils nur mit einer Animation drin. Die Bewegungen hatten im Endeffekt noch mehr nur symbolischen Charakter als heute, und Vorspiel mußte man im Chat „emoten“.

Als Lösung dieser Probleme entstand in den späten 2000ern MLP, kurz für Multi-Love-Pose, eine Erfindung des Second-Life-Users Miffy Fluffy. Daß es vor allem eine Lösung für den vorigen Absatz war, sollte anhand des Namen auf der Hand liegen. Zunächst gab es MLP nur in Second Life und nur in-world. Aber es war unter die extrem lockere BSD-Lizenz gestellt worden und konnte problemlos nach OpenSim gebracht werden. Es dauerte allerdings eine Weile, bis es sich dort einigermaßen auszubreiten begann, weil statische Poseballs in der Handhabung einfacher waren.

MLP funktioniert so, daß das System ganz zuerst ein Menü öffnet, über das man eine Position oder einen Satz davon auswählt. Dann erscheinen ein oder mehrere Poseballs, auf die man sich setzen kann. Wer neuere Systeme kennt, muß sich erst daran gewöhnen, daß man erst das Menü per Hand öffnet und sich erst dann hinsetzen kann. Noch dazu werden dann alle Avatare, die sich auf die Poseballs setzen, gefragt, ob das System sie animieren darf oder nicht. Und am Ende muß man alles per Hand wieder schließen, damit der oder die Kugeln wieder verschwinden.

Revolutionär war nicht nur, daß man die Poseballs nur sieht, wenn man sie braucht. Dazu kam, daß über das Menü voreingestellte Kombination aus Poseball-Positionen und eingebauten Animationen aufgerufen werden können. Eine weitere Besonderheit von MLP ist, daß es je nach gewählter Animation Objekte rezzen und derezzen kann, z. B. ein Buch, wenn ein Avatar in eine Leseposition gebracht wird.

Gerade aus heutiger Sicht nachteilig ist neben dem immensen serverseitigen Leistungsbedarf von MLP die komplizierte Handhabung. Das System startet nicht, wenn man sich auf ein Möbelstück setzt, sondern man muß es erst händisch starten und sich erst dann auf den bzw. einen daraufhin erschienenen Poseball setzen. Die Positionen inklusive Winkel sind einstellbar, aber nur im Zusammenspiel mit der Menüsteuerung und der viewerseitigen Bearbeiten-Funktion – und nur durch den Eigentümer. Aber MLP war erst der Anfang von Möbeln mit variablen Sexanimationen, und man ging bezüglich Verwendungszweck vermutlich davon aus, daß solche Möbel eh vornehmlich an privaten Wohnorten in festen Partnerschaften verwendet würden. An öffentliches Sexmobiliar war noch nicht zu denken.

Im Hypergrid findet man trotz allem heute noch Mobiliar mit MLP, und zwar sowohl in Möbelläden auf Freebie-Sims als auch – so widersinnig das auch ist – öffentlich nutzbar. Linda Kellie, die ihre Simdeko generell möglichst funktional gestaltete, stattete sowohl Prim-Möbel als auch Clutterfly-Mesh-Objekte mit MLP aus. Die Super Sex Bed Mattress arbeitet auch mit MLP und wird manchmal der Einfachheit halber in ungeskriptete Betten eingebaut. Es ist davon auszugehen, daß viele, die so etwas tun, die Matratze selbst nie getestet haben.

Paramour Multi-Animation Controller (PMAC)

PMAC (Github-Mirror) kam im Frühjahr 2015 auf. Entwickelt wurde es von der 2019 verstorbenen Skripting-Großmeisterin Áine Caoimhe (wie der Name ausgesprochen wird, erkläre ich euch vielleicht ein anderes Mal). Die kennt man ja ganz besonders für ihre zumeist golden glitzernde „Tanzkugel“, die Clubmaster Dance Machine, die erstmals gleichermaßen Einzel- wie auch Paartänzern individuelles, menügesteuertes Tanzen ermöglichte und heutzutage fast überall hängt, wo getanzt wird. Die basiert nämlich auch auf PMAC, genau wie Áines neuer Line-Dancing-Boden, der nur noch ein einzelnes Objekt ist, auf dem dutzendweise Avatare synchron zueinander tanzen können. Zusammen mit dem Clubmaster hat er Tanzpads weitgehend verdrängt.

Wie es zu der Zeit mit Animationssteuerung in Second Life jenseits von MLP aussah, gerade in Möbeln, kann ich nicht sagen. So durch und durch amerikanisch und kommerziell, wie Second Life ist, vermute ich, daß jeder Möbelhersteller, der nicht mit MLP herumkrücken wollte, seine eigene proprietäre und streng geheime Lösung für seine teuren Payware-Möbel hatte. Das dürfte auch erklären, warum auf den vielen Sitzmöbel, die schon vor einigen Jahren aus Second Life gecopybottet wurden, überwiegend gar nicht gesessen werden kann: Das ginge nur mit einem Skript, da ist aber keins eingebaut, weil man das ursprünglich vorhandene Skript nicht mitkopieren konnte.

In dieser Hinsicht war PMAC eine Riesensensation und meines Erachtens etwas, was OpenSim – oder zumindest das Hypergrid – Second Life ganz klar voraus hatte: PMAC war nicht nur kostenlos, sondern quelloffen, und es war von vornherein unter eine freie Lizenz gestellt worden. Jeder konnte diese Technologie nutzen – und sie wurde auch fleißig genutzt.

Was PMAC so sensationell machte, war, daß es fast keine Poseballs mehr brauchte. Weder waren irgendwo Kugeln angebracht, die sichtbar waren, sofern keiner drauf saß, noch mußte man diese Kugeln erst per Menü generieren und sich dann draufpflanzen. Man setzt sich auf etwas drauf, und PMAC tritt praktisch sofort in Aktion. Natürlich kann es auch über Menüs gesteuert werden, und wenn mehrere Avatare involviert sind, kann jeder die Animationen gleichzeitig steuern. Noch dazu startet PMAC selbsttätig, sobald man sich auf ein Objekt setzt. Last but not least hat PMAC einen geringeren Leistungsbedarf als MLP.

So etwas wie Poseballs gibt es eigentlich nur noch beim Clubmaster: jeweils eine glitzernde rosafarbene und blaue Kugel, weil die Ansteuerung von Tanzpaaren und die Positionierung der beiden Avatare zueinander anders nicht lösbar war. Sie müssen dafür ja auf irgendetwas „sitzen“. Das heißt, PMAC verwendet weiterhin unsichtbare Objekte zum Positionieren der Avatare, setzt diese aber automatisch auf diese Objekte. Sichtbar werden die Objekte erst dann, wenn die Position der Avatare eingestellt werden muß – und das kann wie in MLP weiterhin nur der Eigentümer und auch das nur mit Viewer-Hausmitteln.

Ein weiteres neues Feature von PMAC ist, Animationen mehrerer Avatare zueinander synchronisieren zu können. Falls sie nicht gleichzeitig gestartet sein sollten, gibt es eine Schaltfläche, mit der alle Animationen zeitgleich neu gestartet werden können.

Obendrein arbeitet PMAC nicht nur mit tatsächlichen Avataren, sondern auch mit NPCs – es kann sogar eingebaute NPCs rezzen und derezzen. Das bekannteste Beispiel dafür ist wieder der Clubmaster: Wer keinen Tanzpartner hat, kann sich einfach einen rezzen.

Natürlich wäre es einfach gewesen, den Code von PMAC zu kopieren und nach Second Life mitzunehmen. Da hätte er aber nicht funktioniert. Das liegt daran, daß PMAC nicht auf der Second-Life-Skriptsprache LSL basiert, sondern auf der mächtigeren OpenSim-Skriptsprache OSSL. LSL läuft auch in OpenSim, aber OSSL läuft umgekehrt nicht in Second Life.

AVsitter

AVsitter erscheint mir wie eine Art Versuch, PMAC mit den eingeschränkten Möglichkeiten von LSL in Second Life nachzubauen, um auch dort MLP durch etwas ohne Poseballs ersetzen zu können. Es ist meines Wissens tatsächlich jünger als PMAC. Seit dem 31. Juli 2017 ist AVsitter quelloffen und steht unter der Mozilla Public License, um auch in kommerziellen Produkten verwendet werden zu können.

Bei der Entwicklung hatte man OpenSim übrigens nicht im Sinn – vielleicht auch, weil OpenSim ja schon PMAC hatte. Dennoch ist es in OpenSim vorhanden. Ich sehe da zwei Einfallstore: Zum einen haben Leute wie Purple Swan aus dem Quellcode Referenzimplementationen für OpenSim gebaut, so z. B. auch „Sitzkissen“ oder „Matratzen“, die man unsichtbar in ungeskriptete Möbel einbauen kann. Zum anderen wurden wohl auch AVsitter-Möbel aus Second Life ohne ihre Skripte gecopybottet und dann in OpenSim mit den sowieso immer ziemlich gleichen AVsitter-Skripten nachgerüstet.

Ein Nachteil von AVsitter gegenüber PMAC ist, daß immer nur ein Avatar die Kontrolle über die Animationen hat. Demgegenüber stehen die Vorteile, daß die Position aller Avatare ohne irgendwelche Edit-Krücken direkt per Menü justierbar ist und AVsitter als bislang einziges System darauf eingehen kann, ob ein Avatar männlich oder weiblich ist.

Obwohl OpenSim seine eigenen Animationssteuerungen hat, hat AVsitter seinen Platz: An einigen Orten werden auf Wohn- oder Geschäftssims Parzellen vermietet, in denen OSSL abgeschaltet ist, PMAC also nicht funktioniert. Damit soll die Serverauslastung reduziert werden. Das liegt nicht etwa daran, daß AVsitter weniger Serverleistung braucht als PMAC, sondern damit soll verhindert werden, daß sich jeder zweite einen Clubmaster aufhängt. Außerdem war AVsitter vor dem Erscheinen von SFposer die einzige Animationssteuerung mit Positionseinstellung per Menü für alle Avatare.

SFposer

Zu guter Letzt sei noch SFposer erwähnt. Dahinter steckt Satyr Aeon, Betreiber von OpenSimWorld und Schöpfer vor allem der SatyrFarm. Von der SatyrFarm kommt auch das SF, aber mit der eigentlichen SatyrFarm hat SFposer nichts zu tun. Es ist erst 2020 erschienen und bisher nur in einer Beta-Version verfügbar und steht unter der GNU GPL 3.0.

SFposer basiert auf PMAC, braucht also auch wieder OSSL, und verwendet dasselbe Notecard-Format wie PMAC. Existierende PMAC-Objekte können also ziemlich einfach nach SFposer konvertiert werden. Gleichzeitig ist SFposer aber ein ganzes Stück mächtiger. So unterstützt es bis zu 99 Avatare, was es interessant für Tanzsysteme macht. Wie MLP kann auch SFposer Objekte rezzen – aber es kann obendrein sowohl vorübergehend Objekte an den Avatar hängen als auch dem Avatar Objekte geben. SFposer kann die Mimik von Avataren über entsprechend ausgestattete Animationen hinaus mit den Standard-Gesichtsausdrücken steuern. Es kann nicht nur genau wie PMAC NPCs verwenden und rezzen, sondern weil es optional fernsteuerbar und automatisierbar ist, kann es auch als reines NPC-Animationssystem verwendet werden.

Einen Vorzug, den SFposer sonst nur mit AVsitter gemeinsam hat, ist, daß auch hier jeder die Position seines Avatars selbst steuern kann. Dies ist erstmals mit den Vorzügen von MLP und PMAC zusammen möglich.

Für Objektbauer und -modifizierer hat SFposer gleichzeitig den Vorteil, sehr mächtig zu sein, und den, dennoch relativ einfach in der Handhabung zu sein, insbesondere im Vergleich mit AVsitter. Außerdem stammt es aus OpenSim selbst – auch wenn MLP und AVsitter aufgrund ihrer freien Lizenzen nicht illegal importiert wurden – und kann daher auf den erweiterten Befehlswortschatz von OSSL zurückgreifen. Noch dazu bietet Satyr Online-Konverter von MLP, PMAC und AVsitter nach SFposer an. Nachteilig ist allenfalls, daß durch die Lizensierung von SFposer unter der GPL in Objekten eingebaute SFposer-Skripte zwingend les- und bearbeitbar sein müssen, no-modify also nicht erlaubt ist.

Für Endnutzer hat SFposer bis auf seine noch geringe Ausbreitung nur den Nachteil, daß es genau wie PMAC nicht da verwendet werden kann, wo OSSL nicht erlaubt ist, insbesondere also auf gewissen Mietparzellen.

Von den genannten Systemen hat nur SFposer eine größere Zukunft, zumindest in OpenSim. Angesichts der anderen Systeme ist MLP hoffnungslos veraltet. AVsitter scheint „fertig“ zu sein; es wird nicht mehr weiterentwickelt. Die Entwicklung von PMAC wiederum kam zum Erliegen mit dem Ableben der Erfinderin. SFposer bekommt auch nicht oft Updates, aber das bisher letzte kam im Sommer 2021, und es ist davon auszugehen, daß SFposer keine ewige Beta-Version bleibt. Noch dazu kann SFposer sich seit Anfang 2021 sogar mittels eines Update-Skript selbst aktualisieren.

#OpenSim #FürAnfänger #FürFortgeschrittene #FürSecondLifeUmsteiger #Animationen

Was sie tun, ist eigentlich ganz einfach erklärt: Es gibt ja verschiedene Dinge, die ein Avatar tun kann, mit jeweils eigenen Animationen. Stehen, laufen, sitzen, auf dem Boden sitzen, springen, fliegen, schwimmen und so weiter. Die Standardanimationen dafür sind bombenfest im System eingebaut.

Nur sind sie eben nicht gut. Schon 2003, als Second Life startete, waren sie im Prinzip auch nur besser als nichts.

Ein Animation Override ist eine Kombination aus zwei Skripten, einer Notecard und einem Haufen Animationen. „Override“ sagt es ja schon: Er überschreibt diese Standardanimationen jeweils mit einer der Animationen, die mit ihm mitgeliefert werden. Oder gleich mit mehreren, die nacheinander durchgeschaltet werden, für mehr Variationen.

Dann hat man nicht mehr diese komische Standard-Stehanimation, die so aussieht, als wenn der Avatar gleich nach hinten umkippen würde, sondern ein halbes Dutzend sehr viel schickere, sehr viel natürlichere Animationen. Auch mehr oder weniger alles andere wird durch die mit dem AO mitgelieferten, schöneren Animationen ersetzt. Einige AOs machen sogar von Bento Gebrauch und steuern auch die einzelnen Finger an den Händen an. Ganz wenige gehen bei Bento sogar so weit, auch die Gesichtsmimik mit einzubeziehen.

ZHAO vs. khAOs vs. Viewer-AO

Es gibt drei Arten von AO, die in Funktionsweise und Handhabung unterschiedlich sind:

• ZHAO: Aus Second Life importiert, gibt’s fix und fertig in den meisten Freebie-Stores, wird einfach an den Avatar gehängt, verursacht aber viel Lag durch Serverauslastung
• khAOs: OpenSim-exklusiv, wird auch einfach an den Avatar gehängt, verursacht trotzdem keinen Lag, gibt’s aber fast nirgendwo bzw. muß man sich selbst umbauen
• Viewer-AO: Verursacht auch keinen Lag, läuft nämlich nicht auf dem Server, sondern im Viewer, ist aber komplizierter in der Einrichtung

ZHAO: Kennt fast jeder, nutzt fast jeder, überlastet die Gridserver

Eine schlechte Nachricht vorweg: Die allermeisten AOs, die man im Hypergrid vorfindet, sind komplett aus Second Life geklaut und wurden da von Vista Animations erschaffen. Die wohl einzigen legalen Fertig-AOs sind Rugged für Männer und Sweetness für Frauen, die Shandon Loring aus zusammengeklaubten legalen Animationen, unter anderem von Linda Kellie, gebaut hat. Woher der das Kernskript hat, weiß ich nicht, aber im allgemeinen kann man aus Second Life keine Closed-Source-Skripte klauen. Die Animationen wirken allerdings ziemlich robotermäßig im Vergleich zu den Motion-Capturing-Animationen aus Second Life.

Das System, das diese AOs verwenden, nennt sich ZHAO. Wer überhaupt AOs kennt, kennt fast ausnahmslos nur das. Das heißt, die Leute wissen meist nicht, was für eine Technologie hinterm AO steckt, es ist ihnen auch egal. Aber in den allerallermeisten Freebie-Stores gibt es nur immer dieselben ZHAO-AOs.

In der Handhabung sind sie denkbar einfach: Der AO ist ein winzigkleines Objekt, das man sich an den Avatar hängt. Und schon läuft er. Schon bewegt sich der Avatar viel schöner. Man braucht sonst nichts zu machen. Das heißt, ein paar AOs haben dazugehörige HUDs, die man sich extra anhängt, mit denen man den AO steuern kann.

ZHAO hat aber einen riesengroßen Nachteil, der auf Beschränkungen in der Second-Life-Skriptsprache LSL zurückzuführen ist: Es verursacht eine immense Serverlast.

Irgendwoher muß der AO ja wissen, wann welche Animation abzuspielen ist. Also quengelt er herum und fragt beim Gridserver an: „Sitz’ ich? Sitz’ ich? Sitz’ ich? Sitz’ ich? Sitz’ ich?“ Und zwar etwa zehnmal pro Sekunde. Pro Animation. Insgesamt also ca. 250× pro Avatar und pro Sekunde. Das ist wie ein Kind, das auf einer Reise ständig fragt: „Sind wir schon da? Sind wir schon da? Sind wir schon da? Sind wir schon da?“ Nur daß Kinder das nicht zehnmal in der Sekunde fragen.

Jedes Mal muß der Server antworten: „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ „Sitz’ ich?“ „Nein.“ Auch das ca. 250× pro Avatar und pro Sekunde.

Erst wenn auf die Frage „Sitz’ ich?“ ein „Ja“ kommt, geht der Avatar von einer der Stehanimationen zu einer der Sitzanimationen über. Damit hört aber nicht das Gequengel auf, denn weiterhin will der AO für jeden einzelnen Zustand wissen, ob er gerade aktuell ist. Auch wenn der Avatar sitzt, will der AO weiterhin wissen, ob der Avatar (immer noch) sitzt. Und ob er steht und ob er auf dem Boden sitzt und ob er läuft und ob er schwimmt und so weiter.

Die Belastung des Servers durch einen einzelnen Avatar kann man getrost vernachlässigen. Aber jetzt stelle man sich mal ein richtig großes Event vor. Nicht gerade den OSCC, da werden Avatarskripte und damit auch alle angehängten AOs unterbunden. Man stelle sich eher vor, ein großes, populäres Grid eröffnet eine neue Sim mit einer fetten Party. Oder noch schlimmer, eine Hochzeit. Und Avatarskripte werden nicht blockiert.

Da kommen dann 50 Avatare mit ZHAO-AOs. Zusätzlich zur himmelhohen Avatar-Komplexität – fast niemand kennt die Komplexität des eigenen Avatars – kommen also diese Skripte, die den Server mit Anfragen bombardieren. Über 12.000× pro Sekunde! Und der Server muß jedes Mal antworten – auch wieder über 12.000× pro Sekunde.

Und dann wundern sich die Leute, warum die Sim laggt von extrem langsam ladenden Objekten über schweren Chatlag bis hin zu massiven Bewegungsschwierigkeiten. Oder warum die Sim gleich mitten in der Party ganz abstürzt. Schuld hat dann der Simbetreiber. Oder der Gridbetreiber. Oder wenn beide jegliche Schuld von sich weisen und mit dem Finger auf die Nutzer zeigen, waren es mal wieder die anderen. Was auch immer die gemacht haben. Aber irgendwas müssen die ja gemacht haben. Man selbst hat auf jeden Fall gar nichts gemacht. Glaubt man.

Und selbst wenn: Man kann ja sonst nichts machen, außer ganz auf einen AO zu verzichten. Glaubt man.

Viewer-AO: Eigeninitiative zur Serverentlastung

Dabei ginge es auch anders. Man muß sich einen AO nicht zwingend als geskriptetes Objekt an den Avatar hängen und damit auf den Server einprügeln.

Man kann das auch im Viewer stattfinden lassen. Gute Viewer bieten nämlich die Möglichkeit, AOs aus dem Viewer heraus auszuführen. Man kann sich im Viewer seinen eigenen AO zusammenbauen, man kann aber auch fertige AOs importieren. Dabei sieht man den AO nicht nur selbst, sondern alle anderen sehen den auch.

Der große Vorteil ist, daß der AO nicht mehr beim Server herumquengelt. Er wird nun dadurch gesteuert, daß der Viewer sagt: „Du sitzt jetzt.“ Oder: „Du schwimmst jetzt.“ Je nachdem eben. Die Serverbelastung durch den AO schrumpft auf ziemlich genau null. Wenn das alle machen würden, hätte man auf Partys sehr viel weniger Lag.

Ein schöner Nebeneffekt ist, daß die AOs im Viewer viel einfacher zu handhaben sind als per Avatar-Anhängsel. Sagen wir, du mußt für irgendwas deinen AO abschalten. Normalerweise mußt du ihn ganz vom Avatar abnehmen. Wenn du ihn wieder benutzen willst und ihn nicht unter deinen Favoriten abgelegt hast, darfst du ihn erst aus dem Wuhling heraussuchen, zu dem dein Inventar mit der Zeit geworden ist. Wenn du ihn irgendwann gefunden hast, mußt du ihn an den Avatar wieder dranhängen. Dann darfst du warten, bis das Ding gerezzt und sein Inhalt geladen ist.

Den Viewer-AO kannst du mit einer Schaltfläche im Viewer ausschalten. Und wieder einschalten. Wenn der Viewer gut eingerichtet ist, ohne jegliche Menütaucherei. Standardmäßig ist nämlich die AO-Schaltfläche weder im Firestorm noch im Singularity sichtbar – wahrscheinlich, weil die meisten sie nicht brauchen, weil eh „alle“ mit ZHAO-AOs oder ganz ohne AO herumlaufen. Dadurch wissen viele aber nicht, daß man AOs auch im Viewer laufen lassen kann.

Auch das Wechseln des AO ist im Viewer einfacher: Man muß nicht erst das Inventar durchwühlen. Für die AO-Steuerung im Viewer gibt’s ein eigenes Menü, über das man einen der im Viewer eingebauten AOs auswählen kann.

Vor- und Nachteil gleichzeitig sind die Einstellmöglichkeiten, die noch dazu je nach Viewer verschieden sind: Einerseits kann man z. B. einstellen, ob automatisch zwischen verschiedenen Animationen desselben Typs gewechselt werden soll, ob in fester oder zufälliger Reihenfolge, und wie lange jede Animation laufen soll. Andererseits kann der Viewer nicht selbständig erkennen, wie lange die Animationen laufen. Das muß man selbst ermitteln (geht im Firestorm erst seit Version 6.4 und in anderen Viewern überhaupt nicht) und dann eine entsprechende Zeit händisch einstellen.

Was man auch noch einstellen kann, ist, wie sich die Sitzanimationen im Sitzen verhalten. Man hat drei Möglichkeiten: Entweder werden die Sitzanimationen des AO im Sitzen nie ausgeführt. Oder sie werden immer ausgeführt, auch wenn vom Objekt, auf dem man sitzt, schon eine Animation zur Verfügung gestellt wird (außer die so zur Verfügung gestellte Animation hat eine höhere Priorität). Oder sie werden immer ausgeführt, außer wenn vom Objekt, auf dem man sitzt, eine Animation zur Verfügung gestellt wird.

Nachteilig ist gegenüber dem angehängten AO aber die kompliziertere, unbequemere Handhabung vor der Inbetriebnahme. Da hat man ganz offensichtlich schon vor einer geschriebenen Anleitung kapituliert und statt dessen ein Video auf YouTube zur Verfügung gestellt.

Wie man AOs in den Viewer einbaut

Der erste Schritt ist, den AO selbst zu rezzen, also irgendwo in die Landschaft zu packen, wo man das darf. Da stellt er sich dar als, wie gesagt, winzigkleines Objekt. Es hilft ungemein zu wissen, wie er aussieht, sonst findet man ihn womöglich gar nicht. Dann öffnet man ihn und packt den Inhalt ins eigene Inventar aus. Die Vorgehensweise ist also dieselbe, wie wenn man eine Verkaufsbox rezzt und auspackt, nur mit einem sehr viel kleineren Objekt.

Der zweite Schritt ist, den AO in den Viewer zu holen. Dafür öffnet man zunächst das AO-Fenster. Dann sucht man sich im Inventar den ausgepackten AO. In dem gibt es eine Notecard, die die Funktionen des AO beschreibt. Die zieht man ins AO-Fenster. Welche Notecard das ist, erkennt man daran, ob der AO in den Viewer importiert wird oder nicht. Manche AOs sind eigentlich mehrere AOs in einem und enthalten mehrere solche Notecards. Die kann man dann alle nacheinander in den Viewer importieren, die liegen dann jeweils als eigenständige AOs vor.

Als drittes wird der AO dann – optional, sollte man aber in Erwägung ziehen – eingestellt. Verhalten beim Sitzen, automatisches Durchschalten der Animationen, oder wenn nicht, welche der verschiedenen Animationen man verwenden will, und so weiter.

Der Firestorm hat übrigens den Vorteil, daß man das nur einmal für alle zusammen machen muß, weil die Einstellungen nebst Animationen im Inventar gespeichert werden. Egal, wieviele Firestorm-Installationen man hat, die AO-Einstellungen sind immer gleich. Andere Viewer wie Singularity bieten diesen Komfort nicht, da muß man den zweiten und dritten Schritt einmal pro Viewer machen wenn man mehrere hat.

khAOs: OpenSim-Spezialität, so bequem wie ZHAO bei viel geringerer Serverlast, kennt aber keiner

Daß man überhaupt AOs direkt im Viewer nutzen kann, weiß aber kaum jemand. Wie das geht, erst recht nicht. Und von denen, die davon schon mal gehört, sind sich viele zu bequem und/oder zu unsicher in der Handhabung des Ganzen. Die bleiben lieber bei AOs, die man sich ganz einfach aus dem Inventar an den Avatar hängt. Die haben ja auch den Vorteil, daß man sie mit Outfits abspeichern kann. In Alltagskleidung bewegt sich der Avatar dann anders als im Abendkleid.

Als „Retter“ kam dann der Mann daher, der in OpenSim auch schon der Titanic das Sinken beigebracht hat: Kayaker Magic. Der schrieb ein neues Kernskript für die Anhäng-AOs. Und er schrieb es in OSSL. Das Ergebnis nannte er „khAOs“ und brachte es im August 2020 offiziell heraus.

OpenSim hat hier nämlich einen gewaltigen Vorteil gegenüber Second Life: Der Server teilt proaktiv dem Avatar mit, was letzterer gerade tut. Der Avatar muß gar nicht erst nachfragen. Entsprechend gibt es in OSSL die Möglichkeit, diese Mitteilungen in Skripten zu nutzen.

Statt also immer und immer und immer wieder zu fragen: „Sitz‘ ich?“ und auf die Antwort des Servers zu warten, tut das Skript zunächst einmal überhaupt nichts. Wenn sich nun ein Avatar hinsetzt, schickt der Server ihm die Nachricht: „Okay, du sitzt jetzt.“ Nur auf dieser Grundlage schaltet der Avatar dann um auf eine andere Animation (oder mehrere, je nachdem).

Für den Nutzer ändert sich durch khAOs grundsätzlich überhaupt nichts. Der AO handhabt sich genau wie die AOs, die man schon kennt: an den Avatar hängen und läuft. Einen Unterschied gibt es nur, wenn man schon einen Viewer-AO laufen hat und jetzt z. B. einen Rollschuh-AO, Schlittschuh-AO, Ski-AO oder dergleichen nutzen will, der auf khAOs umgebaut ist. Dann muß man nämlich den Viewer-AO so lange abschalten. (Oder man packt sich auch diesen zweckgebundenen AO in den Viewer.)

Gegenüber den ZHAO-AOs, die man fast überall in Freebie-Stores findet, sinkt die Serverbelastung durch khAOs-AOs auf nahe null. Das Gequengel fällt ja weg. Wenn auf einer Party mit 50 oder mehr Avataren viele einen khAOs-AO haben, hat man nicht mehr eine größere vierstellige Anzahl Anfragen pro Sekunde an den Server, der die alle beantworten muß. Wenn alle als Anhäng-AO einen auf khAOs-Basis haben, hat man auch mal minutenlang gar keine mehr, weil niemand den Zustand seines Avatars ändert, weil alle ihre Avatare auf der Line-Dance-Tanzfläche geparkt oder an den Clubmaster gehängt haben.

Jetzt gibt es aber zwei neue Probleme. Beide gehen darauf zurück, daß keine Sau weiß, daß khAOs existiert. Zum einen gibt es ziemlich genau null Nachfrage nach khAOs-AOs. Zum anderen ist bis jetzt wohl nur Cataplexia Numbers auf die Idee gekommen, sich mal die ganzen geklauten AOs vorzunehmen und auf khAOs umzubauen. Ich meine, der Umbau an sich ist simpel, man muß nur das Kernskript durch ein anderes ersetzen. Aber das macht eben keiner. Und auch Cat hat ihre umgebauten AOs alle in eine neutrale Sammelbox geschmissen und die irgendwo in ein oder zwei ihrer Sims versenkt, statt jeden AO einzeln in seiner eigenen bunten Box an die Wand eines populären Freebie-Store zu hängen. Ansonsten bietet nur Kayaker Magic selbst die Rugged- und Sweetness-AOs als khAOs-Umbauten an.

Wie man einen AO von ZHAO auf khAOs umbaut

Vielleicht ist ja jetzt jemand am Umbau in Eigeninitiative interessiert. Vielleicht hat jetzt sogar jemand vor, die vielen geklauten AOs, die man überall im Hypergrid in de Freebie-Stores findet, als khAOs-Versionen in den eigenen Freebie-Store zu hängen.

Wie gesagt: Der Umbau ist, wenn auch nicht ganz trivial, keine Raketenwissenschaft.

• Schritt 1: Man beschaffe sich das khAOs-Kernskript. Entweder baut man sich sein eigenes Skript namens „KHAOS-II-core“; den Inhalt findet man hier. Oder, besser noch, man geht in die OSCC Expo Zone 4. Da hat Kayaker einen eigenen Bereich, wo er das Kernskript und seine beiden umgebauten AOs anbietet. Das hätte den Vorteil, daß Kayaker als Schöpfer des Skript eingetragen ist und nicht man selbst. Das Skript sollte man irgendwo im Inventar ablegen, wo man es auch wiederfindet, also unter „Skripte“.
• Schritt 2: Man lege von dem AO, den man umbauen will, im eigenen Inventar eine Kopie an. Sollte man genau diesen AO gerade tragen, sollte man ihn vorher abnehmen.
• Schritt 3: Die Kopie benenne man um, so daß aus dem Namen hervorgeht, daß sie mit khAOs arbeitet.
• Schritt 4: Man hänge sich die umbenannte Kopie an den Avatar und bearbeite sie.
• Schritt 5: Im Inhalt des AO findet sich irgendwo ein Skript namens „ZHAO-II-core“ oder „CORE“ oder „engine“. Das lösche man. Es gibt auch ein Skript, das „Interface“ im Namen hat; das bleibt unangetastet!
• Schritt 6: Nun ziehe man aus dem eigenen Inventar das in Schritt 1 beschaffte neue Kernskript in den Inhalt des AO. Dieser kompiliert kurz neu und ist dann verwendbar.
• Schritt 7: Um das Ganze zu speichern, nehme man den AO wieder ab. Will man ihn nutzen, hänge man ihn hinterher wieder an.

Falls man das Ganze jetzt in der modifizierten Originalschachtel weitergeben will, geht es hier weiter. Voraussetzung ist natürlich, daß man den AO schon auf khAOs umgebaut hat, daher zähle ich mit 8 weiter.

• Schritt 8: Man rezze die Box, in der der AO ursprünglich gekommen ist. Falls man sie nicht mehr hat, gehe man in den Freebie-Store des eigenen Vertrauens und besorge sich eine neue.
• Schritt 9: Man benenne nun die Box so um, daß ersichtlich ist, daß darin ein khAOs-AO steckt (und nicht mehr der ursprüngliche ZHAO-AO).
• Schritt 9½ (optional): Falls man das kann, kann man auch die Boxart so umgestalten, daß auf den ersten Blick erkennbar ist: Hier steckt ein khAOs-AO mit weniger Serverbelastung drin! Man kann auch seine eigene Boxart gestalten; das wird aber diejenigen abschrecken, die AOs nach ihren ursprünglichen, mitgeklauten Boxarts „kaufen“.
• Schritt 10: Man lösche den in der Box enthaltenen AO aus deren Inhalt.
• Schritt 11: An dessen Stelle ziehe man den auf khAOs umgebauten AO in die Box.
• Schritt 12: Man nehme oder kopiere die so veränderte Box ins Inventar.
• Dies wiederhole man mit möglichst vielen AOs.
• Schritt 13: Man hänge die modifizierten Boxen in den eigenen Freebie-Store mit einem großen Vermerk, daß diese AOs so umgebaut sind, daß sie keinen Lag verursachen. Oder wenn man keinen eigenen Freebie-Store hat, reiche man sie an die Betreiber anderer Freebie-Stores weiter und sage denen, das sind dieselben AOs, die sie schon haben, aber die machen keinen Lag mehr.

Wenn man Glück hat, kommen dann wieder Leute, die ihre eigenen neuen Freebie-Stores bauen wollen, und nehmen dafür genau diese umgebauten AOs mit. Dann kann sich das Ganze endlich weiter ausbreiten.

Second-Life-Nutzer, die das hier gelesen haben, muß ich enttäuschen: khAOs läuft nicht in Second Life. Ich schrieb ja schon, daß es in OSSL geschrieben ist und nicht in LSL. Und OSSL-Skripte funktionieren nicht in Second Life, nur in OpenSim.

#OpenSim #FürAnfänger #FürFortgeschrittene #FürSecondLifeUmsteiger #Animationen

Der Avatar ist ein etwas weiteres Feld, also gibt’s hier auch mehr zu erklären.

Der Body

Der Kern des Avatars ist natürlich der Körper, also der Body.

Systembody

Am Anfang und dann jahrelang gab es nur den Systembody. Der ist nicht so schick und hochdetailliert wie Meshbodys, aber relativ simpel, genügsam in der Leistung und einfach in der Handhabung. Die Füße haben beispielsweise keine Zehen, die werden per Textur angedeutet; man spricht auch von „Entenfüßen“. Die haben aber den Vorteil, daß Layer-Socken ohne Schuhe besser aussehen.

Der Systembody ist fähig zu Gestik bis hin zu sich bewegenden Fingern und Gesichtsmimik. In der Handhabung ist er vergleichsweise einfach; Skins oder Hairbases und andere Tattoos kann man ihm einfach anziehen. Dafür hat er mehrere Textur-Layers mit vorgegebenen Funktionen, so etwa auch für Kleidung, die sogenannte Layer-Kleidung.

Es gibt an sich nur den einen Systembody, den man immer trägt, weshalb er im Aussehen nicht auftaucht. Man kann ihn zwar ausblenden, bzw. Meshbodys sollten das ganz automatisch tun, aber abnehmen kann man ihn nicht.

Shape

Der Shape bestimmt die Form des Körpers. Einerseits gibt es eine ganze Reihe an Parametern, mit denen man die Form steuern kann. Dazu zählt auch ein Umschalter zwischen männlich und weiblich. Sowohl in Second Life als auch in OpenSim ist der Standard-Shape, mit dem der Startavatar kommt, am Anfang weiblich (der Startavatar heißt übrigens „Ruth“); er kann aber auf männlich („Roth“) umgeschaltet werden.

Andererseits haben verschiedene Shapes auch verschiedene vorgegebene Grundparameter, die wesentliche Elemente von Form und Größe vorbestimmen, denn die regelbaren Parameter funktionieren nur in einem eingeschränkten Bereich. Mit einigen Shapes ist es beispielsweise nicht möglich, einen männlichen Avatar zu bauen, der kleiner ist als 1,88 m; andere Shapes erlauben das.

Wenn man den Shape, den man für seinen Body verwenden will, nach eigenem Gusto eingestellt hat, kann man eine Kopie davon mit den eigenen Parametereinstellungen speichern.

Einen Shape trägt man immer, aber er taucht im Viewer im aktuellen Aussehen auf, weil man den Shape auch auswechseln kann.

Haare

Auch Haare trägt man rein technisch gesehen immer, und auch sie lassen sich auswechseln.

Klassische Haare bestehen aus einer Textur und einer ganzen Anzahl an Parametern, um die Frisur zu bearbeiten. Die Einstellungen sind also ähnlich wie beim Shape, haben aber weitreichendere Auswirkungen auf die Form.

Das meiste, was man heutzutage an „Haaren“ findet, ist allerdings eine Glatze, die dafür dient, mit einer als Tattoo getragenen Hairbase und als Anhang getragenen modellierten Frisuren getragen zu werden.

Meshbody

Meshbodys waren seinerzeit in Second Life die zweite logische Konsequenz aus der Verfügbarkeit von Mesh: Man konnte endlich noch schönere, detailliertere und individuellere Körper und Körperteile (Köpfe, später auch Hände) modellieren. Vorher gab es schon Mesh-Köpfe und -Füße (mit Zehen!) für den Systembody.

Ein Meshbody ist zunächst einmal ein Objekt, das am Körper getragen wird. Er hängt sich aber an den Shape und läßt sich durch diesen verformen. Um einen Meshbody tragen zu können, muß der Systembody normalerweise mit einem Ganzkörper-Alpha vollständig ausgeblendet werden, sonst sind beide Bodys gleichzeitig sichtbar. Erst einige moderne Meshbodys mit Bake-on-Mesh-Unterstützung (z. B. Ruth2 v4, Roth2 v2) blenden den Systembody selbsttätig aus.

Früher kamen Meshbodys mit eigenen Layers, um klassisches Systembody-Zubehör benutzen zu können, als es noch kaum bis gar keine entsprechenden Pendants für Meshbodys gab. Jeder Layer ist aber eine eigene zusätzliche Mesh-Form auf jeder Body-Mesh-Form, was auf zahllose Meshes für einen einzigen Körper hinausläuft. Die daraus resultierenden vielen ungenutzten Layers trieben die Avatar-Komplexität unnötigerweise in schwindelerregende Höhen. Inzwischen müssen solche Layers per Applier – in Second Life spricht man von Omega – nachträglich angebracht werden, was die Komplexität zwar stark verringert, aber den Aufwand der Handhabung erhöht und auch die Flexibilität reduziert, denn Meshbodys können ohne dieses Hilfsmittel zusätzlicher Mesh-Schichten keine Texturen für den Systembody (Skins, Tattoos usw.) verwenden.

Bei den allermeisten Meshbodys ist der Kopf ein separater Teil. Das hat den Hintergrund, daß der Kopf durch einen separaten Mesh-Kopf ersetzt werden kann. Der Body erkennt den zusätzlich getragenen Kopf und schaltet den eigenen Kopf ab.

Bento

Frühe Meshbodys waren zwar schön anzusehen, aber im Grunde laufende Schaufensterpuppen. Der Einfachheit halber waren Köpfe und Hände in einem starren Stück gegossen, so daß es weder Gesichtsmimik noch bewegliche Finger gab. Das war tatsächlich etwas, was der Systembody besser konnte als jeder Meshbody, der hat nämlich einen in sich beweglichen Kopf und in sich bewegliche Hände. Bei den alten Mesh-Köpfen ist z. B. die Zungentextur tatsächlich unnütz, weil man nie eine Zunge zu Gesicht bekommt, weil der Mund dauerhaft geschlossen ist.

Dann kam Bento daher. Bento bezeichnet die interne Beweglichkeit von Mesh-Köpfen und -Händen, also Hände mit sich realistisch bewegenden Fingern und Köpfe mit flexiblen Gesichtern und veränderbarem Gesichtsausdruck. Bento war die erste Übernahme von Features des Systembody für Mesh-Körperteile.

Bento-Köpfe können grundsätzlich überall nachgerüstet werden. Bento-Hände dagegen sind Bestandteil eines entsprechenden Body, dessen eigener Kopf – sofern der Body überhaupt einen Kopf hat – dann auch bentofähig ist.

Um Bento nutzbar zu machen, braucht es natürlich eine entsprechende Ansteuerung. Zum einen gibt es Bento-Animationen, die vor allem die Gestik und Mimik ansteuern. Es gibt auch fertige Gesten, die von Bento Gebrauch machen. Zum anderen Animation Overrides, die auch auf die Bento-Funktionalität zugreifen und z. B. den Avatar ab und zu blinzeln lassen.

Kleidung und Accessoires

Layer

Am Anfang waren die Layers. Der Systembody kommt ja mit mehreren Schichten für Texturen, die zweckgebunden sind. Ganz unten ist die Schicht für die Skin. Dann kommen Tattoos, die auch z. B. Körperbehaarung als Textur oder Make-up darstellen können, und auf den Kopf die Hairbase. Darüber kommt dann die Unterwäsche in Form von Unterhose und Unterhemd, außerdem die Socken, die durchaus auch Strümpfe sein können. Als nächstes kommen Hemd, Hose und Schuhe. Ganz außen gibt es zum einen die Jacke, die den Oberkörper und ein kleines Stück weit den Unterkörper bedeckt, eine vom Körper abstehende, verformbare, normalerweise unsichtbare Schicht für einen Rock und eine für Schuhe.

Die Bezeichnungen sind vorgegeben, und die jeweilige Layer-Kleidung wird auch im Aussehen mit entsprechenden Symbolen angezeigt. Sie kann aber auch anderweitig verwendet werden. Badehosen für Herren können Hosen oder Unterhosen sein. Damen-BHs und Bikini-Oberteile gelten als Unterhemden, ebenso wie manche T-Shirts, damit sie unter Hemden oder dergleichen getragen werden können. Pullover und Sweatshirts gelten als Jacken, weil sie den Hosenbund überdecken. Oberhemden und T-Shirts laufen nur dann unter Hemden, wenn sie in der Hose stecken bzw. am Hosenbund enden. Bei einigen Herrenanzügen ist das Hemd und manchmal sogar die Krawatte im Jackett schon enthalten. Und der Rock kann auch verwendet werden als unterer Teil einer längeren Jacke oder eines Mantels.

Layerkleidung hat ihre Vorteile. Weil ihre Darstellung im Systembody schon integriert ist, wirkt sie sich nicht auf die Komplexität aus. Sie ist einsteigerfreundlich, weil sie einfach an- und auszuziehen ist und im Inventar ihre eigenen Symbole hat, und weil man unter Layerkleidung nie den Body mit irgendeiner Alpha-Funktion ausblenden muß. Außerdem funktioniert sie mit dem Systembody auch noch in den urältesten Viewern aus Zeiten, als an Mesh noch gar nicht zu denken war.

Aber seien wir mal ehrlich: Sie sieht nicht wirklich gut aus. Sie wirkt wie auf den Körper aufgemalt, denn genau das ist sie auch. Bei Frauenavataren kann sie sehr gut funktionieren, denn für Frauen ist es nichts zu Ungewöhnliches, hautenge Kleidung zu tragen. Aber auch da zieht sich dann die Hose tief in den Hintern und das Oberteil unrealistisch zwischen die Brüste, ganz zu schweigen von Trägern, die nichts zu tragen scheinen, weil sie durchgängig auf der Haut aufliegen. Bei Männeravataren ist es noch schlimmer, wenn das Anzugjackett, die Lederjacke oder sogar die Krawatte die Form des Sixpack annimmt, zumal Männer selten wirklich hautenge Sachen tragen.

Ein bißchen kann der Wie-aufgemalt-Effekt ausgeglichen werden durch die Fähigkeit einiger Layers, den Meshbody an einigen Stellen auszustülpen. An Armen und Beinen kann die Körperform nach außen vergrößert werden. Aber auch das sieht immer noch seltsam aus, denn es ist und bleibt ein Form-Offset des Systembody, und die ausgestellten Hosenbeine sind von unten mit Haut verschlossen.

Schuhe wiederum haben zwar die Möglichkeit, die Füße noch umfassender zu verformen, auch nach innen, und den ganzen Avatar um die Stärke der Sohle anzuheben, aber annehmbare Schuhformen sind damit nicht möglich. Im Gegensatz zur übrigen Layerkleidung dürfte man da draußen keine Layer-Schuhe mehr finden, wenn es sie denn je gegeben hat. Hier ging man sofort zu Sculpt über und nahm Layerschuhe nur als Ergänzung zu Sculpt-Schuhen, um z. B. Alphas vermeiden zu können oder den Avatar anzuheben. Und auch die Möglichkeiten der Frisurgestaltung mit den Ausstülphaaren sind zwar weitreichend, die Resultate sind aber nicht sonderlich überzeugend.

So war es kein Wunder, daß jede Alternative zu reinen Layers willkommengeheißen wurde.

Frühe Meshbodys haben noch klassisch wie beim Systembody nutzbare Layers, was sie sehr komplex macht, weil die Layers jeweils aus einer ganzen Anzahl separater Objekte bestehen. Ob das auch Layers für Kleidung mit einschließt, entzieht sich meiner Kenntnis.

Um die absurd hohe Komplexität in den Griff zu bekommen, hat man bei neueren Meshbodys diese eingebauten Layers wieder abgeschafft. Sie können also klassische Layers definitiv nicht tragen, weil es dafür keine Appliers gibt – aber gerade im Bereich der Kleidung gibt es angesichts weitaus besser aussehender Meshkleidung dafür auch keine Notwendigkeit. Daraus ergibt sich aber der Nachteil, daß man entweder nur die im Meshbody eingebauten Skins tragen kann, oder wenn die einem nicht gefallen, muß man eine andere per Applier überziehen, was den Body wieder komplexer macht.

Erst mit Bake-on-Mesh kam die nicht nur (leider nicht immer) volle, sondern sogar gegenüber dem Systembody noch erweiterte Layerunterstützung zurück.

Tip: Wenn man Layerkleidung mit “Anziehen” anzieht, ersetzt man die Kleidung, die man bisher auf dem Layer trug. Zieht man sie aber mit “Hinzufügen” kann, kann man auf demselben Layer mehrere Kleidungsstücke gleichzeitig tragen.

Prim und Sculpt

Um die optischen Nachteile reiner Layer-Aufmachungen auszugleichen, begann man alsbald damit, Prims und Sculpties als Avatar-Deko anzufertigen, die dann an den Body gehängt wurden. Die primären Einsatzgebiete waren zunächst einmal Frisuren, außerdem Kopfbedeckungen und Schuhe.

Ganz zu Anfang wurde tatsächlich mit Prims herumhantiert. Deren eingeschränkte Möglichkeiten führten aber zu Anhängen, die nur geringfügig besser aussahen als Ausstülpungen des Systembody, aber noch nicht unbedingt gut. Für die minimale Verbesserung waren sie außerdem zu komplex.

Klassische Prim-Anhänge verschwanden sehr schnell wieder, als Sculpties in immer größeren Mengen verfügbar wurden. Sie machten es möglich, mit einzelnen Prims sehr viel detailliertere Formen zu modellieren, als vor Sculpties mit einer ganzen Anzahl an Prims möglich waren.

Mit Sculpt wurde auch noch einiges mehr gemacht. Das fing an mit plastischen Hemdtaschen und Krawatten, die endlich frei hingen und nicht mehr auf den Sixpack aufgemalt waren; auch Schals, Kopfbedeckungen und Ohrringe waren jetzt möglich, ebenso besser aussehende untere Hosenbeine. Einige Designerinnen fertigten sogar Sculpt-Röcke an, die aber alle einen gemeinsamen Nachteil haben: Sie folgen prinzipbedingt nicht der Beinbewegung, weil sie an der Hüfte angebracht werden und komplett starr sind. Deswegen sind Sculpt-Röcke zumeist sehr weit geschnitten, und Sitzen ist in ihnen aus ästhetischer Sicht komplett unmöglich. Ein ähnliches Problem ergibt sich mit Sculpt-Stiefeln: Diese sind ebenso starr und hängen an der Wade, was unabhängige Bewegungen der Füße verhindert.

Eine Schwierigkeit bei Sculpt-Anhängseln ist, daß sie alle für den Systembody entwickelt wurden. Sie mit einem Meshbody zu verwenden, kann einen größeren Aufwand darstellen oder fast unmöglich sein.

Mesh

Mesh löste in der Avatardekoration eine gewaltige Revolution aus. Damit wurden erheblich detaillierte, realitätsnähere Accessoires möglich, die gleichzeitig den Primcount nicht ins Unermeßliche trieben.

Wie Prims und Sculpties ist Mesh zunächst einmal starr und hat damit die gleichen Einsatzgebiete.

Interessant wird es mit Rigged Mesh: Es hängt sich automatisch an einen, meistens mehrere von 19 verschiedenen Punkten ans Skelett des Shape und folgt somit der Körperhaltung und zumindest am Bauch der einstellbaren Körperform. Damit wurden so ziemlich alle erdenklichen Kleidungsstücke in Mesh möglich. Noch weiter geht Fitted Mesh: Es hat sieben zusätzliche Anbindungspunkte am Körper, ist aber im allgemeinen angepaßt an jeweils einen bestimmten Meshbody und funktioniert nur mit dem gut. Rigged Mesh stammt dagegen noch aus einer Zeit, bevor Meshbodys sich ausbreiteten, und ist häufig sogar noch geeignet für den Systembody. In dem Fall liegen Mesh-Kleidung Alpha-Layer bei.

Allerdings ist Mesh nicht ohne Nachteile, und die je nach Body und Mesh-Accessoires teilweise dramatisch höhere Avatar-Komplexität ist nicht unbedingt der gravierendste.

Der ist vielmehr, daß Mesh-Kleidung sich im Gegensatz zu Layer-Kleidung nicht jedwedem Body anpassen kann, weil sie nicht auf die Körperoberfläche gelegt wird. Wirklich universell passende Mesh-Kleidung gibt es also nicht. Wenn also Mesh-Kleidung nicht genau auf den Body abgestimmt ist, den man trägt, steht sie im besten Fall an Körperstellen ab, an denen sie eigentlich anliegen soll.

Ansonsten clippt der Body durch die Kleidung. Sofern das nicht an einem Bund oder Saum passiert, kann dem noch damit begegnet werden, daß der Body an den Stellen mittels Alpha ausgeblendet wird. Das ist aber zum einen bei vielen Meshbodys sehr viel aufwendiger als beim Systembody. Zum anderen kann es unschöne Nebeneffekte haben, wenn Körperteile einerseits durch die Kleidung clippen, andererseits aber auch an der Kleidung vorbei sichtbar sein können, z. B. die Beine eines Damenkörpers unter einem Rock. Wenn das Clipping erfolgreich mittels Alpha abgestellt ist, sind, wenn die Dame sitzt, die Beine unterm Rock überhaupt nicht mehr sichtbar, auch wenn sie es eigentlich sein sollten.

Alpha

Der Begriff Alpha kommt ursprünglich aus der Computergrafik im Zusammenhang mit transparenten Bereichen. Einige Pixelgrafikformate wie PNG und Targa haben einen Alpha-Kanal, mit dem für jedes Pixel die Transparenz gewählt werden kann.

Auch in Second Life und OpenSim steht Alpha für Transparenz. Eingeführt – und zur Notwendigkeit – wurde es mit Meshkleidung, um durch die Kleidung clippende Körperteile unsichtbar zu machen.

Beim Systembody geht das mittels Alpha-Masken, die in der Art von Layer-Kleidung angezogen werden, aber als äußerste Schicht, und alles unsichtbar machen, was sie nicht abdecken. Früher, als man noch vermehrt Meshkleidung auf dem Systembody trug, wurden sie häufig Rigged-Mesh-Kleidung von vornherein beigelegt und sind idealerweise an die Form der Kleidungsstücke angepaßt. Alpha-Masken funktionieren übrigens auch mit den freien, quelloffenen Bake-on-Mesh-fähigen Bodys Roth2 v2 und Ruth2 v4. Mit älteren Mesh-Bodys ohne BoM (Adonis bis 3, Apollo, Ares, Athena bis 5, Decadence, Maes usw.) funktionieren sie nicht, und Athena 6 und Adonis 4 müssen erst dafür angepaßt werden.

Ansonsten haben Meshbodys eine eingebaute Alpha-Cut-Funktion. Alpha-Masken funktionieren zum einen bei ihnen von vornherein nicht, weil sie auf den Systembody wirken. Zum anderen werden sie schon gebraucht, um den kompletten Systembody unsichtbar zu machen, damit man nicht mit zwei sich überlappenden Bodys dasteht. Wie gesagt, mit BoM funktionieren sie anders: BoM-Bodys blenden den Systembody selbst aus – zumindest die Körperteile, die sie ersetzen –, und die Wirkung von Alpha-Masken wird auf den Meshbody umgeleitet und blendet diesen dann stellenweise aus.

Die eingebaute Alpha-Cut-Funktionalität wird gesteuert über das mit dem Meshbody mitgelieferte HUD, das die grobe Form des Body einmal von vorn und einmal von hinten anzeigt, jeweils aufgeteilt in eine Anzahl von einzelnen Feldern. Dabei werden Arme und Beine nur von einer Seite angezeigt, weil hier die Felder komplett umlaufend sind. Klickt man auf eines der Felder, wechselt es im HUD die Farbe, und am Body wird es unsichtbar. Bei den meisten Bodys kann man so sehr kleinteilig die Sichtbarkeit steuern. Das macht allerdings die Avatardekoration und vor allem den Kleidungswechsel aufwendiger, zumal die HUD-Einstellungen nicht mit dem Outfit gespeichert werden können und jedes Mal, wenn mehr oder weniger Haut als vorher zu sehen ist, händisch angepaßt werden müssen.

Bake-on-Mesh (BoM)

Bake-on-Mesh ist eigentlich ein älteres Konzept, das nach Aufkommen von Meshbodys verwendet wurde, um z. B. unabhängig von der Körperform hautenge Kleidung zu tragen oder Tattoos oder Make-up aufzutragen ohne Applier und ohne Steigerung der Komplexität: Man nahm einfach die einzelnen Bitmaps der Skin, öffnete sie in einem Bildbearbeitungsprogramm, legte die aufzutragenden Texturen darüber, vereinigte das Ganze, speicherte es als neue Bilddatei und trug diese dann als neue Skin.

Bake-on-Mesh selbst kam ab 2018 allmählich in Second Life auf. Die Idee dahinter war, genau das ohne den Umweg über ein Bildbearbeitungsprogramm direkt im Viewer machen zu können. Alles begann mit einem Third-Party-Tool zum Vereinigen („Baken“) von Texturen im Viewer. Letztlich entwickelte Linden Lab so eine Funktionalität für Second Life selbst, die noch einfacher zu handhaben geht und dann nur noch von den Viewers unterstützt werden mußte. Das war 2019 erreicht.

Ab Anfang 2020 kam die Funktion an sich auch in OpenSim an. Der erste einigermaßen bekannt gewordene Meshbody mit BoM war der freie, quelloffene Meshbody Roth2 v2. Im Juli kam Athena 6 heraus, gefolgt von Ruth2 v4 Ende August und Adonis 4 Anfang September. Aber schon im Winter gab es die ersten Forks von Ruth 2.0 mit BoM.

Grundsätzlich bringt Bake-on-Mesh die Funktion des Systembody, mehrere Texturen übereinanderlegen zu können, für Meshbodys zurück. Der Unterschied ist aber, daß Bake-on-Mesh nicht mit mehreren Mesh-Schichten mit jeweils einer Textur arbeitet, die in der Anfangszeit der Meshbodys die Avatar-Komplexität extrem in die Höhe getrieben hat. Statt dessen nimmt es die Texturen, fügt sie in einer vorgegebenen Reihenfolge zusammen zu einer einzigen Textur und legt diese dann direkt auf den Body. Das Ganze geschieht, ohne das Inventar mit neuen Texturen zuzumüllen, und es ist voll reversibel.

Dabei werden alle Texturmöglichkeiten des Systembody unterstützt; man kann also uralte Layerkleidung auf topaktuellen Meshbodys tragen. Die mögliche Anzahl der zusammengefügten Texturen ist dabei im Gegensatz zum Systembody sogar theoretisch unbegrenzt. Früher mußte man noch mit Tattoos haushalten, weil nur eine begrenzte maximale Menge gleichzeitig möglich war. Bake-on-Mesh hat dagegen grundsätzlich keine Obergrenze für übereinandergelegte Texturen, weil ja am Ende sowieso alles eine Textur wird.

Roth2 v2 und Ruth2 v4 gehen sogar noch weiter: Auf ihnen funktionieren out-of-the-box klassische Alpha-Masken, die teilweise mit Meshkleidung ausgeliefert werden. Das Tragen von Meshkleidung ist mit ihnen so einfach wie mit dem Systembody – bis darauf, daß es für Roth2 v2 im Gegensatz zum Systembody überhaupt keine angepaßte und somit gut passende Meshkleidung gibt.

Bake-on-Mesh hat nur drei Nachteile: Erstens funktioniert es nur in neueren OpenSim-Versionen. Ab OpenSim 0.8.2.1 wird es sehr rudimentär unterstützt – so rudimentär, daß es für so alte OpenSim-Versionen spezielle Varianten von Roth2 v2 und Ruth2 v4 ohne HUD und weitgehend ohne Skripte gibt. Die regulären Varianten mit HUD werden erst ab OpenSim 0.9.1.0 unterstützt. In der Praxis spielt das keine Rolle: Reguläre BoM-Meshbodys funktionieren unter OpenSim 0.8.2.1 gut genug, solange man nicht am BoM herumstellen will, und ältere OpenSim-Versionen dürfte es im Hypergrid nicht mehr geben.

Zweitens werden nochmals neuere Version der Viewers benötigt, sonst sieht man statt der „Baked“-Texturen kunterbunte Ersatztexturen. Singularity unterstützt BoM erst ab Version 1.8.9. Firestorm kann BoM erst ab Version 6.3.9 anzeigen, die aber unpopulär ist, weil sie gern abstürzt, wenn man Objekte rezzt. Dieser Fehler ist seit der Version 6.4.5 Beta behoben. Die aktuellen Versionen von Firestorm und Singularity sind schon lange voll BoM-fähig. Die Zahl derjenigen, die immer noch hartnäckig mit Uralt-Viewern unterwegs sind, nimmt auch stetig ab, seit mehr und mehr Avatare mit Athena 6 unterwegs sind.

Und drittens kann man auf einem BoM-Meshbody zwar Layerkleidung tragen, die kann aber die momentan verfügbaren Meshbodys nicht wie den Systembody mittels Bumpmaps verformen. Layerkleidung sieht also noch mehr wie aufgemalt aus als auf dem Systembody, und Schlaghosen stellen sich nicht als Schlaghosen dar, sondern als Leggings.

Avatar-Komplexität (ARC)

Von allem, was der Viewer darstellt, sind normalerweise Avatare am aufwendigsten zu rendern. Sie sind zum einen sehr detailliert, und zum anderen ist es bei Avataren ziemlich sinnlos, sie wie Szenerieobjekte auch auf relativ geringe Distanz schon deutlich zu vereinfachen.

Hier kommt die Avatar-Komplexität ins Spiel. Höchstwahrscheinlich wird man früher oder später sowieso auf sie stoßen, denn zumindest Firestorm ändert standardmäßig bei Avataren ab einer einstellbaren Mindestkomplexität die Art, wie sie dargestellt werden: Der Avatar selbst wird zu einer sogenannten „Jelly Bean“, also zu einem einfarbigen, in sich fast starren, detailarmen Etwas, das die Umrisse des Avatars abbildet und nur noch alle paar Sekunden aktualisiert wird statt kontinuierlich. Und über dem Avatar wird dessen Komplexität angezeigt, sofern das nicht abgestellt ist. Man kann sich aber auch die eigene Komplexität und/oder die aller anderen Avatare anzeigen lassen, die normal gerendert werden. Singularity kennt kein solches Limit und kann auch die Komplexität nicht anzeigen.

Um einmal die Größenordnungen zu verdeutlichen, hier die Stufen, die Firestorm unterscheidet: * Low: 35.000 * Low-Mid: 100.000 * Mid: 200.000 (Standardeinstellung für maximale Komplexität vollständig dargestellter Avatare) * Mid-High: 250.000 * High: 300.000 * Ultra: 350.000

Natürlich wird die Avatar-Komplexität nicht zufällig ausgewürfelt. Sie hängt davon ab, wie der Avatar gestaltet ist, will sagen, aus wie komplexen Teilen. Am wenigsten komplex ist der Systembody mit Layerkleidung und ohne Prim-, Sculpt- oder Mesh-Accessoires, der hat normalerweise eine Komplexität von genau 2.000. Auch einfache, starre Mesh-Accessoires beeinflussen die Komplexität nicht wesentlich; selbst mit Hut und Schuhen kann man unter 10.000 bleiben.

Andere Anhängsel können die Komplexität extrem in die Höhe treiben. Einige aufwendigere Frisuren zählen etwa dazu. Es gibt auch Kleidungsstücke, die harmlos aussehen, deren Ersteller aber die 3D-Modelle vor dem Export nicht bereinigt bzw. vereinfacht haben. Bei der Herrenkleidung sind das etwa die Antony Pants, die zwar gut aussehen und vielseitig sind, aber die Komplexität um ca. 190.000 erhöhen.

Animationen

Animationen bringen, wie der Name schon andeutet, einen Avatar erst in Bewegung. Komplett ohne Animation könnte ein Avatar z. B. nicht laufen, sondern er würde wie eine Schaufensterpuppe auf Rollen starr durch die Gegend rutschen.

Die Animationen für den täglichen Gebrauch sind in den Viewer schon eingebaut, also zum Stehen (!), Laufen, Sitzen, Schwimmen, Fliegen usw. Es gibt aber auch andere Wege, Animationen auszulösen. So kann man beispielsweise Animationen auch einzeln im Viewer öffnen und händisch auslösen. In einschlägigen Freebie-Shops gibt es mitunter einiges an Animationen oder ganzen Animationspaketen.

Animation Overrides (AOs)

Animation Overrides sind spezielle Animationspakete, deren Aufgabe es ist, die Standardanimationen zu ersetzen. Sagen wir einmal so: Die standardmäßige, staksige Unisex-Laufbewegung ist alles andere als schön. Sie ist einfach nur da, aber es geht besser. Auch die anderen Standardanimationen glänzen nicht gerade mit Eleganz. Die Stehanimation ist so unnatürlich, daß der Avatar eigentlich nach hinten umkippen müßte.

An dieser Stelle kommen die AOs ins Spiel. Sie enthalten zum einen ein Bündel Animationen und zum anderen Informationen, welche Animation jetzt zu welchem Zweck dient.

Es gibt drei Arten von AOs, die unterschiedlich genutzt werden:

• ZHAO ist eine skriptbasierte AO-Technik aus Second Life, die die AOs im Hypergrid dominiert. Alle AOs, die man auf Freebie-Sims in bunten Kisten findet, laufen mit ZHAO. Man hängt sie sich einfach an den Avatar, und sie laufen. Ihr großer Nachteil ist aber, daß sie viel Serverlast verursachen, und wenn viele Avatare mit ZHAO-AOs zusammenkommen, führt das zu Lag.
• khAOs funktioniert in der Handhabung so wie ZHAO. Kayaker Magic brachte es im August 2020 heraus. Es nutzt spezielle Möglichkeiten in OpenSim, um die Serverbelastung auf ein verschwindend geringes Minimum zu reduzieren. Sein großer Nachteil ist, daß es kaum fertige AOs mit khAOs gibt, und wenn man nicht suchen will und auch nicht weiß, wo man sie findet, man auf – wenngleich relativ einfachen – Selbstumbau angewiesen ist.
• Viewer-AO bezeichnet das Verwenden eines AO im Viewer statt als Avatar-Anhängsel. Es verursacht überhaupt keine Serverlast mehr, ist aber durch die Vorbereitung, bevor man es das erste Mal nutzen kann, in der Handhabung am schwierigsten, und mit AOs mitgelieferte HUDs kann man auch nicht nutzen.

In einem späteren Post werde ich genauer auf AOs eingehen.

Zu AOs sei zum Abschluß noch ein Warnhinweis genannt: Es gibt Objekte und Skripte mit speziellen „Sitzanimationen“, die auch die Sitzanimation des Avatars überschreiben. Teilweise sind das tatsächlich Sitzanimationen, die z. B. in Möbel eingebaut sind, teilweise sind sie auch etwas ganz anderes, etwa Tanzanimationen. Die können mit einem AO ins Gehege kommen mit unvorhersehbaren, durchaus auch mal unschönen Folgen. Wenn man sich also nicht sicher ist, daß eine irgendwo eingebaute „Sitzanimation“ sich mit dem eigenen AO verträgt, sollte man vor dem „Hinsetzen“ den AO abschalten.

Tanzen

Avatare können auch tanzen. Sie dazu zu bringen, kann auf verschiedene Arten erfolgen.

So gibt es Tanzflächen oder Tanzpads, auf die man sich einfach „setzen“ kann und dann anfängt zu tanzen. Die einfacheren Exemplare fahren ein voreingestelltes Tanzprogramm ab, bei dem alle Avatare, die darauf „sitzen“, in Formation synchron dasselbe tanzen. Das ist einfach und beliebt bei denjenigen Nutzern, die OpenSim als glorifizierten Chat nutzen und an Immersion wenig interessiert sind. Bessere Ausführungen öffnen ein HUD, über das man Tänze auswählen kann.

Weiter verbreitet sind Tanzmaschinen. Die bekannteste Tanzmaschine dürfte die Clubmaster Dance Machine sein, der sich darstellt als langsam rotierende Kugel aus meistens goldenem Drahtgeflecht und normalerweise irgendwo über oder neben einer Tanzfläche hängt. Tanzmaschinen sind von vornherein flexibler und individualistischer als Tanzflächen. Zunächst einmal verlegen sie den Avatar nicht an irgendeinen vordefinierten Ort, sondern man tanzt da, wo man gerade steht. Außerdem sind auch die Tanzmaschinen mit einer ganzen Anzahl an Tänzen befüllt, die über ein HUD gesteuert werden können. Sie gehen dahingehend sogar noch weiter und bieten Paartänze an, an die sich noch ein zweiter Avatar anhängen kann. Hat man keine Tanzpartnerin/keinen Tanzpartner, kann die Tanzmaschine einem dafür einen NPC rezzen. Es ist eine ziemliche Anzahl an NPCs enthalten, die man durchschalten kann, bis man jemanden Passenden gefunden hat.

Am kreativsten ist es aber noch, sich selbst einzelne Tanzanimationen zu besorgen. Da gibt es auch sehr spezielle Tänze inklusive solcher, die für bestimmte Musikrichtungen oder gar Songs gebaut sind. So kann man den „Time Warp“ hinlegen, wenn der DJ ihn spielt. Oder man kann zu irischer Musik tanzen wie Michael Flatleys Tanztruppe. Oder man spielt zu gitarrenlastiger Musik Luftgitarre wie ein Wilder. Möglichkeiten gibt es da viele.

Gesten

Gesten sind im Prinzip so eine Art „Makros“, um Dinge mit einem Handgriff auszuführen.

Eine Geste kann eine oder mehrere der folgenden Funktionen auslösen:

• Avatar-Animation
• Chat-Eintrag
• Sound
• Objekt außerhalb des Avatars erzeugen und wieder entfernen inkl. Animation

Gesten können auch Timer enthalten, um Funktionen zeitverzögert auszulösen, und/oder eine Funktion mehrfach auslösen, z. B. mehrere Einträge im Chat hintereinander.

Ausgelöst werden Gesten entweder in der Bedienoberfläche des Viewers, oder sie können so konfiguriert werden, daß sie über den Chat ausgelöst werden, wenn man etwas Bestimmtes schreibt. Gerade weil Gesten auch auf den Chat hören, können sie aber nur verwendet werden, wenn sie vorher im Viewer aktiviert wurden, was wiederum nur mit Gesten im Inventar funktioniert. Gesten, die in der OpenSim Library liegen, können wiederum nur aktiviert werden, wenn man sie vorher ins normale Inventar kopiert; auch Verlinken funktioniert nicht.

Am besten lassen sich Gesten auf Veranstaltungen beobachten. Einige Leute machen davon gern und rege Gebrauch. Weil die allermeisten Gesten aber nur Chateinträge beinhalten und davon wiederum sehr rege Gebrauch machen, ist manchmal der Chat randvoll damit.

Manche AOs, besonders solche mit Vornamen, vertragen sich nicht mit Animationen in Gesten bzw. lassen diese gar nicht erst ablaufen. Das liegt daran, daß Animationen auf einer von vier verschiedenen Prioritäten laufen können. Leider sind die Animationen in einigen AOs auf eine zu hohe Priorität gesetzt, höher als die in Gesten. Nachträglich ändern lassen sich diese Prioritäten leider nicht.

Alt

Alt ist kurz für Alternativ-Avatar. In OpenSim kann man sich ja theoretisch beliebig viele Avatare auf beliebig vielen Grids anlegen. Viele User haben daher mehr als einen Avatar. Einer ist normalerweise der Hauptavatar, den man tagtäglich benutzt. Aber für bestimmte Zwecke hat man manchmal auch Alts, z. B. um mit denen zu experimentieren, um Zugangsbeschränkungen zu gewissen Grids umgehen zu können oder unter anderem Namen, um sich incognito bewegen zu können. Oder wenn man nach längerer OpenSim-Aktivität beschließt, sein eigenes Grid zu starten, hat man da natürlich als Admin à la Linden auch einen eigenen Avatar.

Die Handhabung mehrerer Alts gleichzeitig ist etwas schwieriger. Man kann sich ja mit seinem Viewer nur einmal auf einem Grid einloggen, also braucht man pro Avatar eine eigene Viewerinstanz und einen entsprechend leistungsfähigen Rechner. Am einfachsten geht das mit mehreren Bildschirmen, aber zumindest Singularity mag Multiscreen-Setups gar nicht – Firestorm macht da wiederum keine Probleme.

#OpenSim #FürAnfänger #Avatar #BakesOnMesh #Animationen #Alt