ForgeNG Engine 1.4.1: a modular WebGPU 3D engine for serious projects

ForgeNG Engine 1.4.1 is a modular WebGPU 3D engine for games, simulations and interactive 3D experiences in modern web browsers. The new version completes an architecture in which major systems are separated by stable contracts, while the default configuration remains ready to use without manually assembling every subsystem.

The most important change is not simply another renderer feature. ForgeNG now clearly separates the engine kernel from concrete implementations for rendering, physics, audio, input, storage, animation and network transport. A single system can therefore be replaced or developed independently without rebuilding the entire engine.

What is ForgeNG Engine 1.4.1?

ForgeNG Engine 1.4.1 is a WebGPU 3D engine with a configuration-driven provider architecture. Its default 3D renderer uses WebGPU, while other systems can use a standard implementation, a compatible alternative or, where supported, a disabled mode. The kernel communicates through typed contracts instead of depending directly on a concrete backend.

In practice, this means lower coupling, predictable resource lifecycles and easier testing. Each engine instance owns its providers and resources, so two games on the same page do not need to share mutable global state.

Key capabilities in the new version

Modular WebGPU 3D renderer

The default renderer uses WebGPU and supports standard, instanced, masked, physics and custom WGSL shader paths. The rendering infrastructure includes shadows, post-processing and extensible render modules, while GPU resources are isolated per device and per engine instance.

ForgeNG 1.4.1 introduces a clear renderer-provider boundary. A compatible renderer can be selected through configuration, and the kernel no longer chooses a hidden concrete implementation. Initialization, resize, GPU device loss and shutdown follow defined ownership and rollback rules.

Replaceable systems without kernel changes

• Renderer: the default WebGPU 3D renderer or a compatible custom provider.
• Physics: ForgePhysics or an alternative provider implementing the same contract and lifecycle.
• Audio: a WebAudio provider, a custom implementation or a disabled mode.
• Input: keyboard, mouse, wheel, touch and gamepad controls isolated per canvas.
• Storage: persistent browser storage, an in-memory provider or a disabled mode with separate namespaces.
• Animation: skeletal animation as an independent provider connected to model loading and render palettes.
• Network transport: an optional transport layer with bounded queues, backpressure rules and controlled reconnect.

Physics with explicit scene and body ownership

The physics layer distinguishes dynamic, static and kinematic bodies. Typed data covers shapes, transforms, velocity, material and collision filters. Every scene receives its own physics scope, while bodies have controlled creation, commands, snapshots and removal. An alternative physics provider can replace the standard system through composition without changing scenes or the kernel.

Safer scenes, transitions and ECS integration

Scene transitions are transactional, failure-safe and cancellable. The old scene is not destroyed before the new scene reaches its defined commit point, and a failed preload or setup does not leave the engine half active. Object storage, the render bridge and lifecycle orchestration have separate responsibilities, while ECS scheduling uses a clear adapter boundary.

Skeletal animation for glTF and GLB models

ForgeNG processes skeletons, clips and TRS transforms from glTF/GLB assets through a provider-neutral animation model. The renderer owns GPU skinning palettes, and the same pose result is used by the main and shadow passes. The current ABI supports up to 128 joint matrices per palette, with bounds checking and controlled GPU resource cleanup.

Input, storage, audio and a shared UI layer

The browser input provider prevents event cross-talk between multiple canvas elements and handles keyboard, mouse, wheel, touch and gamepad data. The storage layer offers a persistent IndexedDB backend and an in-memory alternative with isolated application and child namespaces, atomic writes and predictable ordering for concurrent operations.

The audio system uses WebAudio for playback, spatial sound, mixing and ducking, while remaining replaceable and optionally disabled. Debug and system panels register through a shared UI shell instead of allowing each subsystem to own a separate DOM framework.

Optional network transport without claiming complete replication

The engine provides a neutral transport contract and an optional WebSocket path for reliable, ordered binary communication. Send queues are bounded, payloads are copied before asynchronous boundaries, and reconnect creates a fresh provider instance with a limited attempt policy. Automatic network replication of world state is not part of version 1.4.1; transport is the stable foundation on which that system can be built.

Stability, security and resource control

ForgeNG validates configuration before GPU and other expensive allocations. Initialization is transactional: if a later step fails, previously acquired resources are released in reverse order. Repeated or parallel shutdown calls share the same completion process, and cleanup continues even if an individual resource reports an error.

Shaders, pipelines, textures and IBL resources are tied to a specific GPU device. This prevents accidental reuse of objects from another engine instance or a previously lost device. Architecture, shader, type-parity, package and real-browser checks are part of the release process.

What projects is ForgeNG Engine designed for?

• 3D games running directly in modern browsers;
• interactive product presentations and digital showrooms;
• technical, educational and physics simulations;
• visualizations with custom shaders, shadows and post-processing;
• projects requiring replaceable physics, audio, input or storage infrastructure;
• long-term engine projects where testing and resource control matter more than fragile shortcuts.

Frequently asked questions about ForgeNG Engine 1.4.1

Does ForgeNG use WebGPU?

Yes. The default 3D renderer uses WebGPU and WGSL shaders. Version 1.4.1 currently exposes a functional 3D mode and does not advertise a nonexistent 2D renderer.

Can I replace only the physics system or renderer?

Yes. The provider architecture allows one compatible system to be replaced through configuration without modifying the kernel or running two implementations of the same exclusive slot.

Does the engine include audio, controls and storage?

Yes. WebAudio, browser input and storage layers are available with standard, alternative or disabled modes where their contracts support those choices.

Is full multiplayer replication complete?

No. The transport foundation exists, including optional WebSocket communication and controlled reconnect, but automatic world and entity replication remains a separate future phase.

ForgeNG 1.4.1 as a foundation for further development

ForgeNG Engine 1.4.1 marks a transition from a monolithic collection of features to a system with clear boundaries, replaceable providers and verifiable resource lifecycles. The result is a WebGPU 3D engine capable of running complex browser scenes while allowing rendering, physics, animation, audio, input, storage and transport to evolve independently.