Browser-native 3D engine, no install: Gessa vs Unity vs Unreal
Last verified 2026-09-06 against engine v1.0.232. Competitor sources were accessed 2026-09-06; every Gessa cell binds to the generated engine reference and the build fails if a bound surface disappears.
Gessa's editor and its player both run in a web browser: a creator authors a 3D world and a player opens it from a URL, with no engine or editor download on either side. That is the moat this page leads with. The honest tradeoff is rendering budget: a browser runtime cannot spend what a native desktop or console target spends, so Gessa's dynamic global illumination is baked rather than fully dynamic, and it has no Nanite-class virtualized-geometry system. Unity and Unreal render at a higher native ceiling and require an installed editor to author and a per-platform build to ship.
Where Gessa stands
| Capability | Gessa | Unity | Unreal |
|---|---|---|---|
| Author and play in a browser, no editor install | Supportedplayable_runtime_surface | Editor install required unity 6000.3 | Editor install required unreal 5.8 |
| Physically based materials and a material graph | Supportedcheck:material-graph-contract | Supported unity 6000.3 | Supported unreal 5.8 |
| Real-time lighting and shadows | SupportedLightComponent | Supported unity 6000.3 | Supported unreal 5.8 |
| Reflections and image-based lighting | SupportedReflectionProbeComponent | Supported unity 6000.3 | Supported unreal 5.8 |
| Fully dynamic global illumination (Lumen-class) | PartialReflectionProbeComponent | Supported unity 6000.3 | Supported unreal 5.8 |
| Virtualized geometry, cluster LOD (Nanite-class) | Not yetrenderer.virtualized_geometry | No virtualized-geometry system unity 6000.3 | Supported unreal 5.8 |
| Particle and visual-effect systems | SupportedParticleEmitterComponent | Supported unity 6000.3 | Supported unreal 5.8 |
RenderableComponent, LightComponent, ReflectionProbeComponent, MaterialInstanceOverrideComponent, and ParticleEmitterComponent are the atomic surfaces behind these rows; the material graph row is backed by the check:material-graph-contract gate and the effect stack by check:renderer-effect-contract in the build.
The gaps, named here
- Global illumination is baked, not fully dynamic. Gessa lights a world with image-based lighting and reflection probes baked at edit time, which the
ReflectionProbeComponentsurface carries; it does not run a Lumen-class real-time dynamic global-illumination solver. The cell reads partial for that reason. - There is no Nanite-class virtualized geometry. The Nanite row reads not_yet, and its binding names that gap on purpose rather than standing on a surface that does not exist. Cluster-LOD work is proven only through the GPU-driven render-path gates, not as a shipping virtualized-geometry feature.
- The browser is the budget ceiling. Even where a Gessa render feature reads supported, it runs inside a browser GPU budget that a native desktop or console target does not share, so photorealism ceilings differ from a native engine even when the feature list overlaps.
Where Unity and Unreal are ahead
- Unreal renders virtualized geometry with Nanite and fully dynamic global illumination and reflections with Lumen as first-party native systems. See the Unreal Nanite and Lumen documentation cited in the table.
- Unity's High Definition Render Pipeline targets high-end native hardware with real-time global illumination, reflections, and a mature Shader Graph and VFX Graph. See the Unity documentation cited in the table.
- Both engines author in an installed editor and ship native desktop and console builds, so their renderers can spend a per-frame budget a browser runtime does not have.
Gessa's answer is not to match a native renderer's budget. It is to render physically based, real-time 3D that authors and plays in a browser with no install, and to be explicit that its global illumination is baked and it has no virtualized-geometry system. The other comparison axes are in the compare index.