Path traced. GPU driven.

Started before AI and developed alongside me while in the game industry.

         

12 YEARS IN DEVELOPMENT

1 ENGINEER

600+ ENGINEERS ON DISCORD

200 Hz VEHICLE SIMULATION

PLATFORMS			GRAPHICS APIS
Windows	Linux	macOS	DirectX 12	Vulkan	Metal

Overview

Spartan is a complete C++ game engine. Path-traced global illumination, hardware ray tracing, a bindless GPU-driven renderer and a racing-grade vehicle simulation sit alongside what a shipped game needs:

Editor

Lua scripting for gameplay

Standalone runtime

Game builder packages a world into a distributable game

Steam achievements, stats and rich presence

The bundled worlds show the range, from Plan, a playable racing game across the island of Zakynthos, to path-traced interiors and a car showroom. Its rendering technology ships in Godot Engine and S.T.A.L.K.E.R. Anomaly, it features in a published programming book, and more than 600 engineers follow its development on Discord.

Important

Built for veterans. Spartan is one engineer's engine, so there is no support queue and no one-to-one help. There is a wiki, a Lua scripting guide and a codebase written to be read. If you are a high-agency engineer who can take it from there, you can ship with it.

Showcase

ZAKYNTHOS  ·  an island some 30 km across with towns, an airport, 200+ spline roads, instanced forests and an FFT ocean
ISLAND COAST  ·  dynamic time of day, atmospheric scattering, shallow-water caustics	SPONZA  ·  ReSTIR path tracing, no light probes, no bake
SHOWROOM  ·  LaFerrari lit by three emissive tubes through volumetric fog	CAR PAINT  ·  layered clearcoat and ray-traced reflections
LIMINAL OFFICE  ·  procedural and streamed, path traced, no bake

_{All real-time captures. Every world is fully simulated: walkable, interactive and drivable.}

Features

No bake ReSTIR path-traced global illumination every frame. No probes, no lightmaps.

One draw per pass The GPU owns the data. Bindless buffers, GPU culling, a single indirect draw.

200 Hz Racing-sim vehicle dynamics inside a general-purpose engine.

_{Expand a section for the full breakdown.}

Lighting and global illumination  ·  _{ReSTIR, ray tracing, IES profiles, clouds, fog, FFT ocean}

• ReSTIR path tracing with spatiotemporal reservoir resampling for real-time multi-bounce global illumination
• Clustered deferred shading with a GPU-built logarithmic-Z grid and cone-vs-AABB culling for spots, so many local lights cost near-constant time per pixel
• IES photometric light profiles (LM-63): spot lights emit the measured beam of a real fixture, from car headlights with regulation cut-offs to architectural downlights, with correct lumens and candela across direct lighting, volumetric fog and path tracing. A feature usually reserved for the big commercial engines
• Hardware ray-traced reflections and shadows via ray queries
• Atmospheric scattering and image-based lighting with bent normals
• Volumetric clouds (Nubis-style) baked into the sky panorama, with cumulus and cirrus layers, multi-scatter lighting and aerial perspective
• Froxel volumetric fog: one view-aligned volume for height and distance fog, sun shafts and underwater caustic shafts, with temporal reprojection and shadowing
• FFT ocean with a Tessendorf spectrum and multi-cascade IFFT in compute, driving a camera-following clipmap with choppy displacement, dynamic normals and crest foam
• Screen-space shadows (inspired by Days Gone) and XeGTAO ambient occlusion
• Shadow map atlas with fast filtering and penumbra estimation

Rendering architecture  ·  _{bindless, GPU-driven, meshlets, universal HLSL}

Geometry, materials, textures, lights, transforms and bounds live in persistent, globally accessible buffers. No per-draw descriptor updates, no per-draw resource binding, no CPU-side draw loops.

• Zero-binding draw path: all per-draw data lives in a single bindless storage buffer, push constants carry only an index
• Single global vertex and index buffer for all geometry (inspired by id Tech), with vertex pulling that bypasses the Input Assembler and is shared by rasterization and ray tracing
• GPU-driven indirect rendering with per-meshlet frustum, Hi-Z occlusion and backface cone culling; the CPU issues a single DrawIndexedIndirectCount per pass
• Meshlet clustering via meshoptimizer, with mesh shaders when available and a vertex-pulling fallback
• Bindless everything: materials, lights, samplers, uber shaders, minimal PSO permutations
• Universal HLSL compiled for Vulkan (SPIR-V), DirectX 12 and Metal (Metal Shader Converter)
• GPU-side asset processing: mip generation (FidelityFX SPD) and texture compression (Compressonator) at load time, not baked offline
• Unified deferred rendering: opaque and transparent surfaces share the same BSDF and render path
• Async compute for SSAO and screen-space shadows, in parallel with shadow rasterization

Performance, camera and post-processing  ·  _{DLSS 4.5, XeSS, FSR 4 upscaling, FSR 3.1 frame generation, TAAU, VRS, GT7 tonemapping, HDR10}

