Revel3D

Building the next gaming platform. Sharing the work as we go.

We're building browser-native game technology, from asset ingestion to the final rendered scene. Follow the iterations, the technical lessons, and the progress toward a platform studios can build on.

Read the development journal

Revel3D / In development

Extras / Progress

The development journal.

A closer look at what we're building, how it evolves, and what each iteration teaches us.

Entry 001Rendering / TerminalDevelopment study

Terminal: from ingestion to visual fidelity.

Getting the scene into the browser was the starting point. Understanding how its lighting and materials work together was the real challenge.

The initial ingestion was relatively straightforward with the tools we already had. The more demanding work came afterward: making surfaces respond to light correctly, understanding the material intent, and preserving the character of the original scene.

We made progress by leaning on Three.js's built-in lighting and material capabilities, reducing our reliance on complex custom reflection workarounds. That gave us a clearer foundation for resolving visual differences and refining the result.

v1 Ingestion
Bring the scene across.

Establish the initial import using the existing toolchain. Getting the content into the browser gave us a starting point for the harder lighting and material work.

What we learnedA successful import is the beginning of visual validation.
v2 Faithful recreation
Get the source right.

Focus on recreating the original scene faithfully, aligning lighting and material behavior with the source through the renderer's built-in capabilities.

What we learnedCorrectness needs a faithful reference before enhancement.
v3 Enhanced presentation
Build on that foundation.

Use additional post-processing to enhance the faithful recreation, aiming for an even stronger visual result than the original source material.

What we learnedEvaluate visual enhancements against the established baseline.

Explore Terminal

Open full demo ↗

Explore the scene, then switch device views to see how it adapts to phone and tablet layouts.

Technology

Unlocking the web as a serious gaming platform.

Traditional cloud gaming streams compressed video frames over the network — heavy, lag-prone, and structurally limited. We transmit structured game and render data in the browser's native language. Cloud GPUs handle the calculations the client cannot; the browser renders interactively on-device. That is a different architecture, and a different investment thesis.

Browser-native worlds

Games run interactively on-device in the browser. No server round trip for input, no video stream, no streaming lag. The player gets a real interactive experience — structural differentiation from pixel streaming and cloud gaming.

Bring the assets

Our engine converts and ingests assets from existing game pipelines — geometry, textures, materials, and animation — into validated browser-native bundles. Studios do not start from scratch; they bring what they already have.

Shape the world

Shatter is our in-browser material graph editor. It compiles connected expression graphs into runtime shaders, with per-node object previews and revision-checked saves — the same compiler drives the editor and the game, not a separate hand-authored shader.

Cloud-computed graphics

Our cloud technology handles demanding graphics calculations while the game runs locally. It sends the browser what it needs to draw the scene — surface samples, particle state, lighting data — rather than streaming gameplay as video.

Scene editor

A versioned scene workbench with hierarchy, viewport, inspector, transform gizmos, light authoring, and material assignment. Shatter opens on demand inside the editor; changes commit back with revision-checked transactions.

Agent-ready toolchain

Schema-first contracts and pipeable CLI primitives expose engine state to automated workflows. Development processes are treated as distinct, composable APIs — built for a small team to move faster than a traditional studio pipeline allows.

The engine

A full browser-native stack, not a rendering demo.

Revel3D is organized as a production engine with clear boundaries between reusable runtime code and project content. The public API ships as a standalone package — loaders, schemas, scene operations, animation playback, and asset validation — separate from demo catalogs and example scenes.

Animation & characters

Clip playback, locomotion blending, rig mappings, and reusable character loading — with working combat and locomotion demos.

VFX & particles

Particle simulation, effect rendering, and material graph adapters. Imported VFX graphs compile through the same pipeline as Shatter-authored materials.

Physics & destruction

Destructible geometry, clearance systems, and rebar — subsystem proofs, not a finished physics middleware product.

World & vehicles

Biome layout, grass interaction, modular placement, and procedural vehicle construction. City Drive shares a saved project with the scene editor workbench.

Networking

Shared protocol, client session timing, server identity, and presence — with a local multiplayer server running alongside the development preview.

