Warum das so ist und warum das so kam, möchte ich hier erzählen.

Singularity ist eigentlich ein uralter Viewer. Vor etwa zehn Jahren wurde er von Ascent geforkt, was seinerseits ein Fork von Inertia war mit dem Ziel, den vor 14 Jahren gestarteten, aber nur kurze Zeit entwickelten Inertia in Second Life zugelassen zu bekommen.

Asbach-Code

So alt der Viewer ist, so alt ist zu erheblichen Teilen natürlich auch der Code. Und wenn man aus der Software-Entwicklung eins gelernt hat, dann ist das: Wenn Bibliotheken oder andere Abhängigkeiten, gegen die etwas entwickelt ist, aktualisiert werden, wird der Code, der gegen sie entwickelt wurde, nicht mitaktualisiert. Jedenfalls nicht, wenn es nicht unbedingt notwendig ist.

Niemand eröffnet einen Issue, weil irgendeine Abhängigkeit aktualisiert wurde, um den Code entsprechend zu modernisieren, wenn der Code auf dem Stand von vor sieben Jahren immer noch wunderbar kompiliert. Und selbst wenn, wird der Issue nicht etwa gefixt, sondern ignoriert oder mit Won't Fix geschlossen. Den Aufwand, etwas zu „reparieren“, was funktioniert, ohne daß sich sichtlich irgendetwas verbessert, macht sich kein Entwickler. Selbst wenn jemand einen Pull Request einreichen würde mit einer gründlichen Code-Modernisierung, dürften viele Kernentwickler keine Lust haben, den zu überprüfen, wenn er nichts wirklich repariert oder verbessert.

Natürlich fängt der Compiler irgendwann an, „Deprecated“-Meldungen auszugeben. Und die werden mit der Zeit immer mehr. Die werden aber geflissentlich ignoriert. Kompiliert ja und läuft hinterher auch. Also alles in Ordnung. „Deprecated“ wird von vielen Entwicklern als „stilistisch veraltet“ angesehen. Tatsächlich aber bedeutet es: „Wird demnächst nicht mehr unterstützt, also kommt in die Puschen und bringt euren Code auf Stand!“

Die ganz schlimmen Finger copy-pasten sogar Code, der deprecated ist, oder schreiben ganz neuen Code, der gleich deprecated ist, weil sie das schon immer so gemacht haben. Außerdem: Wer achtet denn beim Kompilieren darauf, was genau deprecated ist?

Und irgendwann geht’s einfach nicht mehr

Eines schönen Tages dann bekommt man auf seinen Rechner per Systemupdate neue Versionen der Bibliotheken und des anderen Zeugs, gegen die man baut. Auf einmal kompiliert der eigene Code nicht mehr. Was bis gerade eben noch deprecated war, wird jetzt endgültig gar nicht mehr unterstützt.

Dann hat man als Entwickler ein Riesenproblem. Einige Entwickler erinnern sich an die „Deprecated“-Meldungen und sagen: „Hätte ich mal …“ Andere reden sich ein, daß das doch niemand hätte ahnen können, daß das mal passieren würde – nur daß eben die „Deprecated“-Meldungen genau das eben angekündigt hatten.

Gewissenhafte Entwickler würden nun eine sofortige Modernisierung ihres ganzen Code in Angriff nehmen, und zwar mit höchster Priorität. Wenn man allerdings zigtausende oder hunderttausende Codezeilen hat, ist das ein Riesenaufwand, auch ein zeitlicher.

Um trotzdem irgendwas kompilieren zu können, versuchen einige daher, auf irgendeinem Wege alte Versionen ihrer Abhängigkeiten zu installieren. Noch viel mehr Entwickler tun das aber, um die Code-Modernisierung entweder möglichst lange aufzuschieben oder ganz vermeiden zu können. Natürlich bringt auch das nur etwas bei statischen Builds, die die Abhängigkeiten nur zum Kompilieren brauchen und hinterher ohne diese Abhängigkeiten laufen. Ansonsten wäre das Ganze nämlich allmählich auch bei den Nutzern nicht mehr lauffähig.

Irgendwann kommt man dann aber an einen Punkt, an dem die alten Versionen der Abhängigkeiten des eigenen Code auf der eigenen Maschine nicht mehr installierbar sind, weil ihre eigenen Abhängigkeiten nicht mehr da sind bzw. per Update auf eine zu neue Version gebracht werden. Selbst dann gibt’s Entwickler, die schlicht und ergreifend ihre Maschine, auf der sie entwickeln, einfach nicht mehr updaten. Nicht, daß sie sich dann endlich mal dran machen würden, ihren Code auf Stand zu bringen. Natürlich nicht, denn seit aus „deprecated“ „nicht mehr unterstützt“ wurde, hat sich die Menge an eigentlich nicht mehr unterstütztem Code nicht verringert, sondern vermehrt, weil auch der Entwickler sich nicht aufgeschlaut hat, wie man’s denn heute macht.

Paradebeispiel Python

Singularity ging letztlich vermutlich an zwei Abhängigkeiten zugrunde. Die eine ist die GNU Compiler Collection, kurz gcc, die andere Python. Der Python-Anteil im Singularity-Code macht zwar nur 0,6% aus, aber auch die können sich quer stellen.

Schon das ganze Jahrzehnt über gibt es Riesenärger mit uraltem Python-2-Code, von dem irgendetwas abhängt, den auf Python 3 zu bringen aber wie ein unmögliches Unterfangen wirkt. Eigentlich wäre das Migrieren von relativ aktuellem Python-2-Code, also auf dem Stand von Python 2.7, nach Python 3 nicht so überwältigend schwierig. Aber wenn etwas bis heute auf Python 2 basiert, dann basiert es wahrscheinlich auf einer ziemlich alten Version von Python 2, also Python 2.5 oder älter, das noch keine Python-3-Bestandteile hat. Und wieder hat sich niemand je die Mühe gemacht, den Code zu modernisieren, weil er ja auch unter Python 2.7 wunderbar lief. Allen „Deprecated“-Meldungen zum Trotze.

Calibre zum Beispiel, eine E-Book-Verwaltung, ist von 2006, also aus der Zeit von Python 2.5 und somit der Zeit vor Python 3. Python 3.0 war im Dezember 2008 erschienen; zeitgleich kam Python 2.6 raus, das schon Elemente von Python 3 enthielt. Schon im Juni 2009 kamen Python 3.1 und Python 2.7 hinterher. Seitdem wurde aber höchstwahrscheinlich am Bestandscode von Calibre genau gar nichts modernisiert, nicht nach Python 3.1, nicht mal nach Python 2.7.

Auch noch 2008 kündigte die Python Foundation an, die Unterstützung von Python 2 im Jahr 2015 einzustellen. Python-Entwickler hatten sechs Jahre Zeit, ihre Projekte auf Stand zu bringen. Sehr viele haben genau gar nichts gemacht. Anfangs hatten sie keine Eile, dann vergaßen sie es ganz einfach und entwickelten mitunter lustig auf dem vollkommen veralteten Stand von Python 2.5 oder älter weiter, und als der Termin vor der Tür stand, hätte die Zeit nicht mehr gereicht. Das betraf durchaus wichtige, kritische Sachen, auf die nicht verzichtet werden konnte. Also wurde der Support von Python 2 bis 2020 verlängert. Dann sollte aber Ende sein.

Einige drückten nun auf die Tube. Spätestens ab 2018 saßen ihnen einige Linux-Distributionen im Nacken, die sagten, wenn sie nicht auf Python 3 gehen, fliegen ihre Projekte raus.

Schließlich fingen 2020 Linux-Distributionen an, das ab Jahreswechsel 2019/2020 offiziell nicht mehr unterstützte Python 2 aus ihren Softwarequellen zu entfernen. Damit mußten natürlich auch diejenigen Pakete aus den Quellen geworfen werden, die von Python 2 abhingen. Die Entwickler wurden angeschrieben; sie sollten entweder ihre Sachen schleunigst auf Python 3 bringen, oder die werden aus den Quellen entfernt. Einige reagierten wieder erst, als große Distributionen ankündigten, ihre Kreationen aus Versionen mit Langzeitunterstützung (Debian stable, Ubuntu LTS etc.) zu entfernen.

Das betraf letztlich nur noch sehr wenige Projekte. Aber Calibre betraf es sehr wohl. Der einzige Entwickler fing daraufhin an zu jammern, daß Calibre über eine halbe Million Codezeilen auf Python-2-Stand hatte, die könne er nie und nimmer auf Python 3 bringen. Das klang schon sehr danach, als wenn das ganze Ding tatsächlich immer noch praktisch komplett auf Python-2.5-Stand war, also genau überhaupt nichts aus Python 3 eingebaut hatte. Und der Entwickler schlug vor, er könne statt dessen die Weiterentwicklung von Python 2 übernehmen, dann könnten die Distributionen das weiter in ihren Quellen behalten, und er bräuchte Calibre nicht aufwendig zu sanieren. Das schien ihm wirklich der geringere Aufwand zu sein. Allerdings lehnten die Distributionen das ab.

Letztlich konnte Calibre nur weiter bestehen, indem es bis September 2020 doch noch auf Python 3 aktualisiert wurde. Daran wirkten wohl einige Freiwillige mit. Außerdem wurden in diesem Zuge den Entwicklern von Plugins, die immer noch auf Python 2 aufbauten, Pistolen auf die Brüste gesetzt: Wenn die nicht auch auf Python 3 aktualisieren, fliegen ihre Plugins raus. Einige Plugins, die schon längst nicht mehr weiterentwickelt wurden, sind wohl tatsächlich geflogen.

Auch wenn bei Singularity nun der gesamte Python-Anteil auf dem Stand von Python 2.5 sein, also keinerlei Spuren von Python 3 enthalten sollte, ist Python längst nicht das größte Hindernis. Das ist vielmehr gcc, denn Singularity ist größtenteils in C++ geschrieben.

Extremfall gcc

Auch C++ ist nicht TeX, wo 46 Jahre alter Dokumentencode heute noch kompiliert und das daraus resultierende Dokument haargenau so aussieht, wie wenn es vor 46 Jahren kompiliert worden wäre. Es ist auch nicht LaTeX, wo das mit einer Zeitdifferenz von 40 Jahren noch funktioniert. C++ entwickelt sich nicht nur weiter, es baut auch mal Sachen um und schmeißt alte Sachen raus.

Das heißt: Knapp vier Jahrzehnte alter C++-Code kompiliert heutzutage nicht mehr unbedingt. Und schon zehn Jahre alter Code kompiliert heute nicht mehr, wenn er nur ausgefuchst genug ist.

Genau deshalb gibt es ja „Deprecated“-Meldungen. Kaum ein Entwickler folgt irgendeiner Mailinglist, die Änderungen in Compilern ankündigt. Aber was beim Kompilieren passiert, das sehen die meisten. Also wird genau da darauf hingewiesen, daß Teile des Code so veraltet sind, daß das schon kritisch wird und schleunigst behoben werden sollte. Blöderweise ignorieren Entwickler meistens kleinere Mengen an „Deprecated“-Meldungen als harmlos und zu vernachlässigen. Und wenn die Meldungen sich häufen, wird es ihnen zuviel Arbeit, endlich was dagegen zu machen.

Durch sein Inertia-Erbe ist der Code von Singularity zu erheblichen Teilen auf dem Stand von Mitte der 2000er, also bestenfalls dem von C​+​+​03. Auch dieser Code wurde nie auf einen neueren Stand gebracht.

Der C++-Compiler in der Collection heißt g++. Mit g++ 4 war der Code noch kompilierbar, wobei wahrscheinlich neuere Versionen jede Menge „Deprecated“-Meldungen ausgaben. Aber schon der g++ 5 konnte den Code nicht mehr in etwas Ausführbares umsetzen.

gcc 5 kam schon im April 2015 raus, aber Singularity wurde auf einem Ubuntu-LTS-Rechner kompiliert. Ubuntu 14.04 LTS „Trusty Tahr“ kam noch mit gcc 4.8.2. Mit dem Upgrade auf Ubuntu 16.04 LTS „Xenial Xerus“ wurde das aber ersetzt durch gcc 5.3.1. Und schon war Singularity nicht mehr kompilierbar. Das war schon vor gut neun Jahren.

