ForgeNG Engine 1.4.1: modulare WebGPU-3D-Engine für anspruchsvolle Projekte

ForgeNG Engine 1.4.1 ist eine modulare WebGPU-3D-Engine für Spiele, Simulationen und interaktive 3D-Erlebnisse in modernen Webbrowsern. Die neue Version vervollständigt eine Architektur, in der zentrale Systeme durch stabile Verträge getrennt sind, während die Standardkonfiguration ohne manuelle Zusammenstellung jedes Subsystems einsatzbereit bleibt.

Die wichtigste Neuerung ist nicht nur eine weitere Renderer-Funktion. ForgeNG trennt den Engine-Kern klar von konkreten Implementierungen für Rendering, Physik, Audio, Eingabe, Speicherung, Animation und Netzwerktransport. Dadurch kann ein einzelnes System unabhängig ersetzt oder weiterentwickelt werden, ohne die gesamte Engine umzubauen.

Was ist ForgeNG Engine 1.4.1?

ForgeNG Engine 1.4.1 ist eine WebGPU-3D-Engine mit konfigurationsgesteuerter Provider-Architektur. Der Standard-3D-Renderer nutzt WebGPU. Andere Systeme können eine Standardimplementierung, eine kompatible Alternative oder – sofern unterstützt – einen deaktivierten Modus verwenden. Der Kern kommuniziert über typisierte Verträge und hängt nicht direkt von den Details eines konkreten Backends ab.

In der Praxis bedeutet das weniger Kopplung, einen vorhersehbaren Ressourcen-Lebenszyklus und bessere Testbarkeit. Jede Engine-Instanz besitzt ihre eigenen Provider und Ressourcen, sodass zwei Spiele auf derselben Seite keinen global veränderlichen Zustand teilen müssen.

Die wichtigsten Funktionen der neuen Version

Modularer WebGPU-3D-Renderer

Der Standard-Renderer verwendet WebGPU und unterstützt Standard-, Instancing-, Maskierungs-, Physik- und benutzerdefinierte WGSL-Shaderpfade. Die Rendering-Infrastruktur umfasst Schatten, Post-Processing und erweiterbare Render-Module. GPU-Ressourcen werden pro Gerät und Engine-Instanz isoliert.

ForgeNG 1.4.1 führt eine klare Renderer-Provider-Grenze ein. Ein kompatibler Renderer kann über die Konfiguration gewählt werden; der Kern wählt keine konkrete Implementierung mehr im Hintergrund. Initialisierung, Größenänderung, Geräteverlust und Herunterfahren besitzen definierte Ownership- und Rollback-Regeln.

Austauschbare Systeme ohne Änderungen am Kern

• Renderer: standardmäßiger WebGPU-3D-Renderer oder kompatibler eigener Provider.
• Physik: ForgePhysics oder ein alternativer Provider mit demselben Vertrag und Lebenszyklus.
• Audio: WebAudio-Provider, eigene Implementierung oder deaktivierter Modus.
• Eingabe: Tastatur, Maus, Mausrad, Touch und Gamepad, pro Canvas isoliert.
• Speicherung: persistenter Browser-Speicher, Memory-Provider oder deaktivierter Modus mit getrennten Namespaces.
• Animation: Skelettanimation als eigener Provider für Modell- und Render-Paletten.
• Netzwerktransport: optionale Transportschicht mit begrenzten Warteschlangen, Backpressure und kontrolliertem Reconnect.

Physik mit klarem Besitz von Szenen und Bodies

Die Physikschicht unterscheidet dynamische, statische und kinematische Bodies. Typisierte Daten beschreiben Formen, Transformationen, Geschwindigkeit, Material und Kollisionsfilter. Jede Szene erhält einen eigenen Physik-Scope; Bodies werden kontrolliert erstellt, gesteuert, als Snapshot gelesen und entfernt. Ein alternativer Physik-Provider kann das Standardsystem ersetzen, ohne Szene oder Kern zu ändern.

Sichere Szenenwechsel und ECS-Integration

Szenenwechsel sind transaktional, fehlertolerant und abbrechbar. Die alte Szene wird nicht vor dem definierten Commit-Punkt der neuen Szene zerstört. Ein fehlgeschlagener Preload oder Setup-Schritt hinterlässt die Engine nicht in einem halbaktiven Zustand. Objektspeicher, Render-Bridge und Lifecycle-Orchestrierung besitzen getrennte Verantwortlichkeiten; das ECS-Scheduling nutzt eine klare Adaptergrenze.

Skelettanimation für glTF- und GLB-Modelle

ForgeNG verarbeitet Skelette, Clips und TRS-Transformationen aus glTF/GLB-Ressourcen über ein providerneutrales Animationsmodell. Der Renderer besitzt die GPU-Paletten für Skinning; dasselbe Ergebnis wird im Haupt- und Schattenpass verwendet. Das aktuelle ABI unterstützt bis zu 128 Joint-Matrizen pro Palette und prüft Grenzen sowie GPU-Cleanup.

