How web developers can build a 3D engine with C++ and Vulkan

Building a 3D engine from scratch is intimidating—especially for developers accustomed to high-level web tools. But the journey from a browser-based mindset to native graphics programming isn’t as steep as it seems. By leveraging C++ and Vulkan, web developers can unlock the raw mechanics behind real-time rendering without sacrificing control or performance.

Why this project started as a personal quest

The motivation behind this project traces back to childhood curiosity. Long before TypeScript, React, or REST APIs defined my daily work, a single game shaped my fascination with technology: Super Mario 64. The moment I first moved through its 3D world, I wondered how the invisible machinery made it possible. What sequence of instructions transformed abstract geometry into pixels on a screen?

This engine, named Ultra as a nod to the original Nintendo 64 prototype label, is my attempt to answer those questions. It’s not a commercial product or a polished library—it’s a learning tool designed to peel back the layers of 3D rendering. The project targets developers like me: those comfortable with JavaScript ecosystems but eager to understand what happens below the abstraction layers they use every day.

The codebase lives on Codeberg, a privacy-focused, European-hosted platform that prioritizes open-source ethics over corporate incentives. You can explore the repository at codeberg.org/remojansen/ultra. There’s no fixed roadmap—only curiosity and incremental progress. Each milestone, from bootstrapping Vulkan to rendering the first triangle, is documented to help others follow the path.

What web developers already know—what they need to unlearn

This series assumes deep familiarity with modern web development. You likely write JavaScript or TypeScript daily, structure your projects with modular patterns, and rely on tools like npm and node to manage dependencies and runtimes. These skills translate surprisingly well into C++ and Vulkan development—but the execution differs dramatically.

Your expertise in browser APIs—DOM manipulation, WebGL, and rendering pipelines—gives you intuition for user interfaces and visual systems. However, C++ demands a shift from dynamic, garbage-collected environments to static, memory-managed execution. You’ll need to adapt to compile-time decisions, manual memory handling, and explicit resource management.

Key concepts like separation of concerns, dependency injection, and layered architecture remain relevant. But instead of expressing them through frameworks, you’ll implement them directly in code—without the safety nets of JavaScript engines or browser optimizations.

The toolchain: from npm to native compilation

JavaScript’s ecosystem revolves around npm install and runtime execution. C++ operates under the opposite paradigm: compilation before execution. This foundational difference shapes every aspect of development.

Clang: turning C++ into machine code

In JavaScript, engines like V8 or SpiderMonkey use Just-In-Time compilation, translating code to machine instructions while the program runs. This allows dynamic optimizations, such as hot path detection, but introduces runtime overhead.

C++ uses Ahead-Of-Time compilation via tools like Clang. Your .cpp files are transformed into optimized machine code before execution begins. There’s no interpreter, no JIT warm-up—just a binary running directly on hardware. This approach eliminates runtime interpretation costs, a critical advantage for real-time graphics where latency matters.

The trade-off is clear: slower startup (compilation happens once, outside the program) and less runtime adaptability. But for a 3D engine processing thousands of vertices per frame, the performance gains justify the workflow shift.

CMake: bridging platforms without rewrites

Web development thrives on cross-platform compatibility. Node.js runs on any system with a JavaScript engine. C++ development, however, varies by compiler, library, and OS. CMake acts as the universal translator.

Instead of writing separate build scripts for macOS, Linux, and Windows, you define your project in a CMakeLists.txt file. CMake reads this file and generates the appropriate build files for your platform—whether that’s Makefiles, Visual Studio projects, or Ninja build scripts. This abstraction allows a single codebase to compile consistently across environments without modification.

Our project defines two key targets:

• ```cmake

Build the engine as a static library

file(GLOB_RECURSE ULTRA_SOURCES src/engine/*.cpp) add_library(ultra_engine STATIC ${ULTRA_SOURCES}) target_include_directories(ultra_engine PUBLIC ${CMAKE_SOURCE_DIR}/src) target_link_libraries(ultra_engine PUBLIC glfw Vulkan::Vulkan)

- ```cmake
# Build the demo application as an executable
file(GLOB_RECURSE DEMO_SOURCES src/demo/*.cpp)
add_executable(demo ${DEMO_SOURCES})
target_link_libraries(demo PRIVATE ultra_engine)

A static library (ultra_engine) bundles compiled functions into a reusable archive. It’s analogous to a .jar file in Java or a compiled npm package—it contains code but cannot run independently. An executable (demo), by contrast, is a standalone binary with a defined entry point (main()).

During linking, the compiler resolves references between the executable and the library. Functions called in demo but defined in ultra_engine are resolved by copying the corresponding machine code from the static library into the final binary. The result? A single, self-contained executable (demo) that contains all necessary logic—no runtime dependencies, no hidden magic.

What’s next: from bootstrapping to rendering

This first installment lays the groundwork: installing Clang, configuring CMake, and structuring a project that bridges web development intuition with native performance. The next steps will dive into Vulkan’s initialization, swap chain setup, and the first triangle rendered on screen.

The goal isn’t to build a production-ready engine—it’s to equip developers with the mental model to understand how pixels become worlds. Whether you’re optimizing a game loop or diagnosing a rendering artifact, the knowledge gained here applies far beyond any single framework.