Statt jetzt aber den veralteten Code auf Vordermann zu bringen, ging man einen einfacheren Weg – und bastelte irgendwie wieder gcc 4 auf die Maschine drauf. Aber nicht, um sich für die Code-Modernisierung die nötige Zeit zu verschaffen, sondern wohl eher in der Hoffnung, damit den Code überhaupt nie modernisieren zu müssen. Dahinter stand auch die Hoffnung, daß es bis in alle Ewigkeit möglich sein würde, gcc 4 unter Ubuntu zu installieren.

Nichts geht mehr

Ziemlich genau vier Jahre später wurde Singularity das letzte Mal erfolgreich kompiliert, und zwar immer noch unter demselben alten Ubuntu „Xenial“. Das war im Frühjahr 2020. Inzwischen waren Ubuntu 18.04 LTS „Bionic Beaver“ und Ubuntu 20.04 LTS „Focal Fossa“ erschienen. Es dürfte klar sein, warum der Rechner, auf dem Singularity kompiliert wurde, nicht auf eine der beiden Versionen upgegradet wurde. Vielleicht hatte man festgestellt, daß die alten gcc-4-Pakete schon unter „Bionic“ nicht mehr installierbar waren.

Normalerweise hätte spätestens 2018 die Aussicht, daß gcc 4 irgendwann nicht mal mehr nachinstalliert werden kann, auch nicht aus losen Paketdateien, der Tritt in den Hintern sein müssen, der dazu hätte führen müssen, den Code von Singularity endlich auf einen Stand zu bringen, der nicht schon seit mindestens drei Jahren völlig veraltet war. Passiert ist aber wieder genau gar nichts. Man hatte ja Ubuntu „Xenial“, das lief, da war gcc 4 installiert, Singularity kompilierte, alles war gut.

Wie gesagt, bis Frühjahr 2020. Da wurde noch einmal eine neue Release-Versionen kompiliert, 1.8.9, die erstmals Bakes-on-Mesh neue Beta-Versionen kompiliert. Etwas später folgten ein paar neue Beta-Versionen. Wahrscheinlich ist dann irgendwas mit dem Rechner passiert, auf dem kompiliert wurde. Zu diesem Zeitpunkt dürfte das der einzige noch verfügbare Rechner mit Ubuntu „Xenial“ gewesen sein, auf dem also gcc 4 installierbar war.

Aktuell war damals ja Ubuntu „Focal“, das gcc 9.3.0 mitbrachte und als erstes Ubuntu LTS kein Python 2 mehr. Der Support für Ubuntu „Xenial“ lief noch bis April 2021, aber ich glaube nicht, daß Ubuntu für diese alte Version noch Images zum Installieren zur Verfügung stellte. Hätte also der Rechner, auf dem Singularity kompiliert wurde, neu aufgesetzt oder durch eine andere Maschine ersetzt werden müssen, hätte kein Ubuntu mehr installiert werden können, mit dem Singularity hätte kompiliert werden können.

Ein mögliches Szenario ist also, daß irgendetwas mit dem Entwicklungsrechner bzw. dem Rechner, auf dem kompiliert wurde, passierte. Irgendetwas, das die Weiterverwendung der alten Ubuntu-Installation unmöglich machte, z. B., daß die Festplatte ihren Geist aufgab.

Wie auch immer: Der Rechner stand so, wie er war, nicht mehr zur Verfügung. Es brauchte Ersatz. Dieser Ersatz hätte aber Ubuntu „Xenial“ von 2016 als System gebraucht. Schon 2020 hätte man das Problem gehabt, daß man „Xenial“ nicht mehr hätte installieren können, sofern man kein entsprechend altes Installationsmedium mehr hatte und auch kein ISO-Image, um eins zu bauen. Und wer bewahrt so etwas auf? Schlimmstenfalls hatte man auch die gcc-4-Pakete verloren oder verschlampt und konnte die auch nirgendwo mehr herunterladen, weil Ubuntu „Trusty“, von dem sie kamen, seit 2019 nicht mehr unterstützt wurde.

So hatte man keinen Rechner mehr, auf dem Singularity hätte kompiliert werden können. Man hatte auch keine Möglichkeit mehr, einen Rechner aufzusetzen, mit dem man Singularity hätte kompilieren können. Schon die eh notwendige Weiterentwicklung, um mit Neuerungen in und neuen Anforderungen von Second Life Schritt zu halten, schaffte man 2020 gerade noch so mit Ach und Krach. Selbst die Website war damals schon in Teilen veraltet; das Versprechen, die Singularity-Erklärseite auf den damals aktuellen Stand von Version 1.8.9 zu bringen, wurde nie eingelöst; sie ist bis heute auf dem Stand von Singularity 1.7.0. Da war also auch nicht daran zu denken, den Code von Singularity so aufzufrischen, daß er wieder kompilierbar wäre.

Heutiger Stand

Inzwischen ist 2024. Die letzte Ubuntu-Version, auf der Singularity hätte kompiliert werden können, kam vor zehn Jahren heraus und wird seit fünf Jahren nicht mehr unterstützt. Auch andere Linux-Distributionen unterstützen gcc 4 schon lange nicht mehr. Und selbst die aktuellsten Singularity-Binaries starten, obwohl sie weitgehend statische Builds ohne großartige Abhängigkeiten sind, unter mehr und mehr Linux-Distributionen inzwischen überhaupt nicht mehr.

Vielleicht hätte man noch eine Chance, Singularity unter Arch Linux oder einem seiner Derivate zu kompilieren, ohne den Code anfassen zu müssen. Im Arch User Repository gibt es sehr viele Sachen auch noch in wirklich uralten Versionen, so auch gcc 4.9 und Python 2.7.18. Aber das wäre wirklich für sehr weit Fortgeschrittene – und der Sprung von Ubuntu nach Arch wäre heftig – und würde auf eigene Gefahr laufen, weil beides von den jeweiligen Anbietern schon ewig nicht mehr unterstützt wird.

An eine Weiterentwicklung von Singularity wäre aber selbst dann nicht zu denken. Inzwischen ist sehr viel passiert. Singularity unterstützt noch Windlight, das inzwischen nicht nur in Second Life, sondern auch fast im gesamten Hypergrid durch EEP ersetzt wurde; das wiederum unterstützt Singularity noch nicht. Von Physically-Based Rendering will ich gar nicht erst anfangen.

Es wäre allerdings reiner Wahnsinn, das in den Singularity einbauen zu wollen, wie er jetzt ist. Schon vor acht Jahren ging der Code von Singularity nur noch mit Tricks und unter Verwendung eines veralteten Compilers zu kompilieren. Wenn überhaupt, muß der ganze Code als allererstes um mehr als ein Jahrzehnt modernisiert werden. Ansonsten wäre der Einbau neuer Features wie ein nagelneuer Anbau an einem Gebäude, das seit acht Jahren wegen Baufälligkeit gesperrt ist.

#OpenSim #SecondLife #FürFortgeschrittene #Software

Was ist PBR eigentlich?

Die grundlegendste Frage, die sich hier stellt, ist: Was ist PBR eigentlich, und was macht es?

PBR ist der Nachfolger des Erweiterten Beleuchtungsmodells (Advanced Lighting Model, kurz ALM). Das gibt es an sich schon viele Jahre. Es ändert nicht nur das Verhalten des Lichts, sondern es macht auch Schattenwurf, Ambient Occlusion und andere Tricks möglich.

Zwei andere Features, die vom ALM verbessert werden, bemerkt man in OpenSim nur selten, weil sie gerade bei den riesigen Mengen an aus Second Life geklautem Content beim Wiederzusammenbauen nicht wieder eingebaut wurden. Das eine sind Normal Maps, etwas ähnliches wie Bump Maps, die Oberflächenunebenheiten generieren können, ohne das 3D-Modell darunter komplexer zu machen. Das andere sind Specular Maps, die bestimmen, wo eine Oberfläche wie stark glänzen kann. Ich glaube, vielen ist gar nicht bewußt, daß Oberflächen in OpenSim überhaupt glänzen können, zumeist auch, weil sie nie an glänzenden Oberflächen vorbeikommen.

Das klingt zunächst einmal ganz toll. In der Praxis ist das ALM aber hoffnungslos veraltet. Es wird eh nur von wenig Content unterstützt. Und seien wir mal ehrlich: Wenn beim ALM der Glanz einer Oberfläche auf „gering“ gestellt ist, dann ist das nicht seidenmatt, sondern Plastikglanz. Früher war das mal spektakulär; heute gibt es nur noch wenige wie Luna Lunaria, die das gut aussehen lassen können, weil es einfach nicht mehr zeitgemäß ist.

PBR ist, was aktuelle Videospiele anwenden. Es ist auch Bestandteil des glTF-Standards, der sich generell in neuen virtuellen 3D-Welten mehr und mehr durchsetzt. Zu dem soll Second Life kompatibel werden, was bedeutet, daß auch OpenSim nachziehen wird.

PBR ist eine Abkehr von solchen generischen Tricks wie oben erklärt. PBR ist keine grobe Emulation, sondern Simulation. PBR hat als Ziel, reale Materialien und reale Oberflächen virtuell sehr viel realistischer darzustellen. Metall soll wie Metall wirken, Holz wie Holz und nicht mehr wie unrealistisches Plastik mit Aufdruck.

Im Second-Life-Wiki gibt es ein schönes Vergleichsbild: Links sieht man das ALM, rechts PBR. Auf einmal wirkt Metall wirklich wie Metall, Glas wie Glas und der seidenmatte Lack der Lampe wie seidenmatter Lack. Und wenn man mal bei den Metallbügeln genau hinguckt, sieht man: Die reflektieren tatsächlich die Umgebung, also die Bodentextur, das Wasser und den Himmel. Und wenn man ganz genau hinguckt, sieht man: Die reflektieren sogar die anderen Teile der Lampe! Die glänzen nicht mehr irgendwie. Das ist ein Look, den einige vielleicht noch von früher von PoV-Ray kennen oder vielleicht noch von den Renderingfunktionen in professionellen 3D-CAD-Systemen. Nur mußte damals noch die Einkern-CPU minutenlang unter Vollast laufen, um ein einzelnes Bild mit einer Auflösung von 800×600 Pixeln zu rendern, auch weil man das noch nicht auf der GPU konnte. Ganz so superdetailliert wie damals ist PBR nicht, dafür aber läuft es in Echtzeit.

Das Ganze funktioniert unter anderem mit einem komplett neuen Beleuchtungsmodell. Die Art und Weise, wie sich Licht in-world verhält und mit Oberflächen interagiert, wird nun detailliert berechnet. Es geht z. B. nicht mehr darum, daß etwas glänzt, sondern wie es glänzt. Es gibt keinen generischen Irgendwie-Ganz mehr, sondern Reflexionen. Im Zusammenhang mit PBR wird auch gern genannt, daß damit sogar Spiegel möglich sein werden. Das heißt, superrealistische Spiegel, in denen ein Avatar sich detailliert selbst sehen kann, gehen auch mit PBR nicht, aber Spiegel können Avatare in PBR reflektieren.

Änderungen beim Content

Um PBR wirklich zur Geltung zu bringen, braucht es allerdings auch entsprechenden Content. PBR kann nicht auf vorhandene Sachen seine realistischen Materialeffekte anwenden, nicht auf Objekte, die die alten Specular Maps und Normal Maps haben – das System wird jetzt als „Blinn-Phong“ bezeichnet –, und schon gar nicht auf Objekte, die nicht einmal das haben.

Bisheriger Content wird natürlich auch mit PBR weiterhin angezeigt, und der Glanzeffekt, so vorhanden, verbessert sich im Vergleich zu heute, weil auch ältere glänzende Objekte mit Reflexionen arbeiten.

Um PBR wirklich zur Geltung zu bringen, braucht es allerdings zusätzliche Texturen, und zwar vier davon, von denen drei die Oberflächenbeschaffenheit beeinflussen. Neu ist dabei auch, daß die Glanztextur, also die bisherige Specular Map, jetzt nicht mehr nur schwarz-weiß kann, wobei heller gleich mehr Glanz ist, sondern mittels Farben auch die Art des Glanzes beeinflußt.

PBR hat seinen eigenen Satz an Texturen. Das heißt, die eine Textur, die man von den meisten Objekten kennt, die braucht es für PBR noch einmal separat plus die drei Materialtexturen.

