Exploring real-time physics simulation, deterministic memory allocation, and reusable engine architecture.
Hi DEV Community! 👋
Today, I'd like to introduce Dynquora Physics Engine, a new project developed as part of ConnectApp, my independent initiative focused on creating and sharing open-source software.
Dynquora is a CPU-first physics simulation library for C and C++, built around Extended Position-Based Dynamics (XPBD).
The goal is to explore how to build a lightweight, understandable, and extensible physics simulation foundation while maintaining explicit control over memory, performance, and the public API.
Dynquora is currently a functional MVP, not a production-ready physics engine.
Let's explore what it can do and where the project is heading.
🚀 Why Dynquora?
Physics engines are fascinating pieces of software.
Behind seemingly simple simulations such as ropes, particles, and deformable objects lie interesting challenges involving numerical stability, constraint solving, memory management, and performance.
With Dynquora, I wanted to explore these challenges through a relatively small and understandable codebase.
The project follows several principles:
- Simplicity: start with a minimal physics core rather than a large collection of features.
- Portability: provide a C11-compatible public API that can be consumed from C and C++.
- Predictable memory usage: allocate the simulation storage when creating the context.
- Modularity: separate the physics engine from graphical visualization.
- Transparency: document the algorithms, limitations, and design decisions.
Instead of trying to compete with mature physics engines, Dynquora focuses on providing a foundation for experimentation, education, and further development.
⚙️ What is XPBD?
Dynquora uses Extended Position-Based Dynamics (XPBD), a constraint-solving technique that extends traditional Position-Based Dynamics.
In traditional PBD, constraint stiffness can depend on solver iterations and timestep choices.
XPBD introduces compliance and accumulated constraint multipliers, allowing constraints to represent stiffness more consistently under appropriate simulation conditions.
For a distance constraint between two particles, the solver attempts to satisfy:
C(x) = |xₐ − xᵦ| − L = 0
Where:
-
xₐandxᵦare particle positions. -
Lis the desired distance between them. -
C(x)measures the constraint violation.
The XPBD multiplier correction is:
Δλ = (−C − α̃λ) / (wₐ + wᵦ + α̃)
Where wₐ and wᵦ are inverse masses and:
α̃ = compliance / h²
Here, h represents the substep duration.
Compliance controls how flexible a constraint can be: zero compliance models an ideally rigid distance constraint, while larger values allow greater deformation.
This approach makes XPBD particularly interesting for experimenting with connected particles, ropes, and other constrained systems.
🧩 What does Dynquora currently support?
The MVP implements the essential components of a particle-based simulation:
✅ Particle positions and velocities.
✅ Inverse mass representation.
✅ Gravity.
✅ XPBD distance constraints.
✅ Simulation substeps.
✅ Configurable solver iterations.
✅ Fixed-capacity internal storage.
✅ A C11-compatible public ABI.
One important architectural decision is that the simulation context allocates its internal storage during creation.
After initialization, dq_step does not expand that storage.
The engine also provides a zero-copy particle-view mechanism through dq_particles_acquire.
These views must be released before modifying simulation data or executing another step, and the host must respect the associated generation contract.
A single simulation instance is not thread-safe, so calls must be serialized by the host application.
These design choices make the API's memory and ownership requirements explicit.
🖥️ A graphical viewer with raylib
One of the most interesting parts of developing a physics engine is being able to visualize how its algorithms behave.
For this reason, Dynquora includes an optional diagnostic viewer built with raylib.
The viewer is separate from the physics library, which means graphical dependencies are not required when integrating the simulation core into another application.
The initial demonstration uses an XPBD rope scene.
It also includes simple interaction controls:
-
Space— Pause or resume the simulation. -
N— Advance a single simulation step. -
R— Reset the rope scene.
This provides a useful environment for inspecting the behavior of distance constraints and experimenting with simulation parameters.
🛠️ Building Dynquora
Dynquora uses CMake and requires CMake 3.20 or newer, along with compatible C11 and C++20 compilers.
To build and test the engine:
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel
ctest --test-dir build --output-on-failure
The project also supports an installation step:
cmake --install build --prefix /tmp/dynquora-install
If you want to build the optional graphical viewer, install raylib first.
On macOS, for example:
brew install raylib
Then build the viewer:
cmake -S . -B build-viewer -DDQ_BUILD_VIEWER=ON
cmake --build build-viewer --parallel
./build-viewer/dq_viewer
The physics engine and its visualization tools remain independent, allowing developers to work with the core without introducing unnecessary graphical dependencies.
🔐 Explicit limits and responsibilities
An important part of building reliable software is documenting what it doesn't support.
The current Dynquora MVP does not include:
- Collision detection or broadphase.
- Deformable mesh simulation.
- Multithreaded execution.
- Specialized SIMD acceleration.
- GPU-based simulation.
- Serialization.
- Godot or Unreal Engine integrations.
Custom allocators are also not implemented yet. Although the allocator interface is reserved in the ABI, the current MVP rejects custom allocator configurations with DQ_UNSUPPORTED_BACKEND.
The solver validates numerical inputs and expects finite values, a positive timestep, and non-negative inverse masses and compliance.
Coincident particle positions in distance constraints are skipped in this initial implementation to avoid an undefined constraint normal.
These limitations are deliberate and documented.
🗺️ What's next?
Dynquora is still at an early stage.
Future development may explore collision handling, improved solver capabilities, broader simulation scenarios, and additional performance optimizations.
However, I believe these features should be introduced progressively, supported by tests and clear performance measurements.
For now, the priorities are to keep the core understandable, validate its behavior, and improve the foundation before expanding its scope.
🌍 Part of ConnectApp
Dynquora is developed as part of ConnectApp, an independent software initiative I created to share reusable projects and encourage learning through open-source development.
The broader goal is to build practical applications and technical foundations that developers can study, adapt, and extend.
Dynquora's intended licensing model is Apache 2.0, pending final review of the repository's licensing and attribution files before publication.
🤝 Let's discuss physics engines!
I'd love to connect with developers interested in physics simulation, C/C++, numerical methods, game engines, and low-level software architecture.
If you were building a small physics engine from scratch, what would you prioritize next: collision detection, solver improvements, multithreading, or something else?
I'd be interested to hear your thoughts and experiences.
Thanks for reading! 🚀
Explore ConnectApp
🌐 Website: https://www.connectapp.es
💻 GitHub: https://github.com/ManuelAf-ConnectApp
ConnectApp — Open Source Software. Privacy First. Freedom to Build.
Dynquora is an experimental MVP. Its name and licensing details should be verified before broader distribution.
Top comments (0)