Crankwave: A Detailed Look at the Open-Source Engine Sound Simulation and Baking Tool

From Physics Simulation to Game-Ready Audio

Realistic vehicle engine sound has always been a core experience element in racing games and automotive simulation software. Traditionally, developers either use pre-recorded audio samples or run full physics engine simulations at runtime. The former lacks dynamic responsiveness, while the latter imposes a heavy performance burden. The open-source project Crankwave attempts to find a balance between the two.

Realistic engine sound is not a single-frequency sound wave but rather a complex audio signal produced by the superposition of multiple physical processes. The sound of an internal combustion engine primarily comes from: combustion burst pressure waves within the cylinders, airflow pulsation and resonance in the intake and exhaust pipes, vibrations from mechanical components like the crankshaft and connecting rods, and the harmonic characteristics of the exhaust system. Different cylinder counts (such as V6, V8, inline-four), cylinder bank angles, firing orders, and exhaust pipe layouts produce distinctly different exhaust notes—this is why a Ferrari V12 sounds completely different from a Porsche flat-six. Physics-level simulation requires solving fluid dynamics equations and pressure wave propagation at extremely high sampling rates (typically far exceeding the audio standard of 44.1kHz), making the computational load enormous. This is precisely the fundamental reason why real-time simulation has been difficult to adopt widely in games.

According to project author SvetlozarValchev, Crankwave is an engine sound simulator and responsive audio baking tool licensed under MIT. It was born from a specific engineering need: how to use simulated engine sound effects in games without having to bring the entire physics simulation process into the game runtime.

Crankwave's Relationship with engine-sim

Crankwave is not a project built from scratch but rather a "source-informed rewrite" of the well-known open-source author AngeTheGreat's engine-sim project. AngeTheGreat's original engine-sim gained widespread attention in the developer community for its physics-level simulation of internal combustion engine operating principles, capable of authentically reproducing the unique exhaust notes produced by different cylinder configurations, firing orders, and exhaust structures.

In open-source software development, a "source-informed rewrite" is a development strategy that falls between completely independent development and a direct fork. A fork means modifying and extending upon the original codebase, retaining the original code's architecture and most implementation details, with the possibility of syncing with the upstream project later. A source-informed rewrite means the developer has thoroughly studied the original project's source code, fully understanding its algorithms, physical models, and design decisions, then writing an entirely new code implementation from scratch. The advantage of this approach is that it allows for a complete redesign of the code architecture, data flow, and API interfaces to meet different engineering goals—such as better modularity, clearer interface boundaries, or optimizations for specific use cases—while avoiding missteps that could arise from misunderstanding the original algorithms.

Building on this physics simulation approach, Crankwave has undergone extensive engineering refinement to make it more suitable for integration and use in production environments. This approach of "rewriting" rather than "forking" means the author reorganized the code architecture and data flow after deeply understanding the original implementation principles.

Core Features in Detail

JSON-Defined Engine Configuration

Crankwave uses JSON format to define engine parameters. This design lowers the barrier to entry—developers don't need to modify source code and can describe different engine structures through configuration files alone. This data-driven approach makes engine tuning and iteration more intuitive, and is also convenient for version control and team collaboration.

Data-Driven Design is an important paradigm in modern software engineering, with the core concept of separating behavioral logic from configuration data. In the context of engine sound simulation, JSON configuration files can define dozens of physical parameters such as cylinder count, arrangement (V-type/inline/flat), bore, stroke, firing order, exhaust pipe length and diameter, throttle characteristics, and more. Compared to hardcoding these parameters in source code, the JSON configuration approach allows non-programmers (such as sound designers or vehicle engineers) to directly participate in engine sound tuning. Additionally, as a plain text format, JSON naturally supports diff comparison and merge operations in version control systems like Git, making it well-suited for team collaboration scenarios.

Native and WASM Dual Execution Environments

The project supports both native execution and WebAssembly (WASM) execution. Native execution ensures high performance in desktop and game environments, while WASM support opens up the possibility of running in browsers. This means developers can audition and debug engine sounds in real-time on a webpage without setting up a complex local environment.