Eine und dieselbe Oberfläche kann in Zukunft bis zu sieben Texturen haben. Zum einen sind das der eigentliche „Aufdruck“ plus die beiden Blinn-Phong-Texturen, also Normal Map und Specular Map. Die werden nur gerendert, wenn es kein PBR gibt, und von PBR-Viewern im PBR-Modus ignoriert. Und das Rendern der Normal Map und der Specular Map läßt sich im Viewer ja heute schon abschalten, was auch in Zukunft möglich sein wird. Dazu kommt noch einmal der eigentliche „Aufdruck“ plus die drei Materialtexturen für PBR. Die werden umgekehrt von PBR-Viewern im PBR-Modus gerendert und ansonsten ignoriert, zumal Nicht-PBR-Viewer mit diesen Texturen eh nichts anfangen können.

Zu keinem Zeitpunkt muß der Viewer also sieben Texturen wuppen. Und PBR-Content bremst Nicht-PBR-Viewer bzw. PBR-Viewer mit abgeschaltetem PBR nicht mehr aus als gleichartiger Nicht-PBR-Content.

Allerdings wird Nicht-PBR-Content mit PBR nicht mehr haargenau so aussehen wie heute. Zum einen liegt das daran, daß PBR mit mehr Farbdynamik arbeitet. Es wird also am Ende alles etwas farbenfroher aussehen, wobei das auch vom Bildschirm abhängen kann.

Zum anderen, wie schon erwähnt, reflektiert PBR nicht mehr irgendwas, sondern die tatsächliche Umgebung. Draußen wird höchstwahrscheinlich vieles blaustichig wirken. Das liegt schlicht und ergreifend daran, daß es das Blau des Himmels reflektiert. Das muß man wissen. Dann sollte man aber auch nicht versucht sein, den vermeintlichen Blaustich in den Texturen wieder zu korrigieren. Das ist dasselbe wie extrem langbeinige Avatare, bei denen die perspektivische Verzerrung durch die hoch liegende Kamera ausgeglichen wurde.

Umgekehrt ist PBR-Content nicht automatisch voll mit Nicht-PBR, also mit Nicht-PBR-Viewern und PBR-Viewern mit abgeschaltetem PBR, kompatibel. Dafür müssen die Contentschöpfer selbst sorgen, indem sie auch die ein bis drei Texturen für ohne PBR einbauen. Fehlen diese, wird PBR-Content ohne PBR einfach grau dargestellt.

Tabelle 1: Was ohne bzw. mit PBR korrekt dargestellt wird

Auswirkungen in-world

Übrigens wird PBR auf praktisch allen Oberflächen funktionieren – bis hin zur Bodentextur. Mit PBR wird die nicht mehr wie aufgemalt oder, salopper formuliert, „hingekotzt“ aussehen. Weil zeitgleich mit PBR auch Texturen mit einer Auflösung von 2048×2048 Pixeln eingeführt werden, werden Bodentexturen in entsprechend geeigneten Viewern auch ohne PBR besser aussehen, mit PBR erst recht. Allerdings bin ich mir nicht sicher, ob es auch für Bodentexturen Nicht-PBR-Fallbacks geben wird. Es kann also sein, daß auf Sims, die auf PBR optimiert sind, der Sim-Untergrund grau bleibt, wenn man kein PBR nutzt.

Wer aber seine Sim für PBR optimieren will, muß sich generell mehr anstrengen und einige alte Gewohnheiten ablegen. Eine davon, die die weit überwiegende Mehrheit der Simbauer an den Tag zu legen scheint, ist, Licht komplett zu vernachlässigen. Viele Simbauer haben ihre Viewer ja permanent auf Mittag geschaltet, weil der Tag-und-Nacht-Wechsel beim Bauen stört, und die Einstellung dann vergessen. Die wissen überhaupt nicht, wie ihre Sim bei anderem Licht aussieht. Das erkennt man auch daran, daß Sachen bei Nacht hell leuchten, die eigentlich gar nicht leuchten sollten, z. B. Straßen, Pflanzen oder Häuser. Etliche scheinen generell die Grafikeinstellungen ihrer Viewer dauerhaft heruntergeschraubt zu haben; vielleicht haben sie sogar die Atmosphären-Shader aus.

Wenn man dann doch die eigene Sim im Dunklen sieht, entscheidet man entweder, daß das in Ordnung geht, weil man ja noch etwas sieht, weil es im Standard-Tageszyklus nie richtig realistisch finster wird. Aber selbst wenn es doch zu dunkel wird, installiert fast niemand Beleuchtung. Statt dessen wird alles, was zu dunkel ist, auf „ganz hell“ geschaltet, also das Shading komplett abgeschaltet, so daß es dauerhaft hell leuchtet.

Ich glaube, gerade auch viele OpenSim-Nutzer wissen gar nicht, daß es in OpenSim Lichtquellen geben kann, die ihre Umgebung tatsächlich ausleuchten können – also, von der Sonne und eventuell noch dem Mond abgesehen. Das liegt nicht unbedingt nur daran, daß sie im Viewer alle Lichtquellen abgeschaltet haben, die abzuschalten gehen. Vielmehr liegt es daran, daß sie auch auf anderer Leute Sims selten bis nie Lichtquellen sehen, weil da ganz einfach gar keine installiert sind.

Straßenlaternen beispielsweise sind weit überwiegend reine Deko. Wenn man ganz viel Glück hat, glühen die Lichtquellen. Meistens sind sie komplett funktionslos, und nichts leuchtet, als wären sie kaputt. Nur in ganz seltenen Fällen erhellen sie tatsächlich ihre Umgebung. Dazu haben über 99% der Gebäude in OpenSim keinerlei wie auch immer geartete Innenbeleuchtung.

Das liegt allerdings alles auch daran, daß Beleuchtung fast immer Eigeninitiative erfordert. Leuchten gibt es viele. Aber nur die wenigsten davon geben auch Licht ab. Von denen, die in jüngster Zeit aus Second Life geklaut worden sind und auf den brandheißen Freebie-Sims angeboten werden, die nur den neuesten heißesten Scheiß anbieten, dürfte das gar keine tun – wenn es da überhaupt welche gibt. Die Kundschaft legt keinen Wert drauf, und es ist Mehraufwand, weil es nicht mit aus Second Life exportiert werden kann und per Hand eingebaut werden muß. Also baut man es nicht ein.

Noch dazu gibt es für drinnen jede Menge Tischlampen, auch einiges an Stehlampen. Deckenlampen sind aber schwer zu finden, wohl auch, weil die allermeisten Gebäude viel zu hohe Decken haben, als daß Deckenlampen noch zu sehen wären. Da ist also langes Suchen oder Eigenbau angesagt. Und je neuer „Leuchtelemente“ sind, vor allem, wenn sie aus Second Life kommen, desto geringer ist die Chance, daß sie auch tatsächlich leuchten können.

Sehr viele Gebäude aus Second Life haben ja fest installierte Deckenleuchten. Die funktionieren aber erst recht nicht. Erstens hätte die Beleuchtung wie gesagt nach dem Import händisch eingebaut werden müssen. Zweitens wirkt sich jede Lichtquelle ein bißchen auf die Performance aus. Und drittens sind genau deshalb die allermeisten fest eingebauten Deckenbeleuchtungen auch in Second Life funktionslose Dummys. Das ist besonders dann offenkundig, wenn auf Boden- oder gar Wandtexturen das Licht-und-Schattenspiel der Sonneneinstrahlung von draußen aufgemalt ist. Wo allerdings schon funktionslose Deckenlampen hängen, baut beinahe kein Simbauer jemals tatsächlich nachträglich Lichtquellen ein.

Nicht nur allerdings sieht heute schon jede Sim im Dunklen viel besser aus, wenn sie beleuchtet ist. Nicht nur werden gerade Gebäude im Dunklen benutzbarer, wenn sie beleuchtet sind. Nicht nur sieht das sehr viel besser aus als ein Gebäude, das mitsamt Inneneinrichtung auf „ganz hell“ geschaltet ist. Sondern gerade PBR steht und fällt mit Beleuchtung.

Bei PBR geht es ja um Licht und dessen Verhalten. Ohne Lichtquellen gibt es aber nur das Ambient-Umgebungslicht, das standardmäßig immer und überall da ist, je nach Tageszeit mal mehr, mal weniger. Allerdings kann PBR damit wenig anfangen, und die Auswirkung von Ambient-Licht wird in PBR auch reduziert. Was mit PBR draußen also spektakulär aussieht, sieht in Gebäuden grau und stumpf aus, weil mit PBR im Gegensatz zu heute mit und ohne ALM das Sonnenlicht nicht mehr durch Gebäudewände und -decken dringt und in der Hütte sonst keine Lichtquelle installiert ist.

Höchstwahrscheinlich – hoffentlich – wird PBR mit einer häßlichen Nebenwirkung des ALM aufräumen. Und das sind Oberflächen, zumal völlig undurchsichtige, undurchscheinende Oberflächen wie Ziegelmauern, die von einer Lichtquelle von hinten beleuchtet werden. Das führt dann dazu, daß bei einem Gebäude, das von innen beleuchtet ist, auch die Außenmauern stellenweise leuchten.

Irgendwo habe ich mal gelesen, daß, wenn, dann ganze Sims tutto kompletto mit allem drauf auf PBR ausgelegt werden müssen, weil es sonst kacke aussieht, weil selbst das Aufeinandertreffen von PBR und Blinn-Phong zu inkonsistent wirkt. Mal ehrlich – selbst heute gibt es schon Sims, auf denen aufwendig gestaltete Objekte mit dem vollen Blinn-Phong-Programm auf Gebäude mit aufgemalten Schlagschatten treffen. Und in OpenSim kann daneben durchaus ein Prim-Gebäude auf dem Stand von 2007 mit gekachelten Meterwaretexturen stehen. Da jammert niemand, weil man es gar nicht anders kennt.

Abschied vom alten Beleuchtungsmodell

Im Zuge der Einführung von PBR haben Linden Lab und das Firestorm-Team sich darauf geeinigt, mit Version 7 des offiziellen Second-Life-Viewers und des Firestorm das ganz alte Beleuchtungsmodell abzuschaffen und ALM permanent zu aktivieren. Das hat nicht so sehr den Hintergrund, daß dann nicht drei Beleuchtungsmodelle gepflegt werden müssen.

Tabelle 2: Verfügbare Beleuchtungs- und Renderingmodelle je nach Viewer-Version

Vielmehr geht es darum, Contentschöpfer davon abzubringen, ihre Kreationen vermeintlich auf absolute Kartoffelrechner auszulegen, auf denen mit ALM und Bumpmapping keine vernünftigen Frameraten möglich sind, wo das also alles abgeschaltet ist. Die Sache ist nur die: Die Produkte sollen natürlich trotzdem toll aussehen, und zwar auf jeder Hardware. Dazu gehören auch Oberflächendetails, denn die Konkurrenz hat die ja auch. Und die sollen bitteschön auch noch auf der letzten Kartoffel zur Geltung kommen.

Wenn man aber keine Normal Maps verwenden will, weil zuviele potentielle Kunden zu schwache Maschinen haben, um sie darstellen zu lassen, gibt es dafür nur eine Lösung. Und die ist, die Oberfläche selbst detaillierter zu modellieren, also, die ganzen Unebenheiten und Details tatsächlich ins Mesh einzuarbeiten. Allerdings werden dadurch die Modelle sehr viel komplexer, was sich letztlich negativ auf die Performance auf allen Maschinen auswirkt – bis hin zu Assetserver und Regionserver.

Um diese Unsitte zu bekämpfen, soll sowohl im offiziellen Second-Life-Viewer als auch im Firestorm Viewer das unterste Ende der Grafikeinstellungen abgeschafft werden. Damit soll Bumpmapping attraktiver werden als z. B. das Ausmodellieren zahlloser Schraubenköpfe mitsamt Schlitz. Das ist letztlich eine der Maßnahmen, die Linden Lab ergreift, um Second Life wieder wegzubekommen von den immer detaillierteren, immer komplexeren Meshes.

Die Performance

Eins ist ganz klar: PBR wird deutlich mehr Leistung brauchen als das ALM.

Aber: PBR-fähige Viewer, zumindest der offizielle Second-Life-Viewer und der Firestorm, werden gleichzeitig auch in die Lage kommen, mehr Leistung abzurufen als heute.