Rendering

Water contact fields, baked lighting references, reflection probes, and custom shader assemblies. The Terminal lighting reference imports a full architectural scene with 207 instances and 42 materials into the browser.

Asset pipeline

From existing pipelines to browser-native bundles.

Studios already invest heavily in art pipelines, material systems, and scene composition. Revel3D's ingestion path is designed to meet them where they are — converting source assets into validated, browser-ready bundles rather than asking teams to rebuild from scratch.

The asset bundle format validates manifests for materials, meshes, transforms, submesh groups, and texture sampling configuration. Scene documents version nodes, material workspaces, lights, and project metadata — the same schema drives the editor, the runtime, and automated tooling.

Conversion is asset-specific and scorecard-driven, not a universal automatic port. We document what works, what is partial, and what remains blocked — and we expand coverage as capital accelerates pipeline research. Geometry compression is implemented for scene-reference loading, reducing transfer size without changing rendering semantics.

Cloud research

Distinct demonstrations, saved validation evidence.

Cloud graphics and distributed simulation are active research areas with deployed endpoints and saved correctness reports. They are separate demonstrations today — not yet a finished integrated game platform. We state what each demo proves and where visual or validation gaps remain.

Material-lighting stream

Headless cloud GPUs compute diffuse, specular, shadows, and reflections for a full architectural reference scene. The browser receives surface samples and reconstructs per-pixel lighting locally — a continuous stream of render data, not encoded video. Saved validation reports exist; visual parity gaps against the source reference are acknowledged.

Gravity simulation

Heavy particle simulation runs on cloud GPU; binary particle state streams to the browser for local display. Authoritative snapshots at configurable rates with local interpolation — cloud holds simulation authority, the client renders.

Multi-GPU pipeline

A split workload across two physical GPUs — one computes all-pairs gravity, another performs frustum culling, results gather back for browser draw. Correctness has been validated with saved evidence. Throughput advantage has not been proven.

Image streaming

Headless GPU rendering pushes frame buffers to a browser receiver at a target frame rate with bounded backlog. Useful for offline rendering and benchmark scenes; distinct from the material-lighting and simulation streams above.

Why this is a platform,
not a game.

Market shift

The web removes install friction and app store gatekeeping
One build reaches every device with a browser — desktop, mobile, and dedicated handheld shells
Shareable URLs enable link-based discovery and distribution
Console-quality experiences are becoming viable in-browser as runtime capabilities mature
Large browser game platforms already prove audience scale — the infrastructure layer is what is missing

Commercial path

Original games validate and prove the platform with real players
Technology licensing expands reach to external studios
Studios retain a direct relationship with their audience — no store intermediary
Platform economics vs. traditional retail fees and marketplace take rates
Integrated toolchain — engine, editor, Shatter, cloud graphics — is the product, not a porting service

What runs today

Working demos across subsystems.

These are subsystem proofs and research demonstrations — not a shipped product. They show breadth of capability and give investors concrete evidence beyond slide claims.

Terminal lighting reference — full architectural scene imported with baked lightmaps, reflection probes, and custom shader assemblies running in the browser
Shatter shield study — 35 imported material expressions edited in-browser with per-node previews; same compiler drives runtime and editor
Combat & locomotion — animation kits, combat training, and imported weapon attack blending
VFX library — particle effects and imported material graphs rendered through the engine pipeline
City Drive — vehicle driving demo sharing a saved project with the scene editor workbench
Cloud endpoints — live material-lighting stream, gravity simulation, and multi-GPU pipeline with saved validation reports

Where we are

Active research with a clear path to market.

We're building toward a portable platform that developers can use to reach players across devices. Our commercial plan starts with original games and expands into licensing the technology to other studios.

The public engine API, asset schemas, scene editor, Shatter prototype, and cloud demonstrations are built and running. Broader prototype modules remain in migration; asset support varies by format and feature. Lighting and distributed simulation are distinct demonstrations — not yet a finished integrated game platform.

We're raising to continue the research, broaden pipeline compatibility, integrate cloud demonstrations into a cohesive platform, and bring the stack to market.