Von Anfang an handelte es sich beim Projekt DigiSchulLab um eine explorative Erfahrung. Dies hat die Arbeit und das Ergebnis des Projektes in besonderem Maße beeinflusst. Zunächst stellte die Abwesenheit von vorweg abgesteckten Deadlines und Zielen eine Herausforderung für uns dar, denn bisher hatten nur wenige von uns Erfahrung mit einem explorativen Projektmodell. Doch nach einer gewissen Eingewöhnung haben sich dann die vielen Vorteile herausgestellt, die eine explorative Projektstruktur mit sich bringt.
Ein Vorteil im Bezug auf unser gewähltes Thema war die Freiheit bei der Wahl der verwendeten Werkzeuge und Technologien. Diese Freiheit gab uns die Möglichkeit mit den Werkzeugen zu arbeiten, mit denen wir vertraut sind und welche die besonderen Anforderungen erfüllen, die sich auf dem Weg ergeben. So war es während des Projektes möglich, zwischen verschiedenen Umsetzungen mit verschiedenen Werkzeugen abzuwägen und so Ideen zu verwirklichen, die in einer starren Projektstruktur mit vorgegebenen Technologien nicht möglich gewesen wären. Zum Ende des Projektes hat diese Freiheit bei der Projektstruktur unterstützt, dass mit den entwickelten Komponenten eine virtuelle 3D-Ausstellungsumgebung für den Tag der Informatik relativ schnell aufgebaut und erfolgreich eingesetzt werden konnte.
Ebenfalls einen positiven Effekt auf die Arbeit hatte die Freiheit bei der Setzung der eigenen Ziele. Nach einer anfänglichen Findungsphase für Ideen und der Sichtung von anderen Projekten zu diesem Thema (z.B. Workadventure) konnten wir unser Ziel als Gruppe frei wählen. Das Ergebnis war ein Projekt, hinter dem sich alle Projektmitglieder versammeln konnten und für das sich wirklich alle interessierten. Ebenfalls entwickelt es eine ganz eigene und besondere Eigendynamik, wenn man an einem Projekt arbeitet, welches man selbst gestaltet und nicht nur aus einer Liste wählt.
Schlussendlich lässt sich noch sagen, dass es sich für die meisten von uns bei diesem Projekt um die letzte Projekterfahrung in diesem Studium handelt. Das Studium bietet gegenüber der Wirtschaft die Möglichkeit, die Arbeit zur Erschließung neuen Wissens von wirtschaftlichen und starren Interessen zu trennen. Als das letzte Projekt in einem solchen Umfeld war es eine angenehme Erfahrung, noch einmal in einer kreativ orientierten Umgebung ein Projekt von Anfang bis Ende mitzugestalten.
Die Corona-Krise hat gezeigt, wie wichtig es ist, auf unterschiedliche Situationen vorbereitet zu sein. Die meisten Aspekte unseres Lebens haben sich auf digitale Plattformen verlagert. Dies gilt auch für Schulen. Mit dem Ausbruch der Pandemie wurde deutlich, dass die meisten Schulen nicht vorbereitet waren, Fernunterricht durchzuführen. Auch wenn in den letzten Jahren viel Geld in die Digitalisierung der Schulen und den Aufbau von Infrastrukturen investiert wurde, gibt es noch viele offene Fragen, z.B. die Frage nach der digitalen Souveränität. Was ist, wenn die Schule alle Informationen auf ihrem Server platzieren möchte? Es ist zu bedenken, dass die Schule dies nicht nur finanzieren muss, sondern gegebenenfalls auch die aufgebaute Infrastuktur administrieren muss. Das Ziel unseres Projektes ist es, die folgende Frage zu beantworten: Gibt es eine Möglichkeit, eine digitale Open-Source-Lernumgebung zu erstellen?
„DigiSchulLab“ ist unsere Idee, ein virtuelles interaktives Kommunikationswerkzeug zu schaffen. Es ging darum, eine modulare Client-Server-Architektur zu entwickeln. Zunächst haben wir darüber gesprochen, wie wir unseren Prototyp erstellen werden, auf der Godot-Game-Engine oder mit der Three.js-Bibliothek. Am Ende haben wir uns entschieden, beide Optionen zu nutzen und 2 Clients (Godot, Three.js) und 1 Webserver mit einem gemeinsamen Kommunikationsprotokoll zu erstellen.
Da unsere Fragestellung sich auf eine opensource-basierte Lernumgebung bezieht, war es wichtig für uns nur mit opensource-basierten Werkzeugen zu arbeiten. Als Open Source wird Software bezeichnet, deren Quelltext öffentlich und von Dritten eingesehen, geändert und genutzt werden kann. Open Source hat viele Ursprünge und Vorläufer, beispielsweise die Do-it-yourself-Bewegung, die Hacker-Bewegung der 1960/1970er und die Freie-Software-Bewegung der 1980er Jahre, die der unmittelbare Vorläufer wurde.
HedgeDoc ist die Community-gesteuerte Abzweigung von CodiMD, dem Open-Source-Gegenstück zu HackMD. Es ist inspiriert von Hackpad, Etherpad und ähnlichen kollaborativen Editoren. Dieses Projekt entstand mit dem Team von HackMD und wurde nun in eine eigene Organisation integriert. HedgeDoc (früher CodiMD) ist ein webbasierter Dienst für kollaborative Textverarbeitung in Echtzeit. Er verwendet die Markdown-Sprache, die eine einfache Möglichkeit zur Formatierung von Text darstellt. HedgeDoc bietet eine große Auswahl an Funktionen für alle gängigen Verwendungszwecke der Textverarbeitung: Verwaltung von Überschriften, Inhaltsverzeichnis, Einfügen von Bildern, Tabellen, Graphen und Diagrammen erstellen, Folien erstellen und präsentieren, Fußnoten, Einbetten von Videos, PDF-Betrachtern usw. Verschiedene Berechtigungsstufen ermöglichen es, festzulegen, wer das Dokument lesen oder bearbeiten darf.
Das haben wir im Laufe unser Projektes entdeckt und auf die Hochschule Server gehostet ( HedgeDoc Hochschule Bremerhaven). Wir haben das als kollaboratives Editor für unsere wöchentliche Protokolle, Präsentationen, usw. benutzt.
BigBlueButton (abgekürzt BBB) ist ein webbasiertes Open Source Videokonferenztool. Mit BigBlueButton können Nutzer:innen Videokonferenzen führen, sowie Webinare und Online-Präsentationen veranstalten. Genauso wie bei Microsoft Teams dient BBB der Kommunikation, dem Austausch und der Datenvermittlung. „BigBlueButton“ wird derzeit vor allem von Bildungsinstitutionen für E-Learning und Schulen genutzt, da es viele Funktionen zu bieten hat, die dem Schulunterricht unterstützend zur Seite stehen. Dazu zählen z.B. Webkonferenzen und die Freigabe von Dokumenten und Audio-Videodateien.
Ähnlich wie bei Apache OpenMeetings verwendete BigBlueButton ursprünglich red5, eine Open-Source-Implementierung von Adobe Media Server, um die Zusammenarbeit in Echtzeit zu unterstützen. Heute verwendet BBB HTML5 und WebRTC für Audio, Video und Screen-Sharing, welche in den meisten Browsern integriert sind. Die Installation von Browser-Plugins ist nicht mehr notwendig. Für mobile Endgeräte gibt es keine Apps, BBB funktioniert dort ab Android 6.0 mit Google Chrome und bei Apple-Geräten ab iOS 12.2 mit dem Safari Browser. In beiden Fällen ist die Screen-Sharing Funktion nicht nutzbar, da sie von diesen mobilen Browsern nicht unterstützt wird. Alle relevante Informationen (Sitzungen, Teilnehmer, usw.) werden intern als Schlüssel-Werte-Daten in einer redis-Datenbank verwaltet. Die einzelnen Komponenten kommunizieren über PubSub. In einer BBB Sitzung können je nach der Anzahl der aktivierten Kameras bis 100 oder auf leistungsstarker Hardware auch bis zu 300 Nutzer teilnehmen. Um mehrere Konferenzen gleichzeitig anbieten zu können, ist ein Lastverteiler erforderlich.
Matrix ist ein Open-Source-Projekt, das den Matrix-Standard für sichere, dezentralisierte Echtzeitkommunikation und seine Apache-lizenzierten lizenzierten Referenzimplementierungen. Das Projekt wird von der gemeinnützigen Matrix.org Foundation betreut und hat zum Ziel eine offene Plattform zu schaffen, die so unabhängig, dynamisch und entwicklungsfähig ist wie das Web selbst. Der einfachste Weg, sich anzumelden und Matrix auszuprobieren, ist die Verwendung von Element, einem webbasierten Client. Es gibt auch native Element-Apps für Android und iOS. Wir haben das im laufe des Projektes häufig als Messaging-Dienst benutzt, zur Planung von Meetings und um über das Projekt auszutauschen.
Three.js ist eine JavaScript library, die uns mit Hilfe von WebGL erlaubt 3D Umgebungen im Browser darzustellen. Sie wurde 2010 von Ricado Cabello, online bekannt unter dem Namen Mr.doob, released und ist mit einer MIT Lizenz versehen. Möchte man simple Dinge, wie einen rotierenden Würfel, in einer 3D Umgebung darstellen, fällt dies mit WebGL schon ziemlich kompliziert aus und kann schon an die Hundert Zeilen Code in Anspruch nehmen. Three.js vereinfacht das gesamte Arbeiten mit WebGL ungemein. So lässt sich so ein Vorhaben in three.js sehr übersichtlich und mit wenigen Zeilen Code realisieren.
.png)
Die gesamte Umgebung in three.js, wird eine sogenannte Szene geladen. In dieser Szene können wir dann mit three.js selbst, ohne externe Werkzeuge, alle möglichen Formen und Geometrien erstellen und manipulieren. Was wir in unserem Projekt aber auch genutzt haben, ist das importieren von .glb Dateien. Diese haben wir in Blender designt um Sie dann in unsere Szene einzufügen.
Ein anderes Kernelement in three.js ist die Kamera. Durch die Kamera sehen wir unsere Szene und somit alle unsere Objekte, die wir in der 3D Umgebung platziert haben. Die Kamera bedient sich 2 Koordinaten. Einmal dem Punkt an dem sich die Kamera befindet und dem Punkt wo sie hinschauen soll. Da wir uns in three.js für eine sogenannte Third-Person-Perspektive entschieden haben, setzten wir den Standort unsere Kamera hinter unserer Spielfigur und lassen diese über die Spielfigur hinweg blicken. Die Position der Kamera ändert sich dann mit dem Bewegen der Spielfigur.
Godot ist eine Spiel-Engine, mit der wir einen der beiden Clients programmiert haben.
Godot ist komplett frei und Open-Source unter der MIT-Lizenz.
Es bietet viele Werkzeuge, um die Entwicklung eines Spiels zu vereinfachen.
Wir haben zur serverseitigen Kollisionsabfrage das clientseltige Äquivalent gebaut.
Dies steigert die Usability, da eine serverseitige Kollision vermieden und ein
zurücksetzen
der Figur
verhindert wird.
Dafür wurden die 3D Blender-Objekte importiert und die passenden, vorgefertigten
„CollisionShapes“ darüber
gelegt.
Die gesamte Steuerung erfolgt zunächst in einer orthogonalen Perspektive, die beim Betreten eines Raums in die Ansicht der Egoperspektive übergeht. Beim Verlassen des Raums wechselt die Kamera in die orthogonale Perspektive zurück. Die anfänglich integrierte Kamerafahrt für den Perspektivenwechsel fühlte sich nicht gut an, sodass dieser durch eine Überblendung realisiert wurde. Dafür wurde ein Knoten des Typs „AnimationPlayer“ verwendet, der das Bild kurzzeitig abdunkelt und anschließend wieder erhellt.
Die Figuren der anderen Personen in der Welt werden in Godot zu einer Gruppe
zusammengefasst.
Dadurch ist es möglich Änderungen für alle Figuren, außer der eigenen, durch eine
geringe
Anzahl an
Codezeilen durchzuführen.
Bspw. wird beim Betreten des Raums die Sichtbarkeit der Materialien verringert, damit
durch
die anderen
Figuren durchgeschaut werden kann.
Die vollen Farbwerte der Materialien werden gesetzt, sobald der Raum verlassen wird.
Beim Lesen eines Plakats ist dies dennoch störend, wenn sich eine Figur trotz geringerer
Sichtbarkeit
davor befindet.
Daher besitzt die eigene Figur ein Sichtfeld in Form eines „CollisionPolygon“.
Sobald sich mindestens ein Plakat in diesem Sichtfeld befindet (kollidiert), werden alle
anderen Figuren
innerhalb des Sichtfeldes komplett ausgeblendet.
Dies wird durch das Zusammenspiel der drei clientseitigen Kollisionsobjekte (Plakat,
Sichtfeld, Figur)
möglich.
Bei Blender handelt es sich um eine seit 1995 verfügbare 3D Grafiksuite. Unter einer 3D Grafiksuite versteht man ein Programm, mit welchem Körper modelliert, texturiert und animiert werden können. Diese Schritte können durch den breiten Funktionsumfang von Blender sehr unterschiedlich aussehen und für sehr unterschiedliche Dinge genutzt werden. In unserem Fall haben wir die Spielobjekte mit Blender erstellt, es lassen sich aber auch ganze Filme mit fixen Abläufen in Blender anfertigen (https://www.youtube.com/watch?v=yOUzI5wdKV8). Wie auch bei den vorher bereits vorgestellten Tools war es uns wichtig eine freie Software zu nutzen. Da es sich bei Blender um eine freie, GPL Lizenzierte Software handelt, fiel uns die Wahl leicht.
Als das Modellieren in Blender begann, mussten wir uns auf einen
gemeinsamen Stil einigen. Da das Projekt in Browsern abgespielt
wird und es in übersichtlicher Zeit möglich sein sollte,
anschaubare Resultate zu erzielen, entschieden wir uns für den
Low Poly Stil. Low Poly, bedeutet wörtlich übersetzt wenig
Polygone und es ist genau dies. Objekte werden aus einem Netz von
nur wenigen Polygonen geschaffen, oftmals sehr ähnlich zu dem
Stil von Retrospielen.
Um zu veranschaulichen wie das Modellieren und Texturieren
abläuft, dient die Grafik der Holzkiste. Gestartet wurde hier mit einem
flachen Quadrat auf dem Boden, welches nach oben extrudiert
wurde, dann wurden auf den Seiten die rechteckigen Einbuchtungen
reingeschnitten. In die Einbuchtungen wurden dann nochmal
Einbuchtungen geschnitten, um so einen Plankeneffekt zu haben.
Zum Abrunden gibt es kleinere Cuts für die Holzmaserung und
kleine Verformungen damit die Kiste nicht 100% gerade ist. Das
Texturieren ist in unserem Fall das colorieren der Objekte.
Würden wir das nicht tun, hätten wir eine fade graue Kiste.
Für die Objekte, die im Projekt entstanden sind, haben wir einen eigenen GLB Webviewer. GLB Dateien sind die Dateien, die uns Blender exportiert, welche wir dann wiederum in Godot oder ThreeJS importieren. Der Viewer zeigt uns alle Objekte an, die im Blender Gitlab Branch liegen. So war es für jedes Teammitglied einfach möglich sich den aktuellen Stand anzuschauen, ohne selbst gesonderte Betrachtungswerkzeuge installieren zu müssen. Die Bedienung erfolgt mittels linker Maustaste(Rotation), rechter Maustaste(Verschieben) und Mausrad zum zoomen. Alternativ können auf Touchgeräten die Fingergesten verwendet werden.
Das Modellieren funktioniert analog wie bei den Objekten. Hinzu kommen je noch 2 weitere Schritte nach dem Modellieren. Dies ist einmal die Armature, was so viel bedeutet wie der Figur ein Skelett zu verpassen. Und dann noch das tatsächliche Animieren der Figur. Das Skelett dient der realistischen Bewegung des Körpers, nur so weiß Blender wie sich die Gliedmaßen zu verhalten haben, wenn diese bewegt werden. Das tatsächliche Animieren des Körpers erfolgt dann auf einem Zeitstrahl. Für die Laufanimation startet man so zum Beispiel mit dem rechten Fuß hinten und dem linken vorne und setzt dies auf Punkt 1 auf dem Zeitstrahl. Als nächsten Schritt setzt man dann die beiden Füße genau umgedreht. So entsteht einmal eine Beinbewegung von vorne nach hinten und von hinten nach vorne. Durch das vorher erstellte Skelett ist es Blender nun möglich die Zwischenschritte automatisch aufzufüllen. Was nun noch fehlt ist die Wiederholung. Dafür fügt man nochmal genau die gleichen Animationen bloß spiegelverkehrt hinten an. So erhält man ein Bein, was sich jeweils einmal nach vorne und einmal wieder nach hinten bewegt. Damit ist die Figur fertig, um exportiert zu werden.
Da in unserem Projekt die Welt von verschiedenen Arten von Clients verarbeitet werden müssen, haben wir uns für eine Umsetzung der Assets in GLB-Dateien entschieden. GLBs werden in den meisten Technologien problemlos eingebunden, so auch in unseren Clients auf ThreeJS- und Godot-Basis. Zusätzlich zur Frage der grafischen Darstellung stellte sich noch die Frage der Implementierung der Umgebungs- und Informationsdaten zu den Assets. Nach ein paar Tests hat sich das Verpacken der Daten in obj-Dateien als eine gute Möglichkeit präsentiert, um alle Informationen, die für die Collision-Detection nötig sind, in einer Datei zu verpacken. Vorteilhaft an dieser Umsetzung ist unter anderem, dass die Assets zusammen mit ihren Umgebungsdaten in der selben Nutzeroberfläche erstellt werden können. Dies kann auch von Personen in einem einfachen Prozess umgesetzt werden, die nicht mit der Technik des Projektes voll vertraut sind. Außerdem ist gewährleistet, dass die Modelle und ihre Umgebungsdaten immer miteinander übereinstimmen in Aspekten wie Skalierung, Größe und Rotation.
Bei Learning-Management-Systemen (LMS) handelt es sich im Allgemeinen um Systeme, die das E-Learning unterstützen sollen. Dabei wird der Schwerpunkt vor allem auf die Bereitstellung von digitalen Lehrinhalten zwischen Lehrenden und Lernenden gelegt. Im Falle unseres Projektes, haben wir uns diverse webbasierte Platformen, wie Ilias, IServ oder auch ItsLearning angesehen. Schlussendlich haben wir uns für die Open Source Software Moodle entschieden, welche mit PHP realisiert wurde.
Um Moodle in unsere Test-Infrastruktur zu installieren, wurde die entsprechende Version des offiziellen Git-Repositorys geklont. Über ein interaktives Installations-Skript wurde die Software anschließend installiert. Voraussetzung dafür ist eine Datenbank mit einem entsprechenden Account. In unserem Fall entschieden wir uns für MySQL. Zugangsdaten wurden in eine Konfigurationsdatei im Installationsverzeichnis von Moodle hinterlegt. Nach der Installation konnte über die Website die weitere Einrichtung vollzogen werden. Dazu wurde zunächst ein Administrationskonto erstellt, welches im weiteren Verlauf dazu genutzt wurde, Personen sowie Gruppen anzulegen. Bereits hier merkten wir, dass eine Automatisierung dringend notwendig sein muss, damit komplexere Organisationsstrukturen ohne manuelles Eingreifen importiert werden können. Da Moodle eine REST-Schnittstelle bietet, hofften wir darin Abhilfe zu finden. Diese Schnittstelle musste allerdings erst konfiguriert werden, was mit Hilfe der Entwicklungsdokumentation von Moodle möglich war. Dies verlief zwar nicht immer reibungslos, konnte aber schlussendlich Kernprozesse wie das automatisierte Anlegen von Institutionen, Gruppen und Nutzern darstellen.
Die ursprüngliche Idee war es, die in der virtuellen Lernumgebung erzeugten Dateien ebenfall über einen REST-Endpunkt in eine Gruppe zu laden. In diesem Zusammenhang mussten wir leider feststellen, dass es für diese Funktionalität keine funktionierende Lösung innerhalb der REST-API gab. Daher war es uns nicht möglich dieses Feature im aktuellen Prototypen zu berücksichtigen. Da Moodle allerdings die Möglichkeit bietet, den REST-Service um eigene Funktionalitäten zu erweitern, wäre dies etwas für eine weiterführende Entwicklung.
Im Laufe unseres Projektes wurde entschieden für die Projektanwendungsarchitektur eine modulare Client-Server-Architektur zu gestalten. Hierfür haben wir uns auf ein gemeinsames Protokoll geeinigt, welches vom Server und den Clients implementiert werden muss, damit eine gemeinsame Kommunikation stattfinden kann. Dieser modulare Ansatz bewirkt, dass man nach belieben Server und Client austauschen und in verschiedenen Sprachen implementieren kann. Wir haben eine klare Struktur im Protokoll umgesetzt und es in einem simplen Textformat dargestellt. Hierfür haben wir das Datenformat "CSV" genutzt, da es im Gegensatz zu Datenformaten wie "json", ohne Metadatenbeschreibung auskommt. In einem Testszenario mit 100 Clients haben wir mit "CSV" im Vergleich zu "json" eine Datenreduktion von 500% festgestellt. Im Nachrichtenformat haben wir uns auf Nachrichtarten geeinigt, wie zum Beispiel: "ClientJOIN", "ClientINPUT" und "ServerUPDATE", welche die jeweilige Aktion im Detail beschreibt.
Unser Backend basiert auf dem in Javascript geschriebenen μWebSocket.js und dient als Verbindungsglied zwischen unseren verschiedenen Clientanwendungen. Die Wahl fiel auf μWebSocket.js, da wir während der Evaluation der zu verwendenden Technologien in unserem Projekt für mehr als 300 Clients eine stabilen Verbindung bereitstellen konnten. Die gleiche Anwendung wies dabei unter Verwendung des weit verbreiteten Moduls ws von node.js bereits ab 30+ Clients eine Leistungsminderung auf. Der Server übernimmt in der Kommunikation mit den Clients folgende Aufgaben:
Insgesamt haben wir nun die Möglichkeit, mit 2 verschiedenen, einzigartigen Anwendungen sich mit dem selben Server zu verbinden und zu kommunizieren. Jeder kann nun die Anwendungen starten, egal ob nun Threejs oder Godot, sich darin Bewegen und sich gemeinsam in Räumen begeben und über eine interne Jitsi-Anwendungen kommunikativ austauschen. Dabei wird die Anwendungen automatisch gestartet.
In dem Threejs-Client, besteht die Möglichkeit in der Config verschiedene ressourcensparende Einstellungen vorzunehmen, besonders vorteilhaft ist dies für leistungsschwache Computer. In dem Godot-Client lässt sich die Auflösung der Grafik durch eine Einstellung steigern. Beide Clients fordern zunächst auf einen Benutzernamen anzugeben, mit dem eine Person die virtuelle Welt betreten kann. Dieser Name wird dann in den Jitsi-Räumen angezeigt. Außerdem geben beide Clients zu Beginn Hinweise zur Steuerung der Spielfigur.
Im Rahmen des Projekts wurden anhand einer prototypischen Umsetzung viele Erfahrungen gemacht. Eine Weiterentwicklungen dieser Ansätze sind, z. B. im Rahmen von Bachelorarbeiten oder Folgeprojekten möglich. Um das Konzept zu verbreiten und im Schulkontext weiterzuentwickeln, ist eine Kooperation mit einer Schule oder Klasse sinnvoll. Es gibt noch mehr coole Dinge, die aus diesem Projekt entstehen können. Wenn wir als Projektgruppe weiterarbeiten würden, wären uns folgende Punkte als nächstes wichtig: Der erste Punkt ist, unseren Prototypen in das LMS zu implementieren, damit das Gesamtkonzept verständlicher wird. Als nächstes wäre es großartig, wenn jede Person in unserer 3D-Welt einen globalen Chat haben könnte. Bisher hat jeder Jitsi-Raum einen Chatraum, der von Personen nur genutzt werden kann, wenn sie sich in dem Raum befinden.
Der nächste und wahrscheinlich interessanteste Punkt sind interaktive Elemente und Interaktionen. Wir glauben, dass dies unseren Prototypen attraktiver machen und die Chancen für einen zukünftigen Einsatz erhöhen wird. Aber hier muss gesagt werden, dass wir bereits jetzt eine gute Alternative zu Standard-Videokonferenzen haben. Ein Mitglied aus unserer Projektgruppe sieht einen möglichen Ausblick so: „Konkret wäre dies, die Spielwelt entweder visuell oder durch ein Optionsmenü anzupassen, um so mehr Anwendungsfälle abzudecken. Oder die Spielfiguren farblich / kleidungstechnisch anpassen zu können, um leichter zwischen Personen unterscheiden zu können. Auch wäre eine facettenreichere Gestaltung der Umwelt wünschenswert, um die Orientierung zu erleichtern. Hier könnte man schauen ob sich die Welt weiter optimieren lässt um gleichzeitig die Rechenlast zu mindern.“