Machen wir uns nichts vor: Das ALM ist nicht unbedingt sehr performant. Gerade Windows-Nutzer, die nicht so etwas wie Rainmeter im Blick haben, sehen allerdings nicht, wie ihr Viewer ihre Maschine auslastet. Und ein halbwegs leistungsfähiger Rechner mit ein paar mehr CPU-Threads und einigermaßen Grafikpower wird tatsächlich vom Viewer kaum in Beschlag genommen.

Das liegt schlicht und ergreifend daran, daß die Viewer heutzutage in einem Punkt immer noch in den 2000er Jahren feststecken: Sie können kein Multithreading. Sie nutzen immer nur einen einzigen CPU-Thread und packen da dann alles auf einmal drauf. Und unterm Strich hängt in einem Second-Life-/OpenSim-Viewer immer noch viel von der CPU ab, und die GPU kümmert sich allenfalls um die grafische Umsetzung des Ganzen. Letztlich hat die GPU häufig schon deshalb wenig zu tun, weil der eine völlig überlastete CPU-Thread nicht damit hinterherkommt, ihr zu sagen, was sie tun soll.

Deswegen wundern sich immer wieder Leute, wenn der Einbau einer stärkeren GPU in Second Life oder OpenSim nichts brachte, weil der tatsächliche Flaschenhals das Single-Threading ist, also im Grunde die CPU-Taktfrequenz, und schon die alte GPU kaum ausgelastet war.

Die PBR-fähigen Versionen des offiziellen Second-Life-Viewers und des Firestorm werden aber multithreadingfähig. Die werden sich auf Mehrkern-CPUs über die Kerne und Threads verteilen können. Neben PBR ist ein Grund dafür, daß man sich nicht mehr auf weiter steigende Taktfrequenzen verlassen kann, die ja schon seit Jahren stagnieren. CPU-Mehrleistung kommt heutzutage nur noch aus mehr Kernen. Davon hat aber Software nichts, die eh nur mit einem Thread auf einem Kern läuft.

Die Einführung von Multithreading ist als Schritt nicht nur konsequent, sondern eigentlich längst überfällig. Für die Performance wird das ein Quantensprung sein: Schon wenn man eine AMD-Mittelklasse-CPU mit vier Kernen, also acht Threads hat, steht dem Viewer in Zukunft die achtfache CPU-Leistung im Vergleich zu heute zur Verfügung.

Wohl schon im unteren Midrange-Bereich wird der zusätzliche Berechungsaufwand durch das Multithreading aufgefangen. Wer von ALM auf PBR umsteigen will, dürfte selbst in einer PBR-lastigen Umgebung keine nennenswerten Performance-Einbußen spüren. Wer vorher kein ALM nutzte, es aber aufgezwungen bekommt, für den sollte sich performancemäßig auch nicht viel ändern, derweil aber alles schicker aussieht. Wer vorher schon das ALM aktiv hatte und dabei bleiben will, für den wird der Viewer definitiv sogar schneller. Partys werden nicht mehr so schnell zu Diashows, und gerade auf Partys gibt es wenig Anlaß, PBR zu aktivieren, so, wie heute kaum jemand auf Partys Schatten an hat. Und wenn keine Party ist, kann man vielleicht eher mal Schatten dauerhaft eingeschaltet lassen.

Ein bißchen oberhalb, und da reden wir noch nicht von High-End, kann es sogar durchaus passieren, daß der Viewer mit PBR sogar schneller wird als vorher mit ALM oder mit ALM schneller als vorher ohne. Tatsächliche High-End-Gaming-Maschinen werden von den PBR-Versionen definitiv profitieren – nicht nur optisch, sondern auch in der Performance, weil der Viewer endlich so schnell wird, wie er gemäß verbauter Hardware eigentlich schon immer hätte sein müssen.

Das bedeutet natürlich auch, daß andere Alternativviewer gegenüber dem Firestorm ins Hintertreffen geraten, wenn sie nicht auch Multithreading einführen oder schon unterstützen.

Für die Zukunft sind weitergehende Einstellungen für PBR geplant, mit denen der Leistungsbedarf detaillierter geregelt werden kann.

Von Mißverständnissen, Halbwissen und Kartoffeln

Nun kann man sich fragen: Wenn sich das alles so toll liest, dann sollte doch binnen kürzester Zeit alles und jeder auf PBR upgraden, oder? Wo ist das Problem?

Das Problem fängt damit an, daß PBR eben sehr viel mehr Rechenaufwand bedeutet. Und längst nicht jeder hat einen Rechner, der das auffangen kann.

Zunächst einmal gibt es Leute, die virtuelle 3D-Welten mit Uralt-Hardware nutzen. Eine Statistik vom August 2023 ergab, daß unter den Firestorm-Nutzern mit Laptops einer von 40 eine CPU von vor 2012 nutzte. Und wer so eine alte Maschine nutzt, der tut das nicht aus Gründen der Nachhaltigkeit, sondern der kann sich selbst einen auch nur ein bißchen neueren Gebrauchtrechner nicht leisten. Häufig sind die betreffenden Rechner schon damals keine Gamingmaschinen oder Workstations gewesen, sondern billige Lowend-Consumer-Maschinen, die schon neu kaum für virtuelle 3D-Welten geeignet waren. Deren Nutzer haben wahrscheinlich schon geflucht, als der Schalter für die Darstellung von Mesh entfernt wurde.

Ich kann mich noch daran erinnern, wie das Firestorm-Team die Unterstützung von 32-Bit-Windows abkündigte. Es war damals tatsächlich einiges an Gejammer zu hören von Leuten, die sagten, daß sie dann bald Second Life nicht mehr nutzen können werden, weil sie noch eine uralte 32-Bit-Kiste haben und sich seitdem nie auch nur einen gebrauchten Ersatzrechner für ca. 200 € leisten konnten. Und auf solchen absoluten Kartoffelrechnern nutzen sie dann Second Life und/oder OpenSim, und zwar nicht etwa mit dem Radegast-Textviewer, sondern mit dem offiziellen Second-Life-Viewer oder dem Firestorm.

Generell sieht es so aus, daß mindestens jeder zehnte Second-Life-Nutzer einen vergleichsweise alten Rechner nutzt, der von vornherein nur als Büro- oder Surfmaschine gebaut worden war. Die Geräte haben dann mitunter nur zwei CPU-Kerne, höchstens 4 GB RAM und einfache Intel-GMA-Onboardgrafik. In den allermeisten Fällen sind es Laptops, eine Geräteklasse, die spätestens seit den frühen 2010ern im PC-Bereich die untersten Preiskategorien belegt. Aber selbst wer einen neuen Rechner braucht, greift so manches Mal zu einem Billig-Lowend-Notebook – immer noch mit der Intention, darauf Second Life zu nutzen. Wohlgemerkt, mitunter käme man zum selben Preis an eine gebrauchte Mobilworkstation als massenhaft verfügbarer Leasingrückläufer mit massivem Preisverfall, die hier immer noch leistungsfähiger wäre.

Und weil OpenSim inzwischen längst zu Second Life für Leute, die sich Second Life nicht leisten können, geworden ist, ist der Anteil untermotorisierter Rechner in OpenSim höchstwahrscheinlich noch höher als in Second Life.

Hier hat sich längst eine laute Front gegen PBR gebildet. PBR wird mit „Peanut Butter Rendering“ übersetzt und als vollkommen unnötiger Schnickschnack bezeichnet, den kein Mensch braucht, der aber die Viewer unbenutzbar macht – und zwar auch, wenn es gar nicht eingeschaltet ist. Second Life läßt ja immer nur die drei neuesten Versionen von Drittviewern zu. Das heißt, die Zeit, die man noch hat, um Second Life mit Viewern ohne PBR zu nutzen, in denen das ALM noch abschaltbar ist, geht allmählich zu Ende. Wenn die dritte Firestorm-Version mit PBR raus ist, ist sie vorbei, und man hat nur noch die Wahl zwischen ALM und PBR. So manch ein User sieht keine Chance, bis dahin auch noch an einen leistungsfähigeren Gebrauchtrechner zu kommen. Und überhaupt ist angeblich jede neue Firestorm-Version nachweislich immer deutlich langsamer geworden als die vorige.

Dazu kommt allerdings die Annahme, daß man für Second Life und OpenSim in naher Zukunft absolute High-End-Maschinen in weit vierstelligen Preisbereichen brauchen wird, weil PBR soviel Rechenpower brauchen wird. Das hat zwei Gründe. Der eine ist, daß das Firestorm-Team selbst von „High-End-Rechnern“ schreibt, damit aber nicht dieselben Leistungsklassen meint wie die meisten anderen Leute. Und überhaupt hat die Aussage, daß auch Cyberpunk 2077 PBR verwendet, zur Implikation geführt, daß auch Second Life und OpenSim in naher Zukunft dieselben aberwitzigen Hardwareanforderungen wie Cyberpunk 2077 haben werden.

Der andere ist, daß völlig unbekannt ist, daß PBR-fähige Viewer auch mehr Hardwareleistung abrufen können werden. Viele Nutzer wissen nicht einmal, daß ihr Viewer die ganze Zeit nur auf einem einzigen CPU-Thread läuft und trotz womöglich vernehmlich fönenden CPU-Kühlerlüfters ihre Maschine nur zu einem Bruchteil ausgelastet ist. Wenn irgendwas am Anschlag läuft, ist das nur der eine Thread. Aber das weiß kaum jemand. Entsprechend weiß auch kaum jemand, daß sich die PBR-Versionen von Second-Life-Viewer und Firestorm über die CPU verteilen und ihren Leistungsbedarf aus mehreren Threads holen können werden.

Parallele zu BoM und Ausblick

Meine Prognose gerade für OpenSim ist, daß die Einführung von PBR ganz ähnlich sein wird wie die von Bakes-on-Mesh.

Schon eine ganze Weile vorher wird in Second Life darüber geredet. BoM wurde 2018 zum Thema, PBR 2022. Im Jahr darauf kam die allmähliche Einführung in Second Life und, weitestgehend unbemerkt und eher experimentell, in OpenSim. Tatsächlich gab es in OpenSim schon 2019 die ersten ein, zwei geforkten Meshbodys aus der Ruth-2.0-Familie mit BoM, während in Second Life schon die offizielle Umstellung der etablierten Bodys auf BoM angelaufen war. In OpenSim kam im Mai 2022 Roth2 v2 von den offiziellen Maintainern des RuthAndRoth-Projekts und im Juli, leider für viele der erste BoM-Body in OpenSim überhaupt, Athena 6.

Derweil ist PBR auf beiden Seiten immer noch sehr experimentell und noch kein Content zum Mitnehmen verfügbar, zumal zumindest vom Firestorm nur Entwicklerversionen PBR unterstützen. Meines Wissens ist der Cool VL Viewer der einzige, der PBR schon in einem stabilen Release implementiert hat.

Im Frühjahr und Sommer 2020 waren Firestorm 6.3.9 und Singularity 1.8.9 die einzigen Drittviewer und die einzigen OpenSim-Viewer, die BoM unterstützten. Zumindest der Firestorm war ein stabiler Release, aber leider so verbuggt, daß vor allem Simbauer beim Firestorm 6.0.2 blieben, der aber kein BoM konnte. Auch mit dem Aufkommen von Athena 6 und, einen Monat später, Adonis 4 setzte also noch nicht der BoM-Boom ein.

OpenSim selbst hatte im stabilen Release 0.8.2.1 erstmals grundlegende BoM-Features eingebaut. Die Skript-Unterstützung für BoM gab es aber erst seit der damals aktuellen Version 0.9.1.1, die immer eine Entwicklerversion blieb.

Zum damaligen Zeitpunkt wußten die meisten Second-Life-Nutzer und die allermeisten OpenSim-Nutzer noch gar nicht, daß BoM existiert, geschweige denn, was es kann und was es soll. Mit dem Windlight-Ersatz EEP war es ja ähnlich. Dasselbe trifft heute auch bei PBR zu, nur daß PBR hitziger diskutiert wird. In allen drei Fällen hieß bzw. heißt es häufig: „Das braucht sowieso keiner, und wie es jetzt ist, ist es sowieso besser.“ Und in allen drei Fällen wurde bzw. wird ein Umdenken nötig.