Eingabe, Speicherung, Audio und gemeinsame UI-Schicht

Der Browser-Input-Provider verhindert Event-Crosstalk zwischen mehreren Canvas-Elementen und verarbeitet Tastatur-, Maus-, Wheel-, Touch- und Gamepad-Daten. Die Speicherschicht bietet ein persistentes IndexedDB-Backend und eine Memory-Alternative mit isolierten Anwendungs- und Child-Namespaces, atomaren Schreibvorgängen und deterministischer Reihenfolge konkurrierender Operationen.

Das Audiosystem nutzt WebAudio für Wiedergabe, räumlichen Klang, Mixing und Ducking, bleibt jedoch austauschbar und kann deaktiviert werden. Debug- und Systempanels registrieren sich über eine gemeinsame UI-Shell, anstatt dass jedes Subsystem einen eigenen DOM-Rahmen besitzt.

Optionaler Netzwerktransport ohne falsches Versprechen vollständiger Replikation

Die Engine besitzt einen neutralen Transportvertrag und einen optionalen WebSocket-Pfad für zuverlässige, geordnete Binärkommunikation. Sendewarteschlangen sind begrenzt, Payloads werden vor asynchronen Grenzen kopiert, und Reconnect verwendet eine neue Provider-Instanz mit begrenzter Versuchszahl. Automatische Netzwerkreplikation des Spielzustands ist nicht Bestandteil von Version 1.4.1; der Transport bildet dafür eine stabile Grundlage.

Stabilität, Sicherheit und Ressourcenkontrolle

ForgeNG validiert die Konfiguration vor GPU- und anderen teuren Allokationen. Die Initialisierung ist transaktional: Schlägt ein späterer Schritt fehl, werden zuvor erworbene Ressourcen in umgekehrter Reihenfolge freigegeben. Wiederholtes oder paralleles Herunterfahren teilt denselben Abschlussprozess, und das Cleanup wird auch dann fortgesetzt, wenn eine einzelne Ressource einen Fehler meldet.

Shader, Pipelines, Texturen und IBL-Ressourcen sind an ein konkretes GPU-Gerät gebunden. Dadurch können Objekte aus einer anderen Instanz oder von einem verlorenen Gerät nicht versehentlich wiederverwendet werden. Architektur-, Shader-, Typ-Paritäts-, Paket- und Browser-Prüfungen gehören zum Release-Prozess.

Für welche Projekte eignet sich ForgeNG?

• 3D-Spiele, die direkt in modernen Browsern laufen;
• interaktive Produktpräsentationen und digitale Showrooms;
• technische, edukative und physikalische Simulationen;
• Visualisierungen mit eigenen Shadern, Schatten und Post-Processing;
• Projekte mit austauschbarer Physik-, Audio-, Eingabe- oder Speicher-Infrastruktur;
• langfristige Engine-Projekte, bei denen Tests und Ressourcenkontrolle wichtiger als fragile Abkürzungen sind.

Häufige Fragen zu ForgeNG Engine 1.4.1

Verwendet ForgeNG WebGPU?

Ja. Der Standard-3D-Renderer nutzt WebGPU und WGSL-Shader. Version 1.4.1 bietet derzeit einen funktionalen 3D-Modus und bewirbt keinen nicht vorhandenen 2D-Renderer.

Kann ich nur die Physik oder den Renderer austauschen?

Ja. Die Provider-Architektur erlaubt den Austausch eines einzelnen kompatiblen Systems über die Konfiguration, ohne den Kern zu ändern oder zwei Implementierungen desselben exklusiven Slots parallel auszuführen.

Sind Audio, Eingabe und Speicherung enthalten?

Ja. WebAudio-, Browser-Input- und Storage-Schichten stehen mit Standard-, Alternativ- oder deaktivierten Modi zur Verfügung, sofern der jeweilige Vertrag dies unterstützt.

Ist die vollständige Multiplayer-Replikation fertig?

Nein. Die Transportgrundlage einschließlich optionalem WebSocket und kontrolliertem Reconnect ist vorhanden. Die automatische Replikation von Welt und Entitäten bleibt jedoch eine separate zukünftige Phase.

ForgeNG 1.4.1 als Grundlage für die weitere Entwicklung

ForgeNG Engine 1.4.1 markiert den Übergang von einer monolithischen Funktionssammlung zu einem System mit klaren Grenzen, austauschbaren Providern und nachweisbaren Ressourcen-Lebenszyklen. Das Ergebnis ist eine WebGPU-3D-Engine, die komplexe Browser-Szenen ausführen kann und gleichzeitig Rendering, Physik, Animation, Audio, Eingabe, Speicherung und Transport unabhängig weiterentwickelbar hält.