The simulation is an N-Body system, where all particles interact with each other. It can be referred to as a galaxy simulation, although certain assumptions are made. The formation of a galaxy is a lengthy process, shaped over millions of years of interactions. Furthermore, the sheer number of particles in a galaxy is so immense that recreating the birth of a galaxy with high accuracy is beyond the capabilities of any computer. However, this simulation provides the opportunity to witness the process on a smaller scale.
50,000 particles forms a Galaxy-like image (Try it yourself: #1, #2, #3)
Given the complexity of accurately calculating gravitational interactions, several optimizations have been employed. The particles are organized into hierarchical segments, forming a Spatial Tree. Each particle within a segment interacts with every other particle in the same segment, rather than engaging with particles in different segments. Consequently, the segments themselves are treated as larger particles and interact with one another. This approach ensures an acceptable complexity level: O(N*logN), as opposed to the unoptimized O(N*N) approach.
Visualization of Spatial tree used to optimize 100,000 particles interaction
You can see Spatial Tree segmentation in real-time: link
In practical terms, this means that we can simulate 100,000 particles using approximately 500,000 operations. Without optimization, simulating 100,000 particles would require 10,000,000,000 operations, which is 20,000 times more computationally intensive.
Visualization of 1,000,000 particles (click image to open YouTube video)
- Accurate simulation, galaxy-like pattern may born (#1): link
- Accurate simulation, galaxy-like pattern may born (#2): link
- Fast simulation (#1): link
- Fast simulation (#2): link
- Big GPGPU simulation (#1): link
- Big GPGPU simulation (#2): link
- Particle collisions CPU (accurate): link
- Particle collisions CPU (fast): link
- Particle collisions GPGPU (accurate): link
- Particle collisions GPGPU (fast): link
More links you can find below.
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.99resistance andx100gravity: link - collision initializer with
0.995resistance andx100gravity: link
Particle mass variation:
- Mass variation
3andx0.5gravity: link - Mass variation
5with accurate gpgpu simulation: link - Mass vartiation
10with accurate big gpgpu simulation: link
Debug mode:
Supported render engines:
Use HTML5 Canvas to render particles. In order to reduce delays, rendering through the ImageBuffer is utilized. The rendering performs well on mobile platforms but experiences a significant drop in performance at high resolutions. Furthermore, canvas renderer does not support dynamic particle size, making particles difficult to discern on screens with high pixel density.
Demo links:
Use WebGL 2.0 to render particles. This rendering method effectively displays numerous particles in high resolution. The render works well on screens with high pixel density and maintains dynamic particle size. However, it may not function on older browser versions and older mobile devices. This rendering technique is highly recommended for screens with high refresh rates due to its fast performance.
Demo links:
Supported backends:
A web worker is utilized for physics calculations. All computations are performed separately from the main thread, ensuring a smooth rendering experience even with complex simulation configurations. This calculation approach is particularly suitable for mobile platforms and systems with basic integrated graphics. Please note that since the computations are entirely handled by the CPU, it may not deliver high performance for tasks such as N-Body simulation. You should manage your expectations accordingly.
You can fine-tune the performance by adjusting the segmentation_max_count parameter. Decreasing its value reduces the computational complexity but sacrifices 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 (General-purpose computing on graphics processing units) is employed for calculations in a dedicated worker, utilizing the power of the GPU. The highly parallelized nature of these computations enables significant acceleration, particularly for complex simulation configurations. However, it's worth noting that this method may not be suitable for mobile platforms but delivers excellent results on desktops equipped with discrete graphics cards.
In this calculation method, the segmentation_max_count parameter is interpreted as the dimension of the 2D texture, indicating the size of each segment. For example, a value of 128 actually corresponds to a segment size of 16,348 (128 * 128).
This method enables the simulation of gravity with utmost accuracy, accommodating a high volume of particles. However, it exhibits inefficiency and performs worse than the worker backend when used with small segment sizes.
Demos with different segment max sizes:
- Max segment size
64*64and32kparticles: link - Max segment size
128*128and131kparticles: link - Max segment size
256*256and262kparticles: link
Although increasing the segmentation_max_count adversely affects GPGPU performance, it facilitates the simulation of a significantly larger number of particles while maintaining maximum 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
Application originally developed and optimized for Chrome browser. In other browsers app can have significant performance degradation.
- Due to lack of WebWorker modules the simulation may not work in Firefox.
- Due to lack of OffscreenCanvas GPGPU backend may not be available in Safari/Firefox.