Ein wesentlicher Unterschied zwischen BoM und PBR ist, daß PBR heutzutage auf einige wenige Experimentalsims beschränkt ist und kaum von Viewern unterstützt wird. BoM betraf damals aber nicht Sims und statischen Content, sondern Avatare, die sich durch die Grids bewegten, also überall auftauchen konnten. Und während BoM-fähige Viewer verfügbar waren, war der populärste davon so verbuggt, daß er für viele unbenutzbar war und sich deshalb Viewer ohne BoM-Unterstützung noch wacker hielten.

Mit BoM ging es in OpenSim erst ab Herbst 2020 richtig los, als nach einer Pause von etwa einem halben Jahr endlich der Firestorm 6.4.13 erschien, der BoM konnte und den häßlichen Bug des 6.3.9 nicht mehr hatte. Für den Herbst 2024 wird auch mit dem Firestorm 7 gerechnet, der PBR einführen soll.

Was BoM anschob, waren vor allem die Werbekampagnen für Athena 6, Adonis 4 und Zubehör mit dem türkisen „Free Bakes on Mesh“-Logo. Einige, die sich beim Umzug in neue Grids neue Avatare bauen mußten und keinen Wert darauf lagen, daß ihre Avatare in allen Grids gleich aussahen, schwenkten gleich auf die neuen BoM-Bodys um. Frische Second-Life-Umsteiger nutzten die sowieso, weil sie meistens eh schon an BoM gewöhnt waren und nicht wieder zurück wollten. Außerdem hängten sich immer mehr Freebie-Shops Athena 6, Adonis 4 und das ganze Drumherum auf, um auf dem neuesten Stand zu bleiben.

Ähnliches könnte sich in diesem Herbst mit dem Erscheinen des Firestorm 7 wiederholen: Sobald PBR-Content in Second Life um sich greift, wird er von da umgehend geklaut und nach OpenSim geholt werden. Das wird höchstwahrscheinlich geschehen über zwei der aktuell populärsten Freebie-Sims, die sich damit weiter behaupten werden. Es wird einhergehen mit einer Werbekampagne für PBR, mit der es EvoX – eigentlich eine Marke, deren Eigentümer in OpenSim gar nicht vertreten ist – als Buzzword für den heißesten neuen Content ablösen soll. Dabei sehe ich bei zumindest einer das Risiko, daß die Sachen ohne Fallback-Texturen zusammengebaut werden, zum einen, um Zeit zu sparen und mehr Content in derselben Zeit zusammenbauen zu können, zum anderen, weil nicht bekannt ist, daß ohne PBR Fallback-Texturen gebraucht werden. Wenn der Zusammenbau selbst allerdings ohne aktives PBR im Viewer erfolgt, wird sofort auffallen, daß die Fallback-Texturen fehlen, weil die Objekte grau bleiben.

2021 gab es in Sachen BoM fast Stagnation. Mesh-Klamotten paßten ja gleichermaßen auf BoM- und Nicht-BoM-Versionen von Athena. Layer-Klamotten, die BoM benötigt hätten, hat seit ein bißchen Lingerie im Sommer 2020 fast niemand mehr geklaut. Höchstens gab es mal ein paar neue Köpfe, ein paar neue Skins und ein bißchen neues Make-up. Nach Bodys und Köpfen ohne BoM schien allmählich kein Hahn mehr zu krähen, aber die Vorteile von BoM wurden kaum richtig ausgereizt, zumal weder Athena 6 noch Adonis 4 out-of-the-box Alphamasken unterstützt.

Mit PBR wird es 2025 wahrscheinlich ähnlich aussehen wie mit BoM 2021 oder mit EvoX dieses Jahr: Auch wenn immer noch kaum einer weiß, was das eigentlich ist, wird es auf allem relevanten Content stehen und als Buzzword und Synonym für „der aktuell heiße Scheiß, den man einfach haben muß, weil man ohne komplett altmodisch ist“ gepusht werden bis zum Gehtnichtmehr. Allerdings werden die großen Anbieter jeweils ihr eigenes PBR-Logo machen.

Natürlich wird das alles stehen und fallen mit der Verfügbarkeit von PBR-Content in Second Life. In OpenSim selbst werden nur sehr wenige eigenen Content mit PBR-Unterstützung machen und ihn dann nur selbst vertreiben. Wahrscheinlich werden das die paar wenigen sein, die heute schon Blinn-Phong unterstützen, etwa Luna Lunaria im Payware-Bereich und Aaack Aardvark (Arcadia Shop) bei den Freebies.

Die Zweifler und Gegner wird es natürlich weiterhin geben. Bei BoM bestand der Widerstand eigentlich nur darin, nicht über den Firestorm 6.0.2 hinaus upzugraden. Zur Verwendung von BoM am eigenen Avatar ist ja niemand gezwungen. Das Gemoser über BoM-Avatare, die „komisch“ aussahen, weil BoM kein vollwertiges Fallback hat, ist verstummt, weil eh niemand für diejenigen, die keinen neueren Viewer installieren wollten, sich den Aufwand machen wollte, BoM wieder aufzugeben. Die wenigen, die heute noch den Firestorm 6.0.2 oder älter verwenden, dürften BoM-Avatare statt dessen händisch derendern, auch wenn sie dann auf Partys ziemlich einsam sein werden.

Bei PBR wird es anders gelagert sein. PBR wird wahrscheinlich sowohl Avatarausstattung als auch ortsfesten Content betreffen bis hin zu Bodentexturen. Bis eventuell auf die Bodentexturen ist nahezu vollwertiges Fallback möglich. Wo es kein Fallback gibt, sei es, weil technisch nicht möglich, sei es, weil jemand keine Lust auf das bißchen Mehraufwand hatte, werden die PBR-Verweigerer über den angeblich kaputten Content, die angeblich kaputte Sim oder gar das angeblich kaputte Grid mosern. Erst wenn sie nach ein paar Monaten begriffen haben, daß das mit PBR zusammenhängt, werden sie PBR noch blöder finden und noch mehr darüber meckern, um so mehr, je mehr PBR-Content ohne Fallback sich auf allen möglichen Sims und an allen möglichen Avataren ausbreitet.

Andererseits allerdings glaube ich, PBR-Content ohne Fallback wird kaum Verwendung finden. Das liegt ganz einfach daran, daß viele Simbauer selbst keine so leistungsfähigen Rechner haben, daß sie dauerhaft PBR einschalten würden. Wenn dann irgendetwas keine Fallback-Texturen hat, sehen auch sie es als untexturiert grau, und dann werden sie es definitiv nicht verwenden. PBR-Content ohne Fallback wird es nur auf Sims von Erbauern geben, die selbst einen High-End-Rechner haben und den Viewer auch beim Bauen immer auf Luxuseinstellungen fahren. Das sind dann nämlich die einzigen, die die fehlenden Fallback-Texturen gar nicht bemerken werden.

#OpenSim #SecondLife #FürFortgeschrittene #ContentDesign #Drama

Weil die Lindens eben nichts unternehmen, nehmen die Nutzer die Angelegenheit in ihre eigenen Hände. Das heißt, das tun sie schon länger, aber jetzt verstärken sie diese Anstrengungen sogar noch. Und auch OpenSim verschärft seine ohnehin schon laufenden Gegenmaßnahmen gegen das auch da gegenwärtige sexuelle Ageplay.

Allerdings sind diese Maßnahmen nicht ohne Kollateralschäden.

Präventive Gegenmaßnahmen oder Paranoia?

In OpenSim wird ebenso wie in Second Life nicht erst gegen sexuelles Ageplay vorgegangen, wenn es passiert oder kurz davor ist zu passieren. Das Vorgehen ist proaktiv und präventiv, und man reagiert lieber zuviel als zuwenig. Einiges davon mutet aber als regelrecht paranoide Überreaktionen auf Grundlage völlig verzerrter Standards an.

Zugegeben, wenn jemand eine „familienfreundliche“ FKK-Sim baut, bekommt man automatisch nervöse Zuckungen. Wenn das mal wieder eine Strandsim voller „Mobiliar“ mit Sexanimationen ist, ist derjenige entweder kreuzdämlich und hat keine Ahnung, was er sich da eigentlich hinstellt, oder er ist zu blöd, das tatsächliche Ansinnen der Sim gut genug zu verschleiern. Wenn sie dann auch noch ein Adult-Rating hat, muß man sich fragen, wie das mit „familienfreundlich“ zusammenpassen soll.

Aber selbst wenn die Sim maximal ein Moderate-Rating hat und nachweislich komplett frei von jeglichem Sexmobiliar ist, ist sie zumindest zweifelhaft. Entweder sind die Betreiber neu in virtuellen Welten und komplett ahnungslos, was aber unwahrscheinlich ist, wenn sie eindeutig Erfahrung in der Simgestaltung haben. Oder sie sind naiv und blauäugig genug, daß ausdrückliche Familienfreundlichkeit, ein Moderate-Rating, das Fehlen von Sexmobiliar und sogar ein ausdrückliches Verbot sexueller Elemente in der Nacktheit (z. B. Erektionen) ihre Sim sicher macht. Wie im ersten Teil schon geschrieben, solange kein Gesetzgeber sagt, nackte Kinderavatare sind keine Kinderpornographie, sind sie anzusehen als genau das.

Und wenn dann auch noch die Avatare der Simbetreiber selbst nicht etwa als Personal der Anlage in Erscheinung treten, sondern selbst als Kinder – als nackte natürlich –, dann ist das entweder noch größere Naivität oder ein noch geschickteres Verschleiern von Dingen, die möglicherweise tatsächlich auf ganz anderen Sims stattfinden.

In solchen Situationen Vorsicht walten zu lassen, ist also mehr als selbstverständlich, zumal das durchaus auch für Besucher strafrechtliche Konsequenzen haben kann.

Keine Silikontitten = minderjährig

An anderer Stelle hingegen wird regelrecht überreagiert. Das fängt bei gewissen Meshbodys an. Und nein, ich rede nicht von Kinderbodys.

Ich rede von sogenannten Petite-Bodys. Normale weibliche Meshbodys haben ja idealisierte, also ziemlich große Brüste. Die wenigsten Frauen haben im Real Life so große Brüste, jedenfalls nicht in Form mit einer ansonsten so schlanken Figur. Und wenn sie die haben, dann sind die mit erheblicher Wahrscheinlichkeit irgendwann vergrößert worden, also nicht natürlich. Petite-Bodys entsprechen im wesentlichen diesen Meshbodys, haben aber deutlich kleinere Brüste. Realistischere Brüste.

Das erste Problem ist nun: In Second Life und in OpenSim hat kaum mehr jemand eine realistische Vorstellung von menschlichen Proportionen. Der Standard ist „BBBBBL“: „Big Butt, Big Boobs, Big Lips“. Ein Riesenhintern, Riesenmöpse und gleichermaßen riesige Lippen, die inzwischen sogar häufig in permanenter Kußstellung sind. Ich meine, es wird ja auch als völlig normal angesehen, wenn der Kopf eines Avatars nur ein Neuntel oder weniger der Körpergröße ausmacht, die Körpergröße zu 60% auf die Beine entfällt und die Arme so kurz sind, daß die Fingerspitzen bei nach unten ausgestreckten Armen gerade eben so auf Schritthöhe sind.

Wenn nun also „dicke Dinger“ als Standard für erwachsene Frauen wahrgenommen wird, werden Brüste, die eigentlich realistisch groß sind, Teenagern zugeschrieben. Schon allein auf dieser Grundlage gelten weibliche Avatare ohne das obligatorische Paar Riesenglocken als minderjährig und werden auch so behandelt. Allein deshalb ist auch gerade eine Ladenbetreiberin in Neverworld dabei, von ihren diversen nicht einmal kleinen Freebie-Sims absolut alles an Athena-Petite-Inhalten zu entfernen.

Erschwerend kommt die Kleidung hinzu, die für Petite-Avatare aus Second Life importiert wird. Für die ganz normale Athena wird z. B. seit Jahren nur noch importiert, was sexy genug ist. Für Athena Petite wird dagegen zu großen Teilen importiert, was niedlich und lolitamäßig wirkt, also den Avatar noch weniger erwachsen wirken läßt.

Es gibt leider durchaus auch Ageplayer, die einen Athena Petite haben, um einen minderjährigen Avatar darstellen zu können, der aber zumindest aktuell noch nicht keine attachmenterkennenden Autobans auslöst. Aber ein erheblicher Teil der Petite-Avatare verwendet diesen Body, weil, wer auch immer hinter dem Avatar steckt, keinen Bock auf die Übersexualisierung weiblicher Avatare und das völlig verzerrte Frauenbild hat.

