Simulation is N-Body, means all particles interacts with each other. This is what can be called a galaxy simulation. Of course, with some assumptions! The formation of a galaxy is a long process, the beauty of which was formed by millions of years of interactions. Moreover, the number of particles in a galaxy is so large that no computer could recreate the birth of a galaxy with high accuracy. But this simulation will allow you to enjoy the process on a small scale.
50,000 particles forms a Galaxy-like image (Try it yourself: #1, #2, #3)
Since an accurate calculation of the gravitational interaction would be too difficult, some optimizations were used. All particles are divided into hierarchical segments, thus creating a Spatial Tree.
Each particle in a segment interacts with each other, but not with particles in other segments. Instead, the segments themselves are perceived as large particles and interact with each other. This allows us to achieve an acceptable complexity: O(N*logN) instead of unoptimized O(N*N).
Visualization of Spatial tree used to optimize 100,000 particles interaction
You can see Spatial Tree segmentation in real-time: link
This means that we can simulate 100,000 particles in just about 500,000 operations. Without optimization, 100,000 particles would require 10,000,000,000 operations (20,000 times more)
Visualization of 1,000,000 particles (click image to open YouTube video)
You can use Simulation Player to watch recorded simulations.
Note: Please be patient, files may be very large, so loading may take a while. Pay attention to the package size written in brackets.
Demo links:
- 16k particles with
collision=1
: player / recorded track (6MB) / simulation - 65k particles with
collision=1
: player / recorded track (72MB) / simulation - 128k particles with
g=100
: player / recorded track (56MB) / simulation - 128k particles with self-collision burst,
collision=1&g=10
: player / recorded track (52MB) / simulation
You can combine different parameters, renderer and backend.
To change parameter just add it to url as query parameter, e.g.: /?particle_count=10000&particle_init=bang
Collision:
- Enabled collisions: link
- Enabled collisions with gpgpu simulation: link
- Enabled collisions with gpgpu simulation and
min_distance=3
: link
Different initializers:
- circle initializer: link
- uniform initializer: link
- bang initializer: link
- rotation initializer: link
- collision initializer: link
- swirl initializer: link
Different gravity forces:
Different resistance:
- bang initializer with
0.99
resistance andx100
gravity: link - collision initializer with
0.995
resistance andx100
gravity: link
Particle mass variation:
- Mass variation
3
andx0.5
gravity: link - Mass variation
5
with accurate gpgpu simulation: link - Mass vartiation
10
with accurate big gpgpu simulation: link
Debug mode:
Supported render engines:
Use HMTL5 Canvas to render particles. In order to reduce the delay, rendering through the ImageBuffer is used. The render performs well on mobile platforms, but loses a lot in performance at high resolutions. Also, Canvas does not support dynamic particle size, so particles can be difficult to see on screens with a high pixel density.
Demo links:
Use WebGL 2.0 to render particles. This rendering method allows to effectively display many particles in high resolution. Render works well on screens with high pixel density and maintain dynamic particle size. May not work on older browser versions and on older mobile devices. Rendering is very fast, so this render type is recommended for screens with high refresh rates.
Demo links:
Supported backends:
A web worker is used to calculate physics. All calculations are done separately from the main thread, so even with heavy simulation configurations, rendering will still be at a high frame rate. This method of calculation is well suited for mobile platforms or systems with basic integrated graphics.
The calculation is done entirely by the CPU, so don't expect high performance in tasks like N-Body simulation.
Performance can be influenced through the segmentation_max_count
parameter. Decreasing the value also reduces the computational complexity, but degrades the accuracy of the simulation.
Demos with different segment max sizes:
- Max segment size
8
: link - Max segment size
32
: link - Max segment size
128
: link - Max segment size
256
: link
Increasing segmentation_max_count
significantly degrades performance, but improves calculation accuracy.
Simulation demo links with maximum accuracy:
GPGPU is used for calculation (General-purpose computing on graphics processing units). All calculations are performed in a separate worker, but on the GPU. Due to the high parallelization of calculations, it is possible to achieve significant acceleration for complex simulation configurations. This method most likely will not work on mobile platforms, but it will work well on desktops with discrete graphics cards.
In this calculation method, segmentation_max_count
parameter is interpreted as the size of the side of the 2D texture, i.e. value 128 actually means 128*128=16348
segment size. This method allows to simulate gravity with maximum accuracy and with a large number of particles.
Unfortunately, on small segment sizes, the method works inefficiently and works worse than worker
backend.
Demos with different segment max sizes:
- Max segment size
64*64
and32k
particles: link - Max segment size
128*128
and131k
particles: link - Max segment size
256*256
and262k
particles: link
Increasing segmentation_max_count
also degrades performance for GPGPU, but allows to simulate much more particles with max accuracy.
Simulation demo links with maximum accuracy:
- Max segment size
96*96
: link - Max segment size
128*128
: link - Max segment size
176*176
: link - Max segment size
256*256
: link
See params description here: link