• NVIDIA DLSS 4.5 Super Resolution (SDK 310.9.1) and Intel XeSS 2.0.2 (SDK 3.0.2)
• AMD FSR upscaling (FSR SDK 2.4.0) on Windows with Vulkan and D3D12. Select AMD FSR in Renderer Options (or r.antialiasing_upsampling 5). The SDK selects FSR 4.1.2 on supported Radeon GPUs and FSR 3.1 on other supported GPUs. Run dependency setup to fetch the signed loader and upscaler DLLs. Frame generation retains its existing, separate SDK.
• AMD FSR 3.1 frame generation (FidelityFX SDK 1.1.4) on Vulkan and D3D12, works on any vendor's GPU, with frame-generation-aware fps, latency and frame rate limiting
• TAAU: temporal anti-aliasing with built-in upsampling, Halton jitter and variance-clipped history
• Variable rate shading and dynamic resolution scaling
• Foliage impostors as the final GPU LOD, so dense forests stay cheap at distance
• Texture streaming within a fixed memory budget
• Custom GPU breadcrumbs for crash tracing and post-mortem debugging
• Physically based camera with auto-exposure and physical light units (lux, lumens and kelvin)
• Tonemappers: ACES, AgX and Gran Turismo 7 (default), with HDR10 output
• Post-processing: bloom, motion blur, depth of field, chromatic aberration, film grain and sharpening (CAS)

Vehicle dynamics at 200 Hz  ·  _{Pacejka tires, thermal brakes, LSD, aero, force feedback}

A full vehicle dynamics model running inside the PhysX fixed-timestep loop. Not a gameplay approximation: racing-sim fidelity inside a general-purpose engine.

System	Details
Tires	Pacejka MF 5.2 with combined slip, thermal model, pressure, wear and multiple surfaces
Suspension	Convex hull sweep contact, spring-damper, anti-roll bars, bump stops, bump steer, camber and toe
Weight transfer	Geometric and elastic lateral split via roll centre heights and roll stiffness
Drivetrain	Engine torque curve, turbo, 7-speed gearbox, rev-match, open, locked and limited-slip differentials, RWD, FWD and AWD
Brakes	Thermal model with fade, front/rear bias and slip-threshold ABS
Aerodynamics	Drag, front and rear downforce, ground effect, DRS and rolling resistance
Steering	Ackermann geometry, high-speed reduction and self-aligning torque
Assists	ABS, traction control and handbrake
Integration	Semi-implicit Euler with consolidated net torque per wheel
Input	Controllers and steering wheels with haptic feedback
Camera	GT7-inspired chase camera with speed-based dynamics

Engine systems  ·  _{physics, animation, particles, weather, roads, Lua, audio, editor, profiler, VR}

System	Details
Platforms	Windows (DirectX 12 and Vulkan), Linux (Vulkan) and macOS 26.0+ (Metal 4), with prebuilt binaries in every release
Physics	PhysX with rigid bodies, character kinematics and vehicle dynamics
Animation	Skeletal animation with keyframed clips, crossfade blending, four-bone skinning and two-bone IK with ground-aware foot planting
Particles	GPU-driven compute emission and simulation, depth-buffer collision and soft blending
Weather	Rain that soaks exposed surfaces, fills puddles and keeps covered areas dry, feeding tire grip
Procedural roads	Catmull-Rom spline roads with extruded profiles, terrain conforming, instanced props and path followers
Scripting	Lua 5.4 via Sol2 with the full engine API and lifecycle callbacks
Audio	3D positional audio, streaming, reverb and procedural engine synthesis via SDL3
Cinematics	Camera cut sequencer with entity tracking, spline-driven movement and exact cut timing
Entity system	Component-based with transform hierarchies, prefabs and XML serialization
Threading	Hardware-aware thread pool with parallel loops and nested parallelism detection
Editor	Hierarchy, asset browser, inspector, script and shader editors, gizmos, profiler and memory viewer
Profiling	Nsight/RGP-style timeline with graphics and async compute lanes, RenderDoc integration and a GPU/CPU memory fragmentation map
Asset import	40+ model formats (Assimp), 30+ image formats (FreeImage), 10+ font formats (FreeType)
VR (WIP)	OpenXR with multiview single-pass stereo on Vulkan and DirectX 12

Quick start

Tip

Just want to try it? Prebuilt binaries ship with every release. Building from source? The Building Guide has the details.

  Windows

# then open spartan.slnx (use d3d12 for DirectX 12, or no arguments for a menu)
generate_project_files.bat vs2026 vulkan

  Linux

tools/linux_dependencies.sh && ./generate_project_files.sh gmake vulkan && make config=release_x64

  macOS 26.0+  _{Apple silicon, Metal 4}

# needs Xcode 26, Homebrew (brew install cmake ninja) and the Metal Shader Converter
# from developer.apple.com/metal/shader-converter, then open spartan.xcworkspace
tools/macos_dependencies.sh && ./generate_project_files.sh xcode4 metal

