This is where you leverage the WebGL’s ability to perform these calculations.

jonny-b said:
simulation takes way to long to do anything.

You could use WebGPU. GPUs are extremely efficient for brute forcing N-body problems, as least as long as they fit into a single workgroup, which might be 8K stars in practice.
For more, it's still fast by processing blocks of 8K each, but the real solution would be to get rid of O(n^2), as discussed before.

The simplest solution would be to use a regular grid, e.g. 32 x 32 cells. Each cell has a list of all stars it covers, and the summed mass of all of those stars.

To update one star, algorithm is like this:

for each cell
{
	if (cell is far away) 
		currentStar.acc += ApplyGravityFrom(cellCenter, cellMassSum);
	else for each star in the cell
		currentStar.acc += ApplyGravityFrom(cellStar.Center, cellStar.mass);
}

If you have 100.000 stars, each star might interact with only 2000 masses instead 100.000, at the cost of some quantization error.

And it's not so much work to do.
But: We loose the optimization we did before, by using my ‘optimized N-body loop’, you remember.
This optimization gave us a speedup of 2. We loose that, and we have some extra cost from complexity and maintaining the grid.

It's thus hard to say if the work gives you noticeable benefit at all.
It would be a nice exercise. Dut sadly, as with most trials to optimize time complexity, it only pays off if N is large. And often this prevents application for realtime stuff :/

And there is another issue here too: Your results are not what you desire, and you assume it would become better with more stars and more processing power, to handle a larger N.
But in my experience that's rarely true. Often there is something else missing or wrong, and if we knew, we could fix and verify that also without a larger N.

jonny-b said:
This crossed my mind. I had hoped that I would see the spiral galaxy form from just this basic simulation. However, like you said, it could be that something is just completely wrong. Like perhaps my starting conditions for my galaxy sim are wrong. Perhaps the constraints I've put in are wrong. Maybe I need to incorporate some other physics.

Welcome to the club. I really have a similar experience with my terrain simulation for months.

However, at least we learn that we don't know much. And maybe that's all there is to know, but still takes infinite time to figure out. \:D/

I have coded a galaxy, and yes, the initial conditions are hard to calculate.

First, I create a “test particle” black hole at the centre, and “test particle” stars around it on a disk. Once the initial positions are known, the initial velocities are calculated like:

for (size_t i = 1; i < test_particle_pos.size(); i++)
{
	const custom_math::vector_3 accel = grav(i, test_particle_pos[i]);

	const custom_math::vector_3 out(0, 0, 1);

	test_particle_vel.push_back(accel.cross(out));
}

The whole code is at https://github.com/sjhalayka/galaxy

The galaxy sim is the best. Fantastic!

That's pretty interesting now : )

I have several issues using a Win7 on VirtualBox, running Chrome. Not sure if you can do much about it.

If i select a scene from the drop down, the selection click also toggles the interactive mode switch below the drop down.
Sometimes, after selection, the new scene starts as expected. But sometimes not, and i start trying to click the try it or reset buttons. The response is not clear and feels a bit buggy.

I thought it would be a great idea to implement merging stars. And the black hole sucking and vaporizing stars, instead propelling them out, increasing black hole mass accordingly.
Such merging would also help against the issue of increasing energy if stars collide.

Care to read the paper that I’m working on?

it involves gravitation and dark matter.

https://github.com/sjhalayka/papers/raw/main/anisotropic%20gravitation/bezier_escape.pdf