WebAssembly is a binary instruction format for the Web, standardized by W3C and natively supported by all major browsers. It allows code written in system-level languages like C, C++, and Rust to be compiled into compact bytecode that runs at near-native speed within the browser sandbox. For a computationally intensive audio simulation tool like Crankwave, WASM support means developers can run physics simulations and audition in real-time directly in the browser without downloading or installing any local software. This is significant for rapid prototyping, remote collaboration, and building online engine sound editors. WASM's deterministic execution characteristics also align with Crankwave's pursuit of deterministic baking—the same WASM code produces consistent computational results across different browsers and operating systems.

Live Auditioning

Crankwave provides a live auditioning feature that lets developers instantly hear the sound changes resulting from parameter adjustments, greatly improving sound design efficiency.

Deterministic Baking

The project's deterministic baking capability is one of its core highlights. Baking refers to pre-processing the computational results of physics simulation into audio data that can be played back directly. "Deterministic" means that the same input will always produce the same output, which is crucial for ensuring consistency across different platforms and runtime environments.

Audio Baking borrows the concept of "baking" from the graphics rendering domain. In graphics, lightmap baking involves pre-computing global illumination, shadows, and reflection effects in a scene, storing the results as lightmaps that can be sampled at runtime without real-time ray tracing. Audio baking follows a similar approach: pre-computing the engine sounds generated by physical simulation under different RPMs, throttle positions, and load conditions, then storing them as a set of audio data and metadata. At runtime, the playback engine intelligently interpolates and blends between these pre-baked audio segments based on current game state parameters (such as real-time RPM and throttle position), reproducing simulation-quality sound with minimal CPU overhead. "Deterministic" ensures that regardless of which machine performs the baking process, the output audio data will be exactly the same as long as the input parameters are identical—this is crucial for CI/CD pipeline automated builds and cross-platform consistency verification.

Simulator-Free Playback

This is Crankwave's most practically valuable feature. After baking, the audio enables simulator-free playback—the game runtime no longer needs to carry the full physics simulation logic and can simply play back the baked responsive audio. This directly addresses developers' core pain point: enjoying the realistic sound quality of physics simulation while avoiding the runtime performance overhead.

Architecture Design Decoupled from Game Engines

Crankwave itself does not depend on any specific game engine. The author demonstrated its integration with SPARQ in a demo video but explicitly stated: the simulator, baker, audio format, and playback runtime are all included in the MIT-licensed open-source repository.

This decoupled design gives the project tremendous versatility. Whether developers are using Unity, Unreal, or a custom engine, they can theoretically integrate engine sound effects through the runtime provided by Crankwave. The MIT license also means commercial projects can use it freely, which is especially friendly to indie game developers and small studios.

Practical Significance for Game Developers

Crankwave represents a pragmatic engineering approach: separating computationally intensive simulation processes from lightweight runtime playback. This "offline simulation + runtime playback" pattern has long had mature practices in the graphics rendering field such as lightmap baking, and Crankwave cleverly applies it to the audio domain.

This architectural pattern has extensive precedent in game development. Beyond lightmap baking, pre-computation of navigation meshes (NavMesh), simplification of physics collision bodies, and preprocessing of occlusion culling data all follow the same principle: completing computationally intensive processing that isn't time-sensitive during the development phase offline, with only lightweight queries and interpolation performed at runtime. In the audio domain, commercial audio middleware like Wwise and FMOD also employ similar "preprocessing + runtime mixing" strategies to handle complex sound scenarios. What makes Crankwave unique is that it combines physics simulation-level engine sound generation with this mature engineering architecture, providing a complete toolchain as open source—from the simulator and baker to the runtime player, forming a closed-loop workflow.

For racing games pursuing realistic driving experiences, automotive configurator software, and even educational demonstration tools, such an open-source tool undoubtedly lowers the technical barrier to achieving high-quality dynamic engine sound effects. Interested developers can visit its GitHub repository to learn more and try it out.

Conclusion

As an open-source project born from practical needs and built upon excellent prior work, Crankwave demonstrates the value of community collaboration. It neither reinvents the wheel nor simply copies, but instead makes targeted engineering optimizations for real pain points in production environments. For technology enthusiasts interested in audio technology, game development, or physics simulation, this is an open-source practice worth following.