# GridNode – Was hier entsteht (Community-Zusammenfassung)

> Diese Datei ist eine **verständliche Präsentation** für die Community.

## Worum geht es?

GridNode ist eine **komplett neu entwickelte Grid-Server-Software** für virtuelle
3D-Welten – im Stil von OpenSim/Second Life, aber von Grund auf neu in **Rust**
geschrieben (statt Mono/C#). Es ist **kein Fork** von OpenSim und **keine**
Zusammenstellung alter Bausteine, sondern eine eigenständige Software.

**Das Wichtigste zuerst:** Nach außen bleibt GridNode voll kompatibel zu
bestehenden Viewern – **Firestorm, Alchemy, Cool VL** können sich **ohne jeden
Patch** verbinden, genau wie bei einem klassischen OpenSim-Grid. Nach innen ist
aber alles neu, modern, parallel und deutlich schneller.

## Was soll der Unterschied für Nutzer sein?

Betritt jemand mit ganz normalem, unverändertem Firestorm ein GridNode-Grid,
soll er innerhalb der ersten Minute merken:

- **Objekte rezzen in Sekunden statt Minuten**
- **Flüssige Performance**, auch bei vielen Nutzern/Skripten gleichzeitig
- **Fotorealistische PBR-Grafik**
- **Saubere Physik** (Fahrzeuge, Boote, Fluggeräte)
- **Sub-100-ms-Reaktion** bei Chat und Teleport
- **Räumliches Voice-Chat über WebRTC** (moderne Alternative zu Vivox)

Und das alles, **ohne dass der Nutzer irgendetwas umstellen muss**.

## Die wichtigsten Bausteine im Überblick

### 🧱 Physik (Rapier statt ubODE)
Eine moderne, mehrkernfähige Physik-Engine ersetzt die alte, oft instabile
ubODE-Physik – vor allem Fahrzeuge (Autos, Boote, Flugzeuge) sollen deutlich
sauberer funktionieren. Gleichzeitig gibt es feste Schutzgrenzen, damit niemand
durch übermäßig viele Physik-Objekte die ganze Region lahmlegen kann.

### ⚡ Mehrkern-Nutzung
Klassisches OpenSim läuft im Wesentlichen auf einem CPU-Kern. GridNode nutzt
**alle** verfügbaren Kerne der Servers – für Physik, Skripte, Bild-/Mesh-
Verarbeitung, Netzwerk und Datenbank gleichzeitig.

### 🧩 Ein Prozess pro Aufgabe
Bei klassischem OpenSim kann ein einzelner großer Import/Export/Backup die
komplette Region und den Login lahmlegen. Bei GridNode läuft **jede Aufgabe in
ihrem eigenen Prozess** – ein hängender Import-Job reißt weder die Simulation
noch den Login mit.

### 📦 Asset-Speicherung (CAS statt Datenbank-Chaos)
Texturen, Meshes, Sounds & Co. werden inhaltsadressiert gespeichert (über ihren
eigenen Hash) statt als unübersichtliche Datenbank-Blobs. Das bedeutet: keine
doppelten Dateien, echte Backups, und ein funktionierendes Aufräumen
nicht mehr benötigter Assets.

### 📜 Scripting (LSL & LUA, deutlich schneller)
Skripte (LSL wie gewohnt, dazu neu auch LUA) laufen über einen modernen,
sandboxed Interpreter mit klaren Zeit-/Ressourcenbudgets – Skripte können
weder die Region abstürzen lassen noch andere Nutzer ausbremsen.

### 🛡️ Schutz vor Griefing
Jeder Avatar bekommt feste Obergrenzen für Skripte, Objekte, Partikel usw.
Wird das Limit überschritten, wird gedrosselt statt dass die ganze Region
leidet – abgestuft von sanfter Bremse bis Rauswurf.

### 🧍 Avatare & Aussehen
Baked-Texturen (das „Zusammensetzen" des Avatar-Aussehens) laufen serverseitig
und deutlich schneller – kein minutenlanges „grauer Klumpen"-Warten mehr.
Volle Unterstützung für Bento-Skelett, Bakes-on-Mesh und Animesh.

### 🎙️ Voice (Vivox **und** WebRTC)
Bestehende Grids können weiter Vivox nutzen, neue Grids können auf modernes,
lizenzfreies WebRTC setzen – beides funktioniert parallel, mit automatischem
Fallback, falls ein Backend ausfällt.

### 🌐 Kompatibilität mit alten Grids (Hypergrid)
Der Anschluss an bestehende OpenSim-Grids über Hypergrid bleibt vollständig
erhalten. Wer seine alten Sachen (Inventar, Kleidung, Bauwerke) mitbringen
möchte, kann sie per **IAR/OAR-Import** übernehmen.

### 🤖 KI-Agent (optional, für Grid-Betreiber)
Betreiber können optional einen KI-Agenten nutzen, um z. B. per Texteingabe
("Baue eine Fantasy-Waldregion mit Wasserfällen") automatisch Regionen zu
gestalten oder die eigene Region zu überwachen (Performance, Griefing-Erkennung).

### 🖥️ Der große Zukunfts-Baustein: Ein eigener Viewer auf Basis von Unreal Engine 5

Neben der vollen Kompatibilität zu Firestorm & Co. entsteht **zusätzlich** ein
komplett eigener, moderner Viewer auf Basis der **Unreal Engine 5** – der
gleichen Engine, mit der aktuell viele der grafisch beeindruckendsten Spiele
gebaut werden. Das ist kein kleines Grafik-Update, sondern ein echter
Generationssprung für virtuelle Welten:

- **Lumen** – dynamische, echtzeitfähige globale Beleuchtung. Sonnenuntergänge,
  Lichtreflexionen auf Wasser, Innenräume mit realistischem Streulicht – alles
  ohne aufwändig vorberechnete Lightmaps.
- **Nanite** – nahezu verlustfreie Detaildichte für Geometrie. Bäume, Felsen,
  Gebäude können so detailreich sein wie in einem Kinofilm, ohne dass die
  Region einbricht.
- **Fotorealistische PBR-Materialien** – Rinde, Blätter, Wasseroberflächen,
  Metall und Stoff reagieren realistisch auf Licht, statt flach und plastikartig
  zu wirken wie in klassischen Viewern.

**Stell dir vor:** Genau der Baum, der heute schon auf deiner Region steht,
könnte im UE5-Viewer plötzlich so aussehen wie die Bäume, Landschaften und
Lichtstimmungen in den offiziellen Unreal-Engine-5-Demos – die selbe Region,
das selbe Bauwerk, aber in einer völlig neuen visuellen Liga. Ein Eindruck davon,
wozu die Engine grafisch fähig ist, hier in einer Demo-Playlist:

👉 [Unreal Engine 5 – Demo-Playlist auf YouTube](https://www.youtube.com/playlist?list=PLUJgpgwGYs0ZD8x9WjJwWi2V783pxug0s)

Zusätzlich ist im UE5-Viewer ein **moderner Charakter-Creator** geplant –
losgelöst vom klassischen, oft sperrigen Second-Life-Erscheinungsbild-System:
Avatare lassen sich damit anschaulich und direkt gestalten (Körperform,
Gesicht, Hautdetails), statt sich durch verschachtelte Menüs und Alpha-Masken
zu kämpfen.

Wichtig: **Kein Zwang.** Wer lieber bei Firestorm bleibt, verliert nichts –
beide Viewer-Typen können gleichzeitig in derselben Region genutzt werden und
sehen sich gegenseitig.

## Wie wird das gebaut?

GridNode wird in klar abgegrenzten **Bau-Wellen** entwickelt. Jede Welle hat
feste, überprüfbare Test-Kriterien – ein Punkt gilt erst als „fertig", wenn er
nachweislich funktioniert, nicht schon bei einem ersten Code-Entwurf.
Reihenfolge kurz zusammengefasst:

1. **Fundament** – Projektstruktur, Datenbank, Basis-Infrastruktur
2. **Minimaler Login-Kreislauf** – Einloggen, Avatar sichtbar in Firestorm
3. **Physik & Bewegung**
4. **Asset-Speicherung** (Texturen/Meshes vollständig, nicht nur „Root-Prim")
5. **Scripting-Engine** (LSL/LUA)
6. **Migration alter Grids** (IAR/OAR-Import)
7. **Zusatzfunktionen** (Anti-Griefing, Voice, Suche/Directory)
8. **Vorbereitung für den modernen Protokoll-Pfad**
9. **Der eigene UE5-Viewer**
10. **KI-Agent** als optionales Nachrüstmodul

Legacy-Kompatibilität mit Firestorm hat dabei durchgehend Vorrang: der neue
UE5-Viewer entsteht erst, nachdem der klassische Pfad stabil läuft.

---

*Diese Zusammenfassung richtet sich an die Community und wird bei größeren
inhaltlichen Änderungen aktualisiert.*