VSoyuz — A Soyuz and ISS Spaceflight Simulator Built with Unreal Engine 4.27
Hello everyone!
I’d like to share a few screenshots from my project, VSoyuz, a spaceflight simulator I’ve been working on.
The project focuses on simulating the Soyuz spacecraft and the International Space Station (ISS). The goal is not simply to create a visually appealing space environment, but to bring together 3D visualization, spacecraft orbital dynamics, mathematical models of motion, and the simulation of real onboard systems.
The project is being developed step by step. Some components are already functional, while others are still undergoing development, research, and validation.
I’d like to give you a brief overview of how several parts of the project work.
1. Earth, Atmosphere and the International Space Station
The first screenshots show the ISS against the background of Earth.
Earth is represented as a separate 3D object within the space environment. Its visualization uses spherical geometry, textured materials, and dedicated cloud components.
For atmospheric rendering, the project uses the built-in Sky Atmosphere system in Unreal Engine 4.27.
It is responsible for visual atmospheric light scattering, the atmospheric limb, and the transition between ground-level and orbital views.
The implementation uses:
- Rayleigh scattering — molecular scattering of sunlight;
- Mie scattering — scattering caused by aerosols and atmospheric particles;
- atmospheric light absorption and scattering;
- interaction between the atmosphere and the directional light source.
The current Sky Atmosphere configuration uses an Earth radius of 6,371 km and an atmospheric shell height of 60 km.
The Sun’s direction is calculated separately. The mathematical part of the project includes the sun_direction_j2000() function, which determines the Sun’s direction in the J2000 inertial reference frame.
This direction is then used to synchronize the Unreal Engine Directional Light with the calculated solar position.
A geometric model of Earth’s shadow is also implemented, including the umbra and penumbra.
One important distinction: I am currently working on verifying the physical consistency of the visual atmosphere. A convincing atmospheric limb does not necessarily mean that the underlying optical model is fully calibrated.
ISS Positioning
The station’s position in space is treated as part of the mathematical simulation rather than as an arbitrary movement of a 3D object within the scene.
The project is designed to work with the station’s orbital state, including its position, velocity, and attitude.
The calculated state is transformed into Unreal Engine coordinates and then used to position and orient the corresponding 3D representation.
The rotational dynamics model includes a quaternion-based attitude representation, angular velocity, and an inertia tensor.
I am also developing a model of the ISS gravity-gradient torque. This is an interesting physical effect in which the non-uniformity of Earth’s gravitational field produces a torque on an extended spacecraft structure.
In the future, I want to simulate how this torque changes with different station configurations, including docked visiting spacecraft.
2. The Neptune Cosmonaut Control Panel
The next screenshots show another interesting part of the project: the recreation of the Neptune onboard cosmonaut control panel.
This is not simply a control panel drawn in a 3D editor.
The goal is to reproduce the software architecture of a real onboard display system used to present information and allow cosmonauts to interact with spacecraft systems.
The underlying concept is based on a screen-format architecture.
How Screen Formats Work
The screen should not be a collection of predefined static images.
Its contents are determined by format descriptions that define the positions of elements, text areas, graphical objects, buttons, indicators, and other components.
The project involves studying and porting the original Neptune resource system, including the RUNTIME.SFT file, fonts, and graphical resources.
A dedicated C++ system called SFS is being developed to interpret these resources.
Its architecture includes:
ScreenFormat— representation of a screen format;ScreenFormatRT— runtime resource format handling;SFitem— individual screen elements;- a screen-format registry;
- cluster activation and deactivation logic;
- a dedicated graphics rendering layer.
Bitmap fonts, palettes, and graphical primitives are handled separately.
The screen area is designed around the original 640 × 480 resolution.
How the Image Is Generated
Instead of manually creating every screen, the system reads the format description, interprets its elements, and generates the resulting image in a graphics buffer.
The buffer is then rendered within the application interface.
This approach makes it possible to support multiple screen formats while preserving their original structure and rendering principles.
At the current stage, the project has a working foundation for the screen system, a resource-handling layer, and a partial implementation of the first screen format, F1.
Loading RUNTIME.SFT and activating selected clusters are already implemented in a separate integration path.
However, universal support for all screen formats and full functional equivalence with the original onboard system are still ongoing development tasks.
Camera and Display Architecture
An important design principle is the separation between the data source, screen-format logic, and visual representation.
The rendering system should receive the already-generated screen state rather than contain the operational logic of every onboard subsystem.
This makes it possible to develop the display interface independently of the underlying mathematical models and telemetry sources.
3. The Soyuz Spacecraft
The next series of screenshots focuses on the spacecraft itself.
The 3D Soyuz model serves as the visual representation of an individual spacecraft within the shared space environment.
It is important to me that the spacecraft does not simply look good next to the station. It should have its own calculated physical state.
Position and Attitude
The spacecraft’s mathematical model separates several fundamental quantities:
- center-of-mass position;
- linear velocity;
- attitude;
- angular velocity;
- mass properties;
- control inputs.
The spacecraft’s position is linked to its orbital state, while its attitude is determined by rotational dynamics and control inputs.
Quaternion-based attitude representation is used to describe its orientation.
This allows arbitrary three-dimensional orientations to be handled without the singularities associated with directly using Euler angles.
Spacecraft Control
Another major development area is the simulation of spacecraft onboard control systems.
The project investigates and implements mathematical models of onboard systems, including:
- КДУ — propulsion system;
- ДПО — docking and attitude-control thrusters;
- КУРС — rendezvous and approach system;
- БЦВК — onboard computer complex;
- ССВП — docking and internal transfer system.
Particular attention is paid to ensuring that control inputs are connected to the spacecraft’s mathematical model of motion.
For example, when attitude-control thrusters fire, the spacecraft’s rotational state must change according to the actual forces and torques applied, rather than merely changing the visual appearance of the vehicle.
The DPO system includes 28 individual thruster nozzles, each with its own position and thrust direction defined in the spacecraft’s body-fixed coordinate system.
This provides the foundation for independently simulating nozzle activation and subsequently visualizing the corresponding exhaust plumes.
Further development will focus on manual control modes, rendezvous, approach, and docking procedures.
4. The Overall Project Concept
The main objective of VSoyuz is to combine several levels of simulation within a single environment.
Level 1 — Mathematical Simulation
This includes orbital calculations, coordinate reference frames, kinematics, and the dynamics of spacecraft motion.
Level 2 — Onboard Systems
This covers models of spacecraft equipment, onboard computers, propulsion systems, attitude control, rendezvous, and docking systems.
Level 3 — Visualization
The visualization layer should represent the state of the mathematical simulation: spacecraft positions, attitudes, lighting, atmospheric effects, and physical processes.
I also plan to develop a dedicated Verification and Validation (V&V) system to check the mathematical models against independent reference data and technical documentation.
My goal is to gradually move beyond visually convincing graphics towards scientifically and engineering-grounded simulation.
Conclusion
VSoyuz is currently under active development. Some subsystems already have a substantial software foundation, while others are still going through research, implementation, and validation.
This is a project I am developing out of a strong interest in space exploration, spacecraft engineering, and the technical side of human spaceflight.
In particular, I am interested in feedback on:
- Earth and atmospheric visualization from orbit;
- large-scale spatial coordinate systems;
- orbital dynamics;
- lighting and eclipse simulation;
- recreating complex technical onboard interfaces.
Thank you for taking the time to check out my project!