Unter einsachtzig = minderjährig

Als weitere populäre „Früherkennungsmethode“ von Ageplayern wird die Größe des Avatars herangezogen. Das Schöne daran ist: Das kann mit einfachen Mitteln automatisiert werden. Es gibt ein Skript namens „Childgate“, das vollautomatisch alle Avatare, die eine damit ausgestattete Sim betreten und unterhalb einer Mindestgröße sind, nach kurzer Zeit nicht nur von der Sim wirft, sondern dauerhaft sperrt.

Das Childgate hat zwei Vorteile. Zum einen, wie gesagt, funktioniert es vollautomatisch, also auchin Abwesenheit des Simpersonals. Zum anderen funktioniert es unabhängig von der übrigen Gestaltung des Avatars, man kann es also nicht mit ausschließlich „erwachsener“ oder hinreichend obskurer Avatarausstattung, die nicht auf der Blockliste steht, überlisten. So weit, so gut.

Allerdings ist das Childgate vorkonfiguriert auf eine völlig überzogene Vorstellung davon, ab welcher Größe ein Avatar als erwachsen gilt. Die liegt nämlich normalerweise bei 6 Fuß, was 1,83 Meter sind. Wenn man seinen Avatar auf die eigene Körpergröße eingestellt hat, besteht schon bei männlichen Avataren die Chance, daß das das Childgate auslöst und man gesperrt wird. Bei weiblichen Avataren grenzt die Wahrscheinlichkeit gar an Sicherheit, denn das Childgate unterscheidet nicht zwischen Männlein und Weiblein und wendet auf alle Avatare dasselbe Mindestmaß an.

Es gibt sogar Sim-Betreiber, die immer noch die völlig unrealistischen Riesenavatare von Second Life als Standard ansehen, auf die immer noch alles an Mobiliar in Second Life und OpenSim ausgelegt ist. Die rühren ja daher, daß Second Life bis heute einen Bug bei der Größenbestimmung von Avataren hat: Der offizielle Viewer von Second Life mißt sie nicht bis zur Schädeldecke, sondern bis Augenhöhe. Deswegen trauen Second-Life-Nutzer der Größenangabe im Viewer nicht und stellen ihre Avatare Pi mal Auge ein, was zu ebendiesen Riesenavataren von weit über 2 m Körpergröße führt.

Und so ist auf einigen Sims das Childgate tatsächlich allen Ernstes auf 7 Fuß eingestellt, also 2,13 m. Kritik daran tun die Sim-Betreiber dann gern mit „dein Avatar ist zu klein“ ab.

Umgekehrt gibt es zumindest auf europäischen Sims durchaus Childgates, die auf 1,70 m eingestellt sind. Aber auch die sperren viele realistische Avatare aus, ebenso viele Fantasy-Avatare und dergleichen.

Selbst wenn es kein Childgate gibt, gibt es Sim-Betreiber, die Avatare per Hand kicken und sperren, wenn die ihnen zu klein vorkommen. Das „zu klein“ basiert dann auf Augenmaß, manchmal in Kombination mit den Proportionen des Avatars, aber nicht immer. Einige Sim-Betrieber lassen sich wohl auch die Shape-Größe von Avataren anzeigen und „beseitigen“ sie dann händisch, wenn sie ein gewisses Mindestmaß unterschreiten.

Sommersprossen oder zu bunte Klamotten = minderjährig

Aber auch wenn man das oben Genannte alles berücksichtigt, wenn also der eigene Avatar „sexy“ genug ist und auch groß genug, um zumindest keine 6-Fuß-Childgates auszulösen – oder wenn der eigene Avatar zwar „zu klein ist“, es aber kein Childgate gibt –, kann man Probleme bekommen. Denn inzwischen werden auch andere optische Merkmale herangezogen, um zu bewerten, ob ein Avatar „minderjährig aussieht“ oder nicht. Das passiert um so häufiger, je realistischer der eigene Avatar-Shape noch ist, und um so seltener, je weniger man sich den Idealen „Barbie-/Ken-Puppe“, „kurvenreiche Sexbombe mit Wespentaille“ und „muskelbepackter Riese“ annähert.

Trägt ein Avatar zu knallig-bunte Kleidung, wird er schon mal als minderjährig angesehen, gekickt und gesperrt.

Trägt ein weiblicher Avatar zuviel Rosa, ohne daß das Teil des typischen Schlampenlooks à la Jessica Biatchi ist, dito.

Nach Frisur wird auch gern gegangen. Zopf bei weiblichen Avataren ist heikel, mehr als ein Zopf ist noch heikler. Seitliche Pferdeschwänze gehen gar nicht, ziemlich egal, wie der Avatar sonst aussieht. Im Grunde sind weibliche Avatare nur mit einer langen, gewellten Wallemähne, die offen getragen wird, wirklich sicher – und männliche Avatare entweder mit einem kurzen Maschinenschnitt ganz ohne angehängte Haare oder mit einer rockermäßigen Langhaarfrisur, idealerweise nebst Bart.

Sommersprossen werden auch gern als Zeichen von Minderjährigkeit angesehen. Ich meine, kaum ein Avatar in OpenSim trägt Sommersprossen, auch weil die allermeisten Avatare dafür viel zu dunkle braungebrannte Haut haben. Ich würde nicht einmal ausschließen, daß generell zu helle Haut ein Auslöser für die Annahme sein kann, ein Avatar sei minderjährig.

Umdefinition der Content Ratings

Was ebenfalls Teil des Kampfes gegen Kinderavatare ist, ist der Mißbrauch des Adult-Rating. Eigentlich funktioniert das in OpenSim ja nur als Inhaltswarnung, denn gemäß Second-Life-Definition erlaubt es so ziemlich alles, aber OpenSim hat nicht Second Lifes Alterskontrolle.

In Ermangelung einer Alterskontrolle für Nutzer wird das Adult-Rating aber zunehmend umdefiniert zu „keine Avatare, die minderjährig aussehen“. Wohlgemerkt, mitunter ist das das einzige Kriterium. Die in Second Life damit einhergehenden Freiheiten gibt es indes nicht; statt dessen kann eine Sim gleichzeitig Adult-rated und G-rated sein, also trotz Adult-Rating Nacktheit oder auch nur zu leichte Bekleidung überall auf der Sim ausnahmslos verboten sein.

Sim-Betreiber kommen im allgemeinen problemlos damit davon. Es gibt keine OpenSim-weite Instanz, die die Ratings definiert und die Einhaltung der Definitionen durchsetzt. Die allermeisten Grids haben auch keine verbindlichen Definitionen für die Ratings, weil viele Gridowner felsenfest davon ausgehen, daß es Konsens sei, daß die Definitionen doch sowieso praktisch dieselben sind wie in Second Life. Die einzige Ausnahme ist DigiWorldz, und DigiWorldz erlaubt es tatsächlich, das Adult-Rating in seinen Freiheiten beliebig einzuschränken – also tatsächlich bis zum Pendant zu FSK0.

Einen Nachteil hat das Ganze aber: In Second Life lernt man ganz schnell, daß schon das Moderate-Rating bedeuten kann, daß man in aller Öffentlichkeit auf nackte Avatare treffen kann – und das Adult-Rating, daß man noch „Schlimmeres“ sieht. In OpenSim glauben jetzt schon viele, daß das ganze Hypergrid – abseits dedizierter Sex- oder BDSM-Sims – komplett blitzsauber sei, weil ja sogar das Adult-Rating nicht einmal öffentliche Nacktheit zuläßt. Um so verstörter sind sie dann, wenn sie tatsächlich auf einer Adult-Sim auf nackte Avatare stoßen.

Es wird noch weiter eskalieren

Das Ende der Fahnenstange bei den Gegenmaßnahmen ist noch längst nicht erreicht. Wie schon im ersten Teil geschrieben, wurde alles, was mit Athena Petite zu tun hat, von drei recht umfangreichen Freebie-Sims in Neverworld restlos entfernt. Es würde mich nicht wundern, wenn zunächst einmal genug Druck aufgebaut wird, daß weitere Freebie-Sims denselben Schritt tun, und dann Legacy Perky als nächstes dran ist – ungeachtet Legacys notorisch überbreiter Hüften.

Mehr und mehr Sims werden Avatare, die nicht „erwachsen“ wirken, ausschließen. Mehr und mehr von ihnen werden Childgates einrichten. Sowohl bei neuen als auch bei vorhandenen Childgates wird die Mindestgröße angehoben, auf amerikanischen Sims möglicherweise vermehrt von 6 auf 7 Fuß. Und wer das nicht alles tut, wird gebrandmarkt als Unterstützer von Pädos oder gleich selbst als Pädo.

Auch die optischen Kriterien für minderjährige Avatare werden noch erweitert werden. Bei weiblichen Avataren beispielsweise flache Sneakers, schlimmstenfalls gar mit Socken. Oder überhaupt Schuhe mit Absatzhöhen von unter 15 cm. Weibliche Avatare werden außerdem keine kurzen, weiten Röcke mehr tragen dürfen, es sei denn, diese legen selbst aus der standardmäßigen Kameraperspektive den Hintern frei.

Für weibliche Avatare werden Make-up und Nagellack zur Pflicht. Bei Meshbodys aus Second Life geht der Nagellack normalerweise sowieso nicht zu entfernen, und die Ruth2-Familie, die standardmäßig keinen Nagellack trägt, ist weitestgehend unbekannt, also wird fehlender Nagellack als Zeichen für einen Teenagerbody gewertet. Und das Make-up darf auch nicht zu dezent sein. A propos: Weibliche Avatare ohne Fischlippen werden in Zukunft auch „Kinderavatare“ sein.

Männliche Avatare ohne Bart, und sei es ein Stoppelbart, werden als minderjährig angesehen werden, so selten die auch sind. Auch die Auswahl an zulässigen Bekleidungsfarben wird noch weiter reduziert, bis schlimmstenfalls bei männlichen Avataren nur noch Schwarz, Weiß, Flecktarn und blaues Denim durchgehen.

Es ist gar damit zu rechnen, daß Haut- und Haarfarben mehr zum Kriterium werden. Hautfarben zwischen Gothic-Leichenblässe – und bei weiblichen Avataren geht auch die nur mit Gothic-Make-up durch – und knackbraun werden vermehrt als Zeichen der Minderjährigkeit gelten. Dasselbe wird gelten für helle Haare, vor allem alle Blondtöne, zumindest, bis die ersten Sim-Betreiber sich mit anderen Sim-Betreibern, DJs, Performern oder Gridownern anlegen, die blöderweise zufällig blond sind.

Statt Sichtkontrollen werden sich so etwas wie „Attachment Gates“ ausbreiten, die Avatare automatisch kicken und sperren, je nachdem, was die Avatare tragen. Die gibt es schon mit Blocklisten, die voll sind mit tatsächlicher Kinderavatarausstattung oder zumindest einschlägigen Kinder- oder Teenager-Meshbodys. Aber die werden zum einen zahlreicher und zum anderen zunehmend schärfer konfiguriert, um auch automatisch diejenigen abfischen zu können, die mit „herkömmlicheren“ Mitteln versuchen, jugendlich wirkende Avatare zu bauen.

Statt Schilder aufzustellen, die Kinderavataren den Zutritt verbieten, werden noch mehr Sims, womöglich gar noch mehr ganze Grids, das Adult-Rating mißbrauchen, um Kinderavatare auszusperren. Gleichzeitig werden auf Sims, die das Adult-Rating als Gegenmittel für Kinderavatare verwenden, Nacktheit und sexuelle Handlungen noch sehr viel häufiger gänzlich verboten, um ganz auf Nummer sicher zu gehen.

Ich bin schon gespannt auf das Drama zwischen denjenigen, die all diese Maßnahmen für das ganze Hypergrid einfordern, und denjenigen, die sie ablehnen, und sei es, weil sie solchen Maßnahmen selbst fälschlicherweise zum Opfer gefallen sind.

#OpenSim #SecondLife #FürFortgeschrittene #News #Drama #NSFW

Die Reaktionen der Communitys von Second Life und OpenSim fallen aktuell entsprechend aus. Aber nicht nur auf die behauptete Teilnahme von Lindens, sondern darauf, daß es öffentlich angesprochen wird, daß so etwas existiert.

