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:

• rotation initializer with x1000 gravity: link
• collision initializer with x1000 gravity: link

Different resistance:

• bang initializer with 0.99 resistance and x100 gravity: link
• collision initializer with 0.995 resistance and x100 gravity: link

Particle mass variation:

• Mass variation 3 and x0.5 gravity: link
• Mass variation 5 with accurate gpgpu simulation: link
• Mass vartiation 10 with accurate big gpgpu simulation: link

Debug mode:

• Spatial tree: link
• Speed and momentum vectors: link

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:

• With enabled device pixel rate: link
• With disabled device pixel rate: link

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:

• With enabled device pixel rate: link
• With disabled device pixel rate: link

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:

• Max segment size 1024: link
• Max segment size 2048: link
• Max segment size 4096: link

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 and 32k particles: link
• Max segment size 128*128 and 131k particles: link
• Max segment size 256*256 and 262k 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