Worlds Live in worlds/ as XML. Their assets live in binaries/project/, excluded from Git and downloaded during setup.

Start reading Engine.cpp, the entry point.

Gameplay code The Lua Scripting Guide.

Build targets and architecture notes

The binaries/ folder keeps executables at the top level. Windows vendor DLLs live in third_party/ (Direct3D Agility components in third_party/d3d12/), compiler intermediates and Windows symbols in build/, preferences in settings/, diagnostics in logs/, and engine-wide generated data in cache/. Existing preferences, logs, and engine caches migrate on first launch without replacing files already at the new locations. World-specific bake caches remain alongside their world resources. data/, project/, and crashes/ retain their existing roles. steam_appid.txt stays beside the executable for local Steam development. Ship the vendor folder with the executable; game exports and Windows release archives preserve its structure. Python bytecode caches are excluded from game exports.

Project generation creates these targets, all using the selected graphics backend:

Target	What it is	Executable
Spartan	The editor	spartan_<backend>_development.exe
SpartanRuntime	The game and HUD, without editor widgets	spartan_<backend>_runtime_development.exe

The runtime targets take an existing world with --world <absolute-world-path> and start play once it is prepared. Resource paths remain relative to the executable, as in the editor. The editor's -game option hides its panels.

With dependencies already installed, regenerate without downloading them:

tools/premake5.exe --file=tools/premake.lua --skip-setup vs2026 vulkan

# macOS
tools/premake5 --file=tools/premake.lua --skip-setup xcode4 metal

Engine and world boundary. There is no game layer in C++. source/world/WorldSystems.cpp installs the world lifecycle hooks: camera controls, vehicle render submissions, breakable trees and the optional world systems (ambient wildlife, ambient atmosphere, road details, layered road surfaces). Vehicle physics and state live under source/car, vehicle MCP commands in source/mcp/McpCommandsCar.cpp, and traffic, race drivers, route drivers, car resets and skid marks are regular components in source/world/components. The optional world systems are off by default; a world turns them on through the WorldSystems Lua table from its companion script, the .lua with the same name next to the .world (worlds/plan.lua for plan.world), which runs on every load before the roads are built. Worker model imports publish their entity hierarchy through World::EntityBatch::Commit() after construction succeeds.

Physics. Scene stepping and contact observation use game-independent callbacks; the game installs vehicle contact handling. Vehicle state is opaque to engine consumers, while the existing Physics authoring and Lua API remains compatible.

Asset ownership. World saves record native asset ownership in OwnedResources. Automatic cleanup only removes unreferenced files recorded there; unlisted files, shared libraries, sculpt data and generated caches keep their separate lifetimes. Legacy worlds acquire ownership of referenced assets when saved and do not prune unrelated legacy files.

Component attributes. Attributes exposed for editing go through the component's setters. Raw copy-only or derived fields are read-only; use the named authoring properties for edits.

Play lifecycle. Play startup captures all authored transforms before any component starts, with both phases spread across frames. Stopping play drains completed worker batches before restoration and removal. World unload cancels staged work and clears renderer scene references and temporal history while preserving device lookup tables.

In the wild

Godot Engine Integrates Spartan's TAA Source →

S.T.A.L.K.E.R. Anomaly Ships a rendering addon built on Spartan's source ModDB →

Published book Jesse Guerrero's beginner programming book features Spartan's code and community Amazon →

Origin A portfolio piece at the University of Thessaly under Professor Fotis Kokkoras

_{Projects built on Spartan code can be featured here. Get in touch →}

Ready for games?

Yes. Older coverage, like "The BEST Game Engine You SHOULDN'T Use", describes an engine that no longer exists. Back then Spartan was a renderer. Today it has the scripting, runtime, packaging and Steam support to ship, and graphically it goes further than any other open-source engine.

The one thing that hasn't changed is support: if you need hand-holding, pick something else. If you don't, Spartan is ready.

Community

Discord Rendering deep dives and work in progress, with 600+ engineers. Contribute Contributors get exclusive perks designed to accelerate learning. Sponsor Funds the hosting behind the one-click setup.

Podcast  ·  Exploring the tech world and beyond, conversations across cutting-edge industries, on YouTube and Spotify

License

Note

Free for noncommercial use under the Spartan Engine License 1.0. Commercial use requires prior written permission and negotiated payment terms.

License summary

The license permits free noncommercial use, modification, and redistribution, including reuse of covered code in other projects. Keep the copyright notice identifying Panos Karabelas and the license with redistributed code; compiled distributions must carry them in documentation or accessible legal notices.

Commercial fees, royalties, or a combination are agreed case by case, with no automatic rate or revenue threshold. This applies to the engine and covered code copied into other games, engines, libraries, tools, or applications. Contact Panos Karabelas to discuss your project.

Third-party components retain their own licenses. Copies and versions previously released under MIT retain their existing permissions. See license.md for the complete terms.

_{Built by Panos Karabelas  ·  12 years and counting}