Den Artikel auf Medium werde ich nicht verlinken; so ziemlich jeder, der diesen Artikel behandelt, weigert sich dagegen, so heikel ist der. Statt dessen kann man sich den dazugehörigen Thread im englischsprachigen Second-Life-Subreddit zu Gemüte führen.

Ageplay?

Zunächst einmal: Worum geht es hier eigentlich? Was ist dieses Ageplay?

Gemeint ist hier sexuelles Ageplay. Im Klartext: Erwachsene Avatare, die von erwachsenen Nutzern gesteuert werden, führen sexuelle Handlungen durch mit Kinderavataren, die von erwachsenen Nutzern gesteuert werden. Und ja, das ist in Second Life eigentlich komplett verboten, und zwar auch auf Sims mit Adult-Rating.

Fakt ist aber: Das gibt es trotzdem. Einige der ältesten Sims in Second Life spezialisieren sich geradezu auf so etwas – zwar nur hinter vorgehaltener Hand, aber wer weiß, wo man sich wie informieren kann, der findet das. Und es macht den Anschein, als hätten ausgerechnet die Lindens es in mehr als anderthalb Jahrzehnten nicht geschafft, das zu entdecken.

Dabei kann es so undergroundig gar nicht sein. Es gibt ja tatsächlich Content, der ziemlich eindeutig genau dafür erschaffen wurde. Ich bin zwar selbst nicht in Second Life, geschweige denn in dieser Szene. Aber daß es diesen Content gibt, weiß ich daher, daß er zum einen immer wieder genannt wird, wenn es um das Problem Ageplay geht, und zum anderen es genau diesen Content auch in OpenSim gibt.

Gibt es das wirklich?

Annähernd alles, was seit ca. 2015 in OpenSim neu an Kindercontent aufgetaucht ist, wurde aus Second Life geklaut. Und damit es aus Second Life geklaut werden kann, muß es folgerichtigerweise in Second Life existieren.

Gut, zunächst einmal kann man daran, daß es Sachen gibt, mit denen man seinen Avatar als Kind ausstaffieren kann, nichts Verwerfliches finden. Kann ja mal sein, daß jemand eine unbeschwerte Kindheit, die man selbst nie hatte, spielen will. Oder daß sich ein paar Leute zusammentun und eine Familie spielen wollen. Oder so.

Aber dann guckt man sich den Content, den es in den Kinderläden auf einigen Freebie-Sims so gibt, mal genauer an. Da gibt es dann Kinder-Meshbodys. Mit dazugehörigen Skin-Appliern, denn das ist alles noch aus Vor-BoM-Zeiten. Und auf der Box ist dann eben so ein Kinderavatar mit diesem Meshbody abgebildet.

Nackt.

Standardmäßig ist da ein Mädchen zu sehen. Bei älteren Ausgaben der Box ist der Genitalbereich des Mädchens komplett unbedeckt. Diese Textur im Viewer-Cache zu haben, kann eigentlich schon den Straftatbestand des Besitzes von Kinderpornographie erfüllen, zumal es da bis heute keine juristischen Entscheidungen darüber gibt, wo die in virtuellen Welten anfängt und aufhört. Neuere Ausgaben derselben Box haben einen Querbalken mit dem Namen des Body über den Genitalbereich gelegt – und zwar ganz knapp, daß gerade eben so überdeckt wird, was unbedingt überdeckt werden muß.

Da fragt man sich: Wofür muß ein Kinderavatar überhaupt die Möglichkeit haben, nackt zu sein? Kann man auf die Skin nicht zumindest einen Schlüpfer fest aufbaken, wie es ja teilweise tatsächlich praktiziert wird? Und auch Mesh-Badesachen können so zugeschnitten werden, daß sie den aufgebaketen Schlüpfer komplett überdecken, so daß man den nicht sieht.

Wer so etwas in einem Laden anbietet, kuratiert entweder die Sachen nicht, die er an die Wände ballert, und guckt auch selbst nie nach, was da so hängt. Oder er will ganz einfach möglichst viel Content anbieten, egal, was es sein möge. Oder … denken wir lieber nicht darüber nach.

Wenn man sich in so einem Kinderavatarladen etwas genauer umguckt, wird man auch auf mindestens eine Box stoßen mit – jetzt kommt’s – einem Kinderpimmel. Einem geskripteten, also mit gewissen Funktionen.

Gut, jetzt kann man sagen: Die Nacktskins und den Schniepel braucht man z. B. für einen Nacktbadestrand oder eine FKK-Sim oder so. Oder vielleicht will die Familie ihr Kind ja auch mal baden. Ist doch eigentlich alles ganz harmlos.

Zunächst einmal: Nein, in virtuellen Welten ist das nicht harmlos. Wie gesagt: Es gibt noch keine eindeutige, allgemeingültige juristische Entscheidung darüber, ob nackte Kinderavatare in virtuellen Welten Kipo sind oder nicht. Und solange es keine solche Entscheidung gibt, ist davon auszugehen, daß es als Kipo angesehen und entsprechend geahndet werden kann. Will sagen: Du kannst buchstäblich in den Knast dafür gehen, daß du einmal auf einer FKK-Sim warst.

Vom Juristischen mal ganz abgesehen, ist da immer noch der Umstand, daß dieser Kinderschniepel geskriptet ist. Der hat also Funktionen, die auch Erwachsenenpimmel haben – möglicherweise vom Samenerguß abgesehen, der in dem Alter noch nicht möglich ist. Aber sonst alles. Jetzt kann man das Pipimachen als notwendigen Teil eines harmlosen Rollenspiels einer Familie oder gar einer Kinderbande auf einem FKK-Zeltplatz zu rechtfertigen versuchen, aber schon damit begibt man sich auf dünnes Eis. Und wofür, bitteschön, muß so ein Kinderschniepel zu Erektionen fähig sein? Wie will man das ohne sexuellen Kontext rechtfertigen?

Präzedenzfälle in OpenSim

Nun könnte man sagen: „Okay, es gibt all diese Sachen. Aber das benutzt doch keiner. Und sexuelles Ageplay macht doch auch keiner. Das kann ich mir nicht vorstellen.“

Ich konnte mir bis 2021 auch nicht vorstellen, daß jemand die Sexanimationen in damit ausgestatteten Möbelstücken tatsächlich benutzt, bis ich das erste Mal in-world verführt worden bin.

Und ja, Ageplay gibt es. Und ja, es gibt auch Pädophile in OpenSim. Eigentlich könnte man sagen, in Second Life haben die nicht viel zu verlieren, weil die Lindens auf dem Auge, das die einschlägigen Ageplay- und Pädo-Sims sehen könnte, blind sind. Aber es gibt eben die, denen das nicht reicht, die also ein Umfeld brauchen, in dem sie sich noch sicherer fühlen. Und OpenSim, das ja keinerlei wie auch immer geartete zentrale Administration hat, ist für sie genau das.

Ich möchte mal zwei Beispiele aufführen.

Travesty Winesmith

Das eine war Travesty Winesmith, ein Texaner mit durchweg erwachsenen männlichen Avataren. Später agierte er auch unter den Namen Trav Gambino und Paul Jones. Seine eine Eigenart waren ständige Versuche, geltende Regeln als für ihn selbst ungültig zu erachten und durch seine eigenen zu ersetzen. Wenn er das nicht konnte, versuchte er sie zu umschiffen.

So setzte er teilweise auf sogenanntes Daddyplay. Dafür trieb er sich auf Adult-Sims herum, auf denen die Wahrscheinlichkeit groß genug war, auf einzelne weibliche Avatare zu treffen, die idealerweise sogar nackt waren. Das Daddyplay, das er vorhatte, sollte ein Rollenspiel sein, in dem sein erwachsener männlicher Avatar den Papa spielt und ein erwachsener (!) weiblicher Avatar seine implizit oder gar explizit minderjährige (!) Tochter (!).

Er wußte ganz genau, daß man ihn dafür nicht sanktionieren konnte. Immerhin hätte es sich de facto immer noch um ein sexuelles Rollenspiel zwischen zwei erwachsenen Avataren gehandelt, von denen einer eben nur eine minderjährige Person gespielt hätte. Wohlgemerkt, in beiderseitigem Einvernehmen. Das hätte nicht gegen die jeweiligen Simregeln verstoßen, das hätte nicht gegen die jeweiligen Gridregeln verstoßen, das hätte auch nicht gegen geltendes Real-Life-Recht verstoßen, zumindest nicht in der westlichen Welt, in der fast alles in OpenSim läuft. Jeglicher Versuch, das zu ahnden, wäre laut ihm nichts weiter gewesen als Teil einer Hexenjagd und Verleumdungskampagne gegen ihn.

Manchmal reichte ihm aber auch das nicht aus. Es gab mindestens einmal einen Fall, in dem öffentlich ein Bild gepostet wurde, das ihn auf einer Sim mit Kinderthema und General-Rating zeigt, wie er nackt neben einem angezogenen Kinderavatar steht. Wohlgemerkt, das Bild wurde nicht mit der Fotofunktion gerendert, sondern es war tatsächlich ein Screenshot mit Namen über den Avataren. Der Name des Kinderavatars wurde unkenntlich gemacht, ebenso Travs Gemächt, aber was da zu sehen war, war eindeutig. Travs Reputation wurde dadurch nicht geschädigt, sondern eher bestätigt, aber die Sim und ihre Betreiberin standen in einem sehr schlechten Licht da.

Nachdem die Identität „Travesty Winesmith“ komplett verbrannt war, kehrte er zurück als Trav Gambino. Als solcher führte er sich aber wieder genauso auf, und es war in nullkommanix klar, daß das Travesty Winesmith mit neuem Namen war. Daraufhin legte er sich die Identität Paul Jones zu, die zum einen weniger offensichtlich sein sollte, und die er zum anderen nur in-world verwendete, aber nicht auf wie auch immer gearteten Websites. Aber auch hier blieb nicht lange unklar, wer das war.

Der Engländer mit den vielen Kleinmädchenavataren

Das andere war ein wegen pädophiler Straftaten bereits vorbestrafter Engländer. Der ging anders vor: Statt jeweils immer nur eines einzigen erwachsenen Männeravatars hatte er etliche Avatare in Gestalt kleiner Mädchen. Er hatte dafür eine ganze Liste an Identitäten, mindestens ein halbes Dutzend davon. Er legte Avatare mit diesen Identitäten jeweils auf etlichen Grids an. Und er hatte mit Sicherheit immer eine und dieselbe Avatar-Grundausstattung, die er von Avatar zu Avatar weitergab, um die Ausgestaltung der Avatare zu beschleunigen.

Dann nahm er einen dieser Mädchenavatare und schickte ihn auf eine Sim mit mindestens einem weiteren Avatar darauf. Diese Sim mußte er sicherlich vorher auskundschaften, denn sie durfte nicht die Kombination eines Landepunktes direkt neben einer aktiv genutzten Partylocation mit einem Verbot von Kinderavataren haben. Oder er riskierte es einfach, daß einer seiner Avatare ungünstig landete und damit für diese Sim oder das ganze Grid verbrannt war – egal, er hatte ja dutzendweise Ersatzavatare und konnte jederzeit mit minimalem Aufwand neue machen.

Der nächste Schritt war dann, die Liste der auf der Sim befindlichen Avatare zu öffnen und einen männlichen Avatar herauszusuchen – oder einen, dessen Name männlich erschien. Er war nämlich nicht die hellste Kerze auf der Torte und hielt „Juno“ für einen Männernamen.

Diesen Avatar schrieb er dann per PN an. Dabei schrieb er immer exakt denselben Wortlaut. Zumindest die Zeilen fürs Anschreiben hatte er auf einer Notecard oder in einer Textdatei oder einem Word-Dokument oder so und copy-pastete sie immer in den Chat, statt sie neu zu tippen.

Als erstes winkte er dem anderen Avatar zu – selbst wenn das über eine Distanz von über 100 Metern war mit etlichen Sichtbarrieren dazwischen. Auch wenn man nicht darauf einging, schob er eine Frage nach dem werten Befinden hinterher, die er immer „How is you“ schrieb. Wenn man dann darauf einging, kam als nächstes die Ansage dieses Mädchens, daß ihr Papa gerade nicht zu Hause ist, und ob man mit ihr nach Hause kommen möchte. Wie gesagt, immer 100% identischer Wortlaut.

Wenn er das auf einer Partysim tat, schrieb er auf diese Art mitunter gleich mehrere Avatare gleichzeitig an in der Hoffnung, einer würde anbeißen.

Der Kerl war damals derart aktiv, daß es nicht lange dauerte, bis man von ihm mehrfach angeschrieben worden war. Er führte ja nie Buch darüber, wo er schon war und wen er schon angeschrieben hatte. Nach ein paarmal erkannte man ihn sofort an seiner gecopypasteten Schreibweise, ohne seinen Avatar auch nur zu sehen. Nach ein paarmal mehr kannte man auch zumindest ein paar der Namen, die seine Avatare trugen. Wie gesagt, denselben Namen gab es durchaus auf zwei, drei oder noch mehr Grids.

Gegenmaßnahmen

Die beiden waren allerdings keine Einzelfälle und schon gar nicht die einzigen. Wer nicht gerade in einer winzigen Blase sitzt und diese nie verläßt, weiß, daß es in OpenSim einiges an Pädophilie gibt. In Ermangelung einer zentralen Administration, einer zentralen Definition von Regeln und einer zentralen Durchsetzung dieser Regeln obliegt es der Community, dagegen etwas zu unternehmen. Und angesichts des Berichts über Ageplay in Second Life ist nicht nur davon auszugehen, daß dies noch verschärft wird – es passiert bereits.

Die Konsequenzen dieser Maßnahmen, die harmlosen Avataren in Gestalt Minderjähriger ebenso wie auch manchen eigentlich erwachsenen Avataren das Leben schwer machen, möchte ich im zweiten Teil schildern.

#OpenSim #SecondLife #FürFortgeschrittene #News #Drama #NSFW

Und dann landet man auf einer altertümlich oder mittelalterlich anmutenden Sim. Wenn Avatare anwesend sind, sind vor allem weibliche höchstwahrscheinlich entweder sehr leicht und freizügig bekleidet oder gleich ganz nackt. Womöglich sieht man sogar einen altertümlich bzw. mittelalterlich gekleideten – oder wiederum nackten – männlichen Avatar, der gerade einen weiblichen Avatar erniedrigt oder gar vergewaltigt.

Bevor man auch nur auf die Idee kommt, das zu melden, kann es passieren, daß man sogar von der Sim geworfen wird. Sofern man eine Begründung dafür bekommt, wird die sein, daß man selbst sich nicht an die Regeln gehalten hat.

Ja wie, Regeln? Und wieso man selbst? Man hat nur dagestanden in seinen Alltagsklamotten und hat genau gar nichts gemacht, aber da war dieser Typ, der diese Frau in aller Öffentlichkeit vergewaltigt hat? Wer hat denn hier jetzt gegen irgendwelche Regeln verstoßen?!

Doch, das war man tatsächlich selbst. Doch, es gibt Regeln. Und nach diesen Regeln war die Vergewaltigung übrigens legal.

Was zum Teufel …?

Literarische Vorlage

Dafür sollte ich Gor zunächst einmal erklären.

Gor stammt aus der Literatur. Genauer gesagt kommt es aus einer Romanreihe, die der Autor John Norman seit 1966 schreibt. Der erste Band, Tarnsman of Gor, erschien in Deutschland 1973 unter dem Titel Gor – Die Gegenerde und wurde 2007 unter dem Titel Der Krieger neu veröffentlicht.

Gor selbst ist ein Planet in unserem Sonnensystem, eine sogenannte Gegenerde. Er befindet sich also auf derselben Umlaufbahn um die Sonne wie die Erde selbst, aber am genau gegenüberliegenden Punkt. Gor kann also von der Erde aus nicht gesehen werden, weil die Sonne im Weg ist. Umgekehrt weiß man auf Gor sehr wohl, daß die Erde existiert, denn die Priesterkönige, die höchsten Herrscher, die auf Gor selbst eigentlich Aliens sind, verfügen über Raumschiffe.

In mancherlei Hinsicht ähnelt Gor der Erde. So haben einige irdische Kulturen Pendants auf Gor. Allerdings wird Gor von den Priesterkönigen künstlich auf einem Stand gehalten, der jeweils einer z. B. altertümlichen oder mittelalterlichen Kultur der Erde entspricht. Das liegt auch daran, daß Gor ursprünglich gar nicht bewohnt war und alle Einwohner Gors entweder von der Erde entführt wurden oder Nachfahren von Entführungsopfern sind. Die Priesterkönige haben z. B. Wikinger entführt oder Leute aus dem alten Rom oder aus anderen mediterranen Hochkulturen, aber auch aus Japan, dem Orient oder dem Venedig des Barock. Und die haben sich seitdem nicht weiterentwickeln dürfen. Das heißt, manchmal entführen die Priesterkönige immer noch Menschen von der Erde.

Das erklärt aber immer noch nicht die Phänomene, die ich oben beschrieben habe. Die rühren daher, daß ein wichtiger Bestandteil der Kultur(en) von Gor Sklaverei ist. Weit überwiegend werden Frauen versklavt. Und dieses Sklaventum ist sehr wohl auch sexueller Natur.

Um es kurz zu machen: Im Grunde lebt Norman mit diesen Büchern nur seine eigene Affinität zu männlicher Dominanz, weiblicher Erniedrigung (Maledom/Femsub) und BDSM aus. Und tatsächlich sind die Gor-Bücher in der BDSM-Szene populär, wenngleich auch nicht unumstritten, denn was da passiert, ist kein klassisches BDSM. Nicht nur reduziert es sich im Grunde auf Dom/Sub, also Dominance/Submission, sondern es wird häufig sogar auf ein Safeword verzichtet. Das wird dadurch gerechtfertigt, daß zum einen – meistens – die Frau eine Sklavin ist, die eh nichts zu sagen hat, und zum anderen keine gefährlichen Sadomaso-Praktiken zum Einsatz kommen. Wie gesagt, es ist ja „nur“ Dom/Sub.

Virtuelles Gor: Lifestylers vs. By-the-book

Auch in virtuellen Welten – will sagen, speziell Second Life und OpenSim – gibt es BDSM. Das mag jetzt einige schockieren, das ist aber so. Gerade bei Amerikanern hat man manchmal den Eindruck, daß es nichts gibt zwischen einerseits totaler Prüderie und Verklemmtheit und andererseits BDSM mit allen Schikanen. Im Grunde ging es los, als es durch neue Mittel der Animationssteuerung technisch möglich wurde.

Ein wichtiger Bestandteil war hier die Einführung des Restrained Love Viewer (RLV), einer Erweiterung in Viewern, die es Avataren ermöglicht, andere Avatare zu steuern. In OpenSim wird einem das gern als Mehrzweck-Fernsteuerung für NPCs verkauft, und natürlich kann man es dafür nehmen. Aber RLV wurde für Second Life entwickelt, und in Second Life gibt’s keine NPCs. Da kann man damit nur die Kontrolle über Avatare übernehmen. Hauptsächlich wird es also für Dom/Sub-Spielchen eingesetzt. Dabei muß der zu steuernde Avatar einen entsprechenden Empfänger tragen, was meistens ein Halsband ist.

Wie dem auch sei, bald wurde man wohl der üblichen BDSM-Spiele mit Lack und Leder und Andreaskreuz und Käfig und so weiter überdrüssig und kam auf die Idee, Sims mit Gor-Thema zu bauen. Natürlich war das überwiegend nur ein Feigenblatt für Dom/Sub ohne Safeword und für sexuelle Handlungen in aller Öffentlichkeit.

Das war vor allem dann offensichtlich, wenn die Sims mit Gor herzlich wenig zu tun hatten, weil die Simbetreiber Gor allenfalls vom Hörensagen aus der BDSM-Szene kannten. Ich habe mal von einer Sim gelesen, in der es wohl darum ging, daß irgendwo lauter freie nackte Frauen herumlaufen, die von Männern einfach versklavt werden können. Wohlgemerkt, ohne NPCs. Solchen und ähnlichen Unfug fand man da dann vor.

Irgendwann breiteten sich aber tatsächliche Fans der Gor-Reihe in Second Life und OpenSim aus. Die fanden es doof, daß Gor als Name herhalten mußte für „Maledom/Femsub und Rumgeficke in aller Öffentlichkeit, aber der Mann ist ein antiker Krieger/Geldsack“.

Um das allgemeine Wissen über und die Reputation von Gor zurechtzurücken, führten sie Sims nach einem neuen Prinzip ein: „by the book“, also streng nach literarischer Vorlage. By-the-book-Sims sind also keine reinen BDSM-Sexsims, sondern darauf ausgelegt, alle Aspekte von Gor im Rollenspiel nachstellen zu können. Für diejenigen, die Gor nur als stilistische Vorlage für Maledom/Femsub nutzten, fanden die Gor-Fans den Begriff „Lifestylers“.

Warum Gor-Sims längst nichts für jedermann sind

Wichtig auf Gor-Sims ist auch die Immersion. Der oben geschilderte Rauswurf ist genau darin begründet: Auf den meisten Gor-Sims wird erwartet, daß man sich in diese Welt integriert, daß man sich entsprechend verhält – und daß man sich entsprechend kleidet. Wenn man auf einer Gor-Sim erwischt wird in schwarzer Lederjacke, T-Shirt, Jeans und Turnschuhen, fliegt man achtkantig raus. Solche Klamotten gibt es auf Gor nicht.

„Ich wollte nur mal gucken“ geht als Ausrede ebensowenig durch wie „ich hab’ keinen Bock, diesen Blödsinn mitzumachen“. Out-of-character (kurz OOC) ist gerade auf By-the-book-Gor-Sims im allgemeinen nicht erlaubt. Wer dagegen verstößt, fliegt raus. Da können die Gor-Leute rigoros sein.

Als Frau oder mit einem weiblichen Avatar hat man sowieso keine Rechte. In Gor gibt es grundsätzlich schon auch reiche, mächtige Frauen. Aber nicht jeder in der OpenSim-Gor-Community will das anerkennen. Für viele sind Frauen bzw. weibliche Avatare automatisch immer Sklavinnen. Einige haben schon ein Problem damit, daß das Gor Grid – eins von mehreren Grids, die sich auf Gor spezialisiert haben – von einer Frau administriert wird, also die mächtigste Person im Grid eigentlich eine rechtlose Sklavin sein müßte. OOC aus Ahnungslosigkeit heraus schützt einen übrigens auch da nicht.

Es gibt nur sehr wenige Gor-Sims, auf denen – und sei es nur auf Teilen der Sim – Neulinge, die sich nicht gleich ins Gor-Thema stürzen wollen und können, sich so bewegen dürfen wie sonst auch. Da wird Gor vorgestellt, und da bekommt der angehende Goreaner, was er braucht, vor allem passende Kleidung – sofern es für den eigenen Body passende Gor-Kleidung gibt. Die gibt’s nämlich nur sehr selten auf Nicht-Gor-Sims, aber für Gor-Sims braucht man sie.

Wer von Gor keine Ahnung hat, sollte sich auf diese Sims beschränken. Und wenn es da spezielle Besucherbereiche gibt, sollte man sich auch nur in diesen Besucherbereichen aufhalten. Wenn man das nicht unterscheiden kann, sollte man von allem, wo Gor dran steht, generell die Finger lassen. Wenn man irgendwie prüde ist, mit Rollenspiel nichts am Hut hat oder gegen Sexismus und für Gleichberechtigung und Gleichbehandlung der Geschlechter, dann auch.

Ansonsten kann aus der eigenen unbändigen Neugierde schnell eine sehr unangenehme, ja, schmerzhafte Erfahrung werden.

#OpenSim #SecondLife #FürFortgeschrittene

Zum Anfang: Sieht aus, als hätten wir das offizielle Startdatum von Opensim: den 29. Januar 2007.

Kurze Zeit später schrieb man im alten Second-Life-Forum darüber, erst noch als Sim, die jemand privat zu betreiben schaffte. Dann ist erkennbar, daß das Ganze wohl ursprünglich „OpenSecondLife“ hieß und später in OpenSimulator umbenannt wurde.

Auch interessant: die BIZZin3D Conference 2009 in Berlin. Da wurde nicht nur unter anderem OpenSimulator thematisiert, sondern man sprach auch schon vom „Metaversum“ und vom „Web 3.0“. Vor ziemlich genau 13 Jahren.

#OpenSim #Metaverse #SecondLife #AndereWelten #OpenSimFrühzeit #Fundstücke