Simulation of Gravity / Galaxy Birth simulation

N-Body Simulation

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)

Demo Links

• 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.

Simulation Player

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

Real-Time 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

Renderer

Supported render engines:

Canvas

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:

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

webgl2

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:

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

Backend

Supported backends:

worker

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:

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

gpgpu

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

Parameters:

See params description here: link

Limitations:

Application originally developed and optimized for Chrome browser. In other browsers app can have significant performance degradation.

Known issues

• 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.