About DSFE

The Dynamic Systems Framework Engine (DSFE) is a final year Computer Science project developed to support the design, simulation, and analysis of numerical integration methods under varying dynamic conditions in single or many-body systems.

Although physically grounded, DSFE prioritises numerical-transparency first, and visualisation second. The framework is designed for researching mathematic models through controlled numerical simulations, producing reproducible amd quantitative output data while remaining consistent with physically-valid system and enivronment parameters.

DSFE integrates real-time visualisation using OpenGL, GLSL, GLM, and ImGui to introduce interpretable representations of system behaviour. The visual layer is an addition with the intention of complementing, not replacing, the underlying numerical analysis.

The framework also includes the Dynamic Systems Language (DSL), a domain-specific scripting langauge that enables exact experiment reproduction, parameter control, and determinisitic test execution - one of the biggest reasons for adding DSL.

As an independant an extensible final year project, DSFE allows users to:

• Define custom dynamic systems
• Import external models
• Design their own DSL scripts
• Build their own experimental regimes
• Run in either batch or GUI mode
• Run parallel instances without file restrictions

This open architecture intentionally avoids hidden "Black-Box" abstractions, and instead favours transparency, reproducibility, and research flexibility.

Disclaimer:
The DSFE software has been developed, released, and maintained soley by me(@SaltyJoss).
If you identify any significant bugs, logical inconsistencies, implementation errors, or any citation issues, please open an Issue or contact me directly via GitHub.

Constructive feedback and technical corrections are welcomed, as they contribute to improving both the software and my understanding of the subject matter.

Project Motivation:

While DSFE originated as a final-year project, it reflects a sustained interest in computational mathematics, computational physics, and their application to space-oriented dynamical systems.
I hope that this repository will continue to evolve as the underlying numerical methods, modelling strategies, and experimental frameworks are refined and extended. This project forms part of a broader and continuing exploration into how mathematical models govern the behaviour of physically motivated dynamical simulation environments.

Installation

Pre-Requisites:

Before donwloading the latest release, you will need to have installed the following:

• Latest Visual C++ Redistributable
  

DSFE Installation:

Download the latest release of DSFE from Release in the DSFE GitHub Repository:

• Latest Release of DSFE
  

Running DSFE

Versions v0.8.0r-alpha and below

As an executable

• Download and extract the files from the latest release of DSFE and run the executable (Engine.exe on Windows) as you would any other binary!

Batch mode (CLI)

• Open a terminal in the extracted release folder and run the engine in --batch mode to execute a DSL script that automates simulation sweeps.

# Show help / usage
PS C:\Users\SaltyJoss\dsfe-v0.7.1r-alpha-windows-x64> .\Engine.exe -h

# Example: one of the commands used to run my tests:
PS C:\Users\SaltyJoss\dsfe-v0.7.1r-alpha-windows-x64> .\Engine.exe --batch -t assets/DSLScripts/vispa_report_test_1.dsl --name vispa_rA_t1 --basedt 1/960 --baseint rk4 --dt 1/30,1/60,1/120,1/240,1/480 --int euler,midpoint,heun,ralston,rk4,rk45

Current Release (vx.x.x-beta)

To be Added...

Project Info

Languages used

Robotic Models used in DSFE:

• Google Deepmind's open source models (MuJoCo) of Z1, UR5e, iiwa14, Panda, and H1 robotic systems
• StanforASL's repo for Panda robotic arm
• Unitree Robotics's repo for the Z1 and UR5e robotic arms
• Airbus's repo for the their Versatile In-Space and Planetary Arm (VISPA) URDF and model files

Roadmap Ideas:

IMPORTANT:
After the release of v0.8.0r-alpha this project will be refactored heavily to improve the general pipeline, functionality, and usability for research. This also means DSFE(Core) and DSFE(App) will move away from single-threaded to multi-threaded practices.
On May 8th 2026 my degree content/examinations are finished, meaning DSFE will be prioritised again. It is important to understand that the roadmap of this project outlines the larger plans, with many smaller ones not being added.

In September 2026 I start my masters in Computer Science, for which I plan to use DSFE for the final research project in 2027. This means DSFE will become more generalised in application, with core library (DSFE_Core) aiming to be used for multi-disciplinary research applying numerical models.

These changes have begun with the move to CMake-only building and compiling, alongside separation of concerns for DSFE's core library, and the app-specific executable DSFE_Engine. Originally, the plan was to only involve white-box applications, but given the core library is openly available for use external to the application, it makes sense to include a pre-compiled and functional application for researchers and academics who do not wish to code in C++. However, the DSL (Dynamic Systems Language) component of DSFE will be necessary for writing tests and experiments that are runnable. I will work on getting a gitpages documentation site out for it once the more immediate changes have been made. DSL also has plans to evolve from its current state.

I am the single developer of DSFE, being self-taught in higher-mathematics and computational physics, so please understand that there will be mistakes and errors in the code. If you find any areas of improvement, please let me know. I want this to become a functional and useful research tool for numerical modelling.

Todo List:

• Implement collision meshes with existing dynamics pipeline. (CORE)
• Improve CLI and GUI layouts, making them more Research-Oriented. (CORE)
• Add workspace layouts in GUI mode. (VISUAL)
• Support multiple concurrent sessions for GUI mode. (VISUAL)
• Move simulation data output to a dedicated Data-specific thread. (CORE)
• Explore DX11 and Vulkan alternatives, not necessarily a good idea but could improve usability on specific systems. (VISUAL)
• Explore non-x86(x64) instruction set support (ARM64, RISC-V). (CORE)
• Integrate the standardised URDF XML alongside or in place of the current DSFE json format. (CORE)

Tasks in progress:

This is what I am actively implementing, not just planning to implement

• Multithread DSFE_Core, DSFE_GUI, and DSFE_Engine (not just batch parallelisation) - if DSFE_DSL is later separated, multithread that too. (CORE)
• Extend DSFE to support other classes of dynamical systems outside robotic manipulators. (CORE)
• Support multiple articulated systems within a single simulation instance. (CORE)
• Further extend physcial modelling for different robot models (humanoid, legged). (CORE)
• Rework DSL to be fully independent of the framework, rather used by the DSFE framework in a specific way via a internal libraries to further integrate specific features. (CORE)
• Implement more advanced structure-preserving integration methods (Radau IIA methods, High-Order SSPRK methods, even higher-stage(and therefore order) GLRK methods). (MATH)
• Get DSFE to work on Linux. (CORE)
• Implement solution to current friction model (Seems to be introducing stiffness into RK4/RK45?) - LPV or Karnopp approach maybe?. (MATH)

Completed Tasks:

• Replace the current diagonal model with the standarised full-matrix rigid-body model (CORE)
• Implement unit tests for each method relevant to numerical analysis. (CORE)
• Implement basic implicit/structure-preserving integrators (Implicit Euler, Implicit Midpoint, GLRK-variants) (MATH)
• Sepearate core physics/mathematics logic from the GUI and visualisation layers (CORE)
• Explore migration to a CMake-only build system (CORE)
• Migrate to a CMake-only build system (CORE)
• Further separate the core simulation stepping from the physics/mathematical backend and form the GUI/visualisation layers (CORE)
• Need to look at using CRBA instead of just looping through a mass matrix loop. (MATH)
• Implement RNEA, CRBA, and ABA to replace FDM for approximating M(q) and qdd. (MATH)

Citations

If you use this software in academic work or any published research, please cite it.
See CITATION.cff.

License

Licensed under the GPL-3.0 License.

TL;DR:
This project is licensed under GPL-3.0. You may use, modify, and distribute it (including commercially).
If you distribute this project or a modified version, you must provide the corresponding source code under GPL-3.0, and keep copyright, license, and attribution notices intact.
Modified versions should be clearly marked as modified. See the LICENSE file for details.

Attribution: Please retain the original author credit. A link back to this repository is greatly appreciated.

Third-Party Tools Used:

The software itself is made of 3 seperate solutions that are under the GPL-3.0 License. However, it has been built and tested using various thirdparty tools and libraries.

• Eigen for high-performance linear algebra operations that compute robot kinematics, dynamics, and numerical integration
• GLM for OpenGL-compatible vector and matrix types for graphics transforms, camera math, and rendering-side calculations
• GLFW for creating windows, manage OpenGL contexts, and handle user input across platforms
• GLAD for loading OpenGL function pointers at runtime, and enabling access to more modern OpenGL features
• ImGui for immediate-mode GUI for runtime controls, debugging panels, simulation visualisation tools, and the DSL script editor
• ImPlot for more complex realtime plots used during simulation runs in DSFE
• Assimp for importing 3D meshes and scene data from many file formats for robot models and misc objects
• nlohmann Json for integration of .json files within c++, allowing robots to have defined properties that can be easily retrieved upon loading
• HDF5 for storing structured time-series data from robotic arm simulation runs for post-analysis and comparisons of integration methods performance and stability
• stb image for lightweight loading of png and jpgs files previously used in cubemaps
• SSAO logic was taken and derived from SemiWaker's SSAO repo - please remember this for any logic SSAO-related.

(back to top)

Other Disclaimers:

AI Usage Disclaimer:
AI tool were used in limited and defined ways throughout this project:

• Assisstance in finalising PBR and IBL GLSL shader implementations
• Debugging support after my own attempts using logical analysis, documentation, academic references, and technical forums
• Early-stage resource discovery and outline (e.g. helping identify relevant literature and refine search queries)

Outside of the GLSL shader implementations, any AI-assisted output was limited to implementation guidance and debugging suggestions. All such suggestions were ritically evaluated and verified prior to usage, with any fixes being developed and